Les clés du Registre Windows qui rentabilisent le temps en DFIR
9 min de lecture
Le Registre Windows est l'un de ces artefacts où la documentation est exhaustive et la priorisation manque. Il y a des dizaines de milliers de clés dans une installation par défaut. Vous en regarderez peut-être vingt dans la plupart des investigations. L'astuce est de savoir quelles vingt, et de savoir ce que chacune vous dit réellement quand elle s'allume.
Cet article est la liste courte sur laquelle je reviens. Pas une référence exhaustive. Un ensemble de travail.
Quelles ruches récupérer, dans quel ordre
Si quelqu'un vous tend un hôte et vous dit qu'il pense qu'il est compromis, vous voulez cinq fichiers plus leurs journaux de transactions :
C:\Windows\System32\config\SYSTEM: services, drivers,ControlSetvivant, le Shimcache.C:\Windows\System32\config\SOFTWARE: applications installées, clésRun, service de liste de réseaux.C:\Windows\System32\config\SECURITY: politique de sécurité locale, configuration d'audit, identifiants de domaine en cache (hashs DCC2).C:\Windows\System32\config\SAM: comptes locaux et hashs de mots de passe. À jumeler avecSYSTEMpour déchiffrer.C:\Users\<user>\NTUSER.DAT: paramètres par utilisateur, y comprisUserAssist,RecentDocs, et les clésRunpar utilisateur.
Chacun a une paire de journaux de transactions (.LOG1, .LOG2).
Acquérez-les toujours en même temps que la ruche principale. Le rejeu
des journaux récupère les écritures en cours et fait
occasionnellement remonter des enregistrements qui n'ont jamais
atteint le fichier principal. Cette seule habitude a sauvé plus
d'investigations qu'aucune autre.
Si vous suspectez une suppression de données registre, prenez aussi
chaque NTUSER.DAT de C:\Users\ (y compris tout profil qui ne
s'est pas connecté récemment, les profils supprimés mais non
nettoyés), et cherchez UsrClass.dat à côté de chacun.
Les Volume Shadow Copies valent de l'or. La plupart des installations Windows bien instrumentées gardent au moins une semaine de snapshots VSS, et comparer les ruches entre snapshots VSS est comment vous attrapez les attaquants qui ont édité une clé et l'ont remise.
Les clés de persistance, par ordre de priorité
Il y a environ une centaine d'emplacements de persistance dans le registre, mais une poignée attrape la plupart des incidents réels :
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run et RunOnce :
exécution au démarrage. Le premier endroit où chercher.
HKCU\Software\Microsoft\Windows\CurrentVersion\Run est son
équivalent par utilisateur. Les deux méritent leur temps.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon : clés
Userinit, Shell, et Notify. Les valeurs Userinit modifiées
sont une vieille technique qui marche encore sur les hôtes mal
durcis. Les défauts sont bien connus ; toute déviation est
intéressante.
HKLM\SYSTEM\CurrentControlSet\Services\ : chaque service Windows.
Regardez ImagePath et ServiceDll pour des binaires dans des
répertoires accessibles en écriture par l'utilisateur. Les services
tournant depuis \AppData\Local\Temp\ ou \Users\Public\ sont
presque toujours malicieux.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ :
la clé IFEO. Un mécanisme légitime de redirection de débogueur qui
est abusé pour la persistance et le détournement de processus. Toute
valeur Debugger pointant vers un binaire inhabituel mérite
investigation. Le classique est \sethc.exe ou \osk.exe avec un
débogueur pointant vers cmd.exe (backdoor sticky-keys sur les
écrans de connexion RDP).
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
et User Shell Folders : redirection du dossier de démarrage. Les
attaquants pointent parfois Common Startup vers un répertoire
accessible en écriture et y déposent une charge utile.
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute :
applications à exécuter pendant le démarrage. Les défauts sont
autocheck autochk *. Tout le reste est intéressant.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks :
tâches planifiées (la moitié sauvegardée en registre ; la moitié XML
est dans C:\Windows\System32\Tasks\). Comparer les deux fait
souvent remonter des tâches cachées par édition d'une moitié sans
l'autre.
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load :
valeur de chargement par utilisateur. Rare en usage légitime ;
presque toujours malicieuse quand définie.
Si vous faites une passe rapide, lancez autoruns de Sysinternals
sur une ruche montée. Il vérifie tout cela et bien plus. La sortie
est verbeuse mais le tri par colonne rend le triage gérable.
UserAssist : la curiosité ROT13 qui marche toujours
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{GUID}\Count\
enregistre chaque programme qu'un utilisateur a lancé depuis le menu
Démarrer, l'Explorateur ou la boîte de dialogue Exécuter. Les noms de
clés sont encodés en ROT13 (oui, en 2026, ROT13). Les valeurs
incluent un compte d'exécutions et le FILETIME de la dernière
exécution.
C'est l'un des meilleurs artefacts d'exécution par utilisateur sur le
système. Meilleur que Prefetch pour
la question "qui l'a lancé", parce que UserAssist vit dans le
NTUSER.DAT de l'utilisateur et n'a donc aucune ambiguïté sur
l'attribution.
Cas limites à connaître :
- Les programmes lancés via la ligne de commande, une tâche planifiée ou un service n'apparaissent pas. UserAssist ne suit que les lancements GUI.
- Les horodatages
LastRunse mettent à jour à chaque lancement, ce qui les rend utiles mais volatils. Prélevez la valeur au moment de l'acquisition ; ne supposez pas qu'elle sera la même une heure plus tard. - Les deux GUID qui comptent sont
CEBFF5CD-ACE2-4F4F-9178-9926F41749EA(exécutions d'exécutables) etF4E57C4B-2036-45F0-A9AB-443BCFE33D9F(raccourcis). Certains outils n'en affichent qu'un.
ShellBags : brouillon, contesté, utile
HKCU\Software\Microsoft\Windows\Shell\BagMRU\ et les clés parallèles
sous UsrClass.dat enregistrent quels répertoires un utilisateur a
visités dans l'Explorateur, y compris les répertoires sur médias
amovibles et partages réseau. Les clés sont imbriquées et se
référencent via un arbre Bags\ séparé, raison pour laquelle chaque
analyste a, à un moment, maudit les ShellBags.
Quand la question est "cet utilisateur a-t-il ouvert ce dossier", ShellBags y répond. Quand le dossier est sur une clé USB qui a depuis été retirée, ShellBags peut être le seul artefact qui survit.
Le piège : l'analyse ShellBag est plus difficile que le format ne le
suggère, parce que la structure a changé entre les versions Windows
et parce qu'Explorer écrit les bags paresseusement. Trois outils qui
le font correctement sont ShellBagsExplorer d'Eric Zimmerman,
RegRipper avec le plugin shellbags, et l'analyseur de ce site. La
plupart des implémentations Python ad-hoc obtiennent un
sous-ensemble correct.
Couplez les hits ShellBag avec les fichiers LNK et les jump lists pour la revendication la plus forte sur l'activité fichier utilisateur.
Récemment utilisé : les petites clés qui clôturent les dossiers
Quelques clés par utilisateur qui frappent plus fort que leur poids :
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs :
fichiers que l'utilisateur a ouverts, par extension. Sans ROT13 cette
fois.
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths :
chaque chemin tapé dans la barre d'adresse de l'Explorateur. Inclut
les chemins UNC.
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU :
chaque commande tapée dans Win+R. Les gens tapent dans Exécuter des
choses qu'ils ne mettraient jamais dans leur historique de commandes.
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU :
fichiers ouverts ou sauvegardés via les dialogues Win32 standard.
Inclut l'historique du sélecteur de fichiers pour Office, navigateurs
et la plupart des apps natives.
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU :
l'application la plus récemment utilisée pour ouvrir une extension
de fichier donnée.
Si vous reconstruisez ce qu'a fait un utilisateur pendant la fenêtre suspecte, ces cinq clés plus UserAssist vous donneront 70 % du tableau.
Les clés qui vous égarent
HKLM\SYSTEM\Setup\Status\SysprepStatus et les clés sysprep
associées portent des horodatages qui semblent autoritaires et ne le
sont parfois pas. Sur les systèmes imagés depuis une image maître,
les horodatages sysprep reflètent quand l'image a été scellée, pas
quand l'hôte a été construit ou démarré pour la première fois.
Recoupez avec les clés HKLM\SYSTEM\Setup\Source OS (Updated on YYYY-MM-DD) et les horodatages MFT sur
la ruche SYSTEM elle-même.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate est
une époque Unix dans un registre. C'est la date d'installation telle
que Windows la connaît. Après certaines mises à niveau sur place,
elle est réécrite, donc ce n'est pas toujours la première
installation.
L'heure LastWrite d'une clé est l'heure à laquelle la clé (pas ses
valeurs) a été modifiée pour la dernière fois. Si vous voyez un
LastWrite près de l'heure d'incident suspectée sur une clé de
persistance, c'est intéressant. Si vous le voyez sur une clé que
Windows met à jour régulièrement
(Software\Microsoft\Windows\CurrentVersion\Explorer\StreamMRU et
consorts), c'est du bruit.
Anti-forensique : ce que les attaquants font, et ce qui survit
Le registre est inscriptible par tout ce qui a les privilèges suffisants. Les attaquants qui savent ce qu'ils font :
- Éditer et annuler. Définir une clé
Run, déposer la charge utile, l'exécuter, supprimer la valeur. LeLastWritede la cléRunreflétera la suppression, mais la valeur précédente est parfois récupérable depuis les journaux de transactions et presque toujours depuis les snapshots VSS. - Cacher via les permissions. Prendre possession d'une clé,
définir les permissions pour que SYSTEM puisse lire mais pas les
Administrateurs, et y écrire la persistance. Des outils comme
RegScannerde nirsoft etRegRippertournant en contexte SYSTEM (ou contre une ruche hors ligne) contournent l'astuce. - Cacher via des noms à caractères null. Les noms de clés registre contenant des octets null embarqués sont invalides via l'API Win32 mais légaux au niveau NT. L'UI regedit Windows ne peut les voir ; les analyseurs hors ligne le peuvent. Vieille astuce qui marche encore contre les contrôles peu sophistiqués.
- Effacer MUICache et UserAssist. Possible, mais le registre est
un arbre copy-on-write, donc les cellules non allouées de la ruche
contiennent encore les valeurs effacées. Des analyseurs comme le
plugin
delde RegRipper et yarp les récupèrent.
Les journaux de transactions de ruche sont le filet de sécurité le
plus négligé. Rejouez-les. Acquérez les snapshots VSS. Lancez un mode
recovery sur chaque ruche avant de commencer la vraie analyse.
Un ordre d'opérations qui marche
Pour une passe standard "cet hôte est-il compromis" :
- Acquérir
SYSTEM,SOFTWARE,SECURITY,SAM, et chaqueNTUSER.DATplus leurs.LOG1/.LOG2et les fichiersUsrClass.dat. - Lancer une passe de récupération sur chaque ruche. Certains analyseurs le font automatiquement.
- Extraire les clés de persistance ci-dessus. La sortie
autorunsde Sysinternals est la voie la plus rapide. - Extraire UserAssist, RecentDocs, RunMRU et TypedPaths de chaque ruche utilisateur.
- Comparer avec les snapshots VSS si disponibles. Une persistance qui apparaît dans la ruche vivante mais pas dans le snapshot d'hier est suspecte.
- Pour toute valeur de persistance pointant vers un binaire, pivoter vers AmCache, Prefetch, et le MFT pour le fichier lui-même.
L'étape de comparaison est ce qui sépare la forensique registre passable de la bonne. Tout le monde peut extraire une clé Run. Savoir que la clé Run était vide dans le snapshot d'il y a deux jours est ce qui rend la conclusion défendable.
Lire les ruches dans le navigateur
L'analyseur de ce site lit les ruches regf entièrement côté
client, avec rejeu de journaux de transactions. Déposez une ruche et
vous obtenez l'arbre clés-et-valeurs, les horodatages LastWrite, et
les plugins standard couvrant les emplacements de persistance
ci-dessus. Aucun envoi, ce qui compte quand la ruche SAM ou SECURITY
est en cause.
Pour aller plus loin
- Harlan Carvey, RegRipper : l'analyseur par plugins hors ligne canonique. Lisez la source des plugins ; c'est la meilleure référence vivante pour ce que contient réellement chaque clé.
- Maxim Suhanov, yarp : la bibliothèque de plus bas niveau, bonne pour comprendre le format de ruche.
- Microsoft, Registry Hives : référence du fournisseur. Moins utile que les plugins RegRipper, mais officiellement canonique.
- Le poster SANS DFIR sur la forensique du Registre Windows : aide-mémoire en une feuille, à imprimer.
Le registre est l'un de ces artefacts où dix minutes à lire les bonnes clés battent deux heures à lire les mauvaises. La liste ci-dessus est la mienne ; construisez la vôtre à partir d'elle.