Registry Parser
Tous les articles

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, ControlSet vivant, le Shimcache.
  • C:\Windows\System32\config\SOFTWARE : applications installées, clés Run, 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 avec SYSTEM pour déchiffrer.
  • C:\Users\<user>\NTUSER.DAT : paramètres par utilisateur, y compris UserAssist, RecentDocs, et les clés Run par 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 LastRun se 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) et F4E57C4B-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. Le LastWrite de la clé Run reflé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 RegScanner de nirsoft et RegRipper tournant 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 del de 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" :

  1. Acquérir SYSTEM, SOFTWARE, SECURITY, SAM, et chaque NTUSER.DAT plus leurs .LOG1/.LOG2 et les fichiers UsrClass.dat.
  2. Lancer une passe de récupération sur chaque ruche. Certains analyseurs le font automatiquement.
  3. Extraire les clés de persistance ci-dessus. La sortie autoruns de Sysinternals est la voie la plus rapide.
  4. Extraire UserAssist, RecentDocs, RunMRU et TypedPaths de chaque ruche utilisateur.
  5. 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.
  6. 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.