Forensique du Registre Windows : ruches, clés et méthode

Le Registre est la source la plus riche en preuves de configuration et d'activité utilisateur sur un système Windows, et l'une des plus faciles à mal interpréter. Ce guide vous montre où se trouvent les ruches, comment en obtenir une copie cohérente, quels horodatages sont fiables et lesquels ne le sont pas, quelles clés répondent aux questions classiques d'une enquête, et comment traiter les ruches à grande échelle avec Registry Explorer, RECmd et RegRipper.

Les ruches et leur emplacement

Le Registre que l'on voit dans regedit est assemblé à l'exécution à partir de plusieurs fichiers ruches (hives), des fichiers binaires au format regf montés sous une clé racine. La ruche du Registre est l'unité que l'on collecte et que l'on analyse. La fiche ruches du Registre liste tous les chemins ; celles dont vous aurez besoin dans presque chaque dossier sont :

NTUSER.DAT et UsrClass.dat existent pour chaque profil : collectez-les pour tous les utilisateurs, comptes de service et administrateurs compris. Amcache est techniquement une ruche et s'ouvre avec les mêmes outils, même si des parseurs dédiés la présentent mieux.

Journaux de transactions et ruches « sales »

Windows n'écrit pas chaque modification directement dans la ruche. Elles passent d'abord par des journaux de transactions placés à côté de chaque ruche : SYSTEM.LOG1, SYSTEM.LOG2, NTUSER.DAT.LOG1, etc. Depuis Windows 8.1, un nouveau format de journal permet aux données modifiées de rester dans les logs un certain temps (on cite couramment jusqu'à une heure) avant d'être reportées dans le fichier principal.

Le bloc de base (l'en-tête) d'une ruche contient un numéro de séquence primaire et un secondaire. S'ils diffèrent, la ruche est sale (dirty) : le fichier sur disque est en retard sur les journaux. C'est normal pour une copie prise sur un système allumé ou planté, et pour un snapshot cloud.

Conséquences :

• Collectez toujours les .LOG1 et .LOG2 avec chaque ruche. Les targets KAPE RegistryHives et leurs équivalents Velociraptor le font.
• Rejouez les journaux avant l'analyse. Registry Explorer le propose au chargement d'une ruche sale ; RECmd les rejoue automatiquement sauf indication contraire ; regipy-process-transaction-logs produit une copie propre.
• RegRipper ne rejoue pas les journaux lui-même : donnez-lui une ruche déjà nettoyée.
• Conservez la ruche sale d'origine et ses journaux comme preuve, et travaillez sur la copie rejouée.

La collecte des ruches verrouillées sur un système allumé est détaillée dans l'acquisition et le triage avec KAPE et Velociraptor.

CurrentControlSet ou ControlSet00x

HKLM\SYSTEM\CurrentControlSet n'existe pas dans le fichier SYSTEM. Au démarrage, Windows choisit l'un des ControlSet stockés (ControlSet001, parfois ControlSet002) et y rattache CurrentControlSet. Hors ligne, il faut donc déterminer lequel était actif :

SYSTEM\Select
  Current        = 1   -> ControlSet001 était utilisé
  Default        = 1
  LastKnownGood  = 1   (parfois absent sur les builds récentes)
  Failed         = 0

La plupart des systèmes récents n'ont que ControlSet001, mais ne le supposez pas. Les fichiers batch RECmd et les plugins RegRipper résolvent Select\Current pour vous ; en navigation manuelle, vérifiez-le d'abord. Un second ControlSet différent de l'actif peut d'ailleurs être intéressant en soi, par exemple un service présent dans l'un et pas dans l'autre.

Le LastWrite et ses limites

Chaque clé possède un LastWrite, un FILETIME en UTC mis à jour quand une valeur de la clé change ou qu'une sous-clé est ajoutée ou supprimée. Il est précieux, et très souvent surinterprété :

• Clés uniquement. Les valeurs n'ont pas d'horodatage. Si une clé contient dix valeurs, le LastWrite indique que quelque chose a changé dans la clé à ce moment-là, pas quelle valeur.
• Pas de propagation. Modifier une valeur dans une sous-clé ne met pas à jour le LastWrite du parent.
• Windows réécrit ses propres clés. Mises à jour, maintenance, chargement de profils et tâches planifiées peuvent toucher de nombreuses clés d'un coup. Un groupe de LastWrite identiques sur des clés sans rapport pointe généralement vers l'OS, pas vers l'utilisateur.
• Le nettoyage laisse une trace. Quand un attaquant ou un outil de nettoyage supprime une valeur MRU, le LastWrite de la clé enregistre l'heure de la suppression.
• Les horodatages internes sont distincts. Des artefacts comme UserAssist, BAM ou les profils réseau stockent leurs propres heures dans les données des valeurs. Chacun a son format, et certains sont en heure locale plutôt qu'en UTC ; voir UTC et heure locale.

L'en-tête du fichier de ruche contient aussi un horodatage, mais il n'est plus mis à jour depuis Windows 8.1 : ne vous y fiez pas.

Clés supprimées et cellules libres

Une ruche est faite de cellules. Supprimer une clé ou une valeur marque sa cellule comme libre sans l'effacer : le contenu survit jusqu'à ce que l'espace soit réutilisé. Registry Explorer affiche les entrées récupérées dans les enregistrements supprimés ou non associés ; yarp et certaines options de RECmd les récupèrent aussi. Les journaux de transactions et les volume shadow copies peuvent contenir des versions plus anciennes des mêmes données.

C'est important face à l'anti-forensique : un attaquant qui supprime une valeur Run ou une clé de service après usage laisse souvent les données dans une cellule libre, et le LastWrite de la clé parente date l'opération.

RegBack : vide depuis Windows 10 1803

Les anciens guides conseillent de comparer les ruches actives avec C:\Windows\System32\config\RegBack. Avant Windows 10 1803, une tâche planifiée y copiait régulièrement les ruches système. Depuis 1803, Microsoft a désactivé cette sauvegarde par défaut : les fichiers sont toujours là mais font 0 octet. Un administrateur peut la réactiver avec la valeur DWORD EnablePeriodicBackup sous HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager, comme le documente Microsoft sur learn.microsoft.com. Vérifiez la taille des fichiers avant de compter sur RegBack, et tournez-vous vers les shadow copies ou Windows.old pour les ruches historiques.

Les clés qui répondent aux questions de l'enquête

Les chemins ci-dessous utilisent ControlSet001 ; remplacez-le par le ControlSet indiqué dans Select\Current.

Profil du système

Deux pièges : ProductName indique toujours « Windows 10 » sous Windows 11, fiez-vous donc à CurrentBuild (22000 et au-delà pour Windows 11) ; et InstallDate correspond sur beaucoup de systèmes à la dernière mise à jour de fonctionnalités, pas à l'installation d'origine. Les profils réseau stockent leurs dates en SYSTEMTIME heure locale, pas en UTC. MountedDevices est le point de départ de l'historique USB et des volumes, avec USBSTOR et consorts. Les comptes sont détaillés dans SAM et comptes utilisateurs.

Activité utilisateur (NTUSER.DAT et UsrClass.dat)

BAM se trouve dans SYSTEM mais est indexé par SID : il fait le pont entre preuves système et preuves utilisateur. Les artefacts d'activité utilisateur sont traités en détail dans ShellBags, fichiers LNK et Jump Lists, et les artefacts d'exécution comme ShimCache dans les preuves d'exécution. Les emplacements de persistance (clés Run, services, Winlogon, IFEO) ont leur propre guide : traquer la persistance sous Windows.

Les outils

Registry Explorer

La visionneuse graphique d'Eric Zimmerman charge plusieurs ruches, rejoue les journaux de transactions, récupère les clés et valeurs supprimées, et fournit des favoris et des plugins qui décodent les artefacts courants (UserAssist, ShellBags, BAM, etc.). Utilisez-la pour explorer, valider une découverte ou comprendre une clé inconnue.

RECmd et ses fichiers batch

RECmd est son pendant en ligne de commande. Sa force, ce sont les fichiers batch (.reb) : des listes YAML de clés et de valeurs à extraire, avec des plugins de décodage. La distribution fournit des BatchExamples, dont Kroll_Batch.reb et DFIRBatch.reb, qui couvrent les clés de cet article et bien d'autres, et produisent un CSV unique par exécution, directement exploitable dans Timeline Explorer.

# Traiter toutes les ruches d'un dossier de triage (récursivement) avec un batch éprouvé
RECmd.exe -d E:\case\HOST01\tout\C --bn E:\tools\RECmd\BatchExamples\Kroll_Batch.reb --csv E:\case\HOST01\registry

# Interroger une clé dans une seule ruche, pour une vérification rapide
RECmd.exe -f E:\case\HOST01\SYSTEM --kn "ControlSet001\Control\TimeZoneInformation"

RECmd rejoue les journaux de transactions quand il rencontre une ruche sale et que les journaux sont présents. Le module KAPE !EZParser lance RECmd avec un fichier batch à votre place.

RegRipper

RegRipper, de Harlan Carvey, exécute des plugins Perl sur une ruche et produit des rapports lisibles, souvent accompagnés de notes d'analyste sur la signification de l'artefact. Il excelle pour obtenir rapidement une vue narrative et pour les artefacts que les autres outils ne décodent pas.

# Lancer un seul plugin sur une ruche utilisateur
rip.exe -r E:\case\HOST01\users\jdoe\NTUSER.DAT -p userassist

# RegRipper 3.x : lancer tous les plugins correspondant au type de ruche détecté
rip.exe -r E:\case\HOST01\SOFTWARE -a > E:\case\HOST01\software.txt

Rappel : RegRipper ne rejoue pas les journaux de transactions, nettoyez d'abord les ruches sales. La couverture des plugins et les options varient selon les versions ; rip.exe -l liste ce que votre copie prend en charge.

Comparatif

Pour la chronologie, les parseurs winreg de Plaso ajoutent les LastWrite et les artefacts décodés à une super timeline.

Erreurs fréquentes

• Analyser une ruche sale sans ses journaux : l'activité la plus récente, souvent la plus pertinente, manque.
• Lire littéralement les chemins CurrentControlSet dans une ruche hors ligne, ou supposer ControlSet001 sans vérifier Select.
• Prendre le LastWrite pour l'heure d'écriture d'une valeur : c'est l'heure de la dernière modification de la clé, quelle qu'en soit la raison.
• Oublier UsrClass.dat : les ShellBags et les détournements COM par utilisateur s'y trouvent, pas dans NTUSER.DAT.
• Attribuer une ruche utilisateur au mauvais compte : rattachez chaque dossier de profil à son SID via ProfileList ; un compte renommé garde l'ancien nom de dossier.
• Mélanger les fuseaux horaires : certains horodatages internes sont en heure locale. Relevez le fuseau du système dans la ruche SYSTEM avant de bâtir une chronologie.
• Compter sur RegBack sous Windows 10 1803 et versions ultérieures.

Méthode pratique

1. Collectez chaque ruche avec ses .LOG1/.LOG2 : SAM, SECURITY, SOFTWARE, SYSTEM, DEFAULT, Amcache, ainsi que NTUSER.DAT et UsrClass.dat pour chaque profil. Ajoutez les ruches des shadow copies si elles existent.
2. Calculez les hash et préservez les originaux ; travaillez sur des copies.
3. Rejouez les journaux de transactions (Registry Explorer, RECmd ou regipy) et notez quelles ruches étaient sales.
4. Profilez le système : Select\Current, nom de machine, fuseau horaire, build de l'OS, dernier arrêt, interfaces réseau. Inscrivez le fuseau horaire en tête de vos notes.
5. Cartographiez les utilisateurs : comptes SAM et SID de ProfileList rapprochés des chemins de profil et des ruches.
6. Extrayez en masse avec RECmd et un batch comme Kroll_Batch.reb ; chargez le CSV dans Timeline Explorer et filtrez sur la fenêtre de l'incident.
7. Pivotez sur les découvertes : clés de persistance, exécution (BAM, ShimCache, UserAssist), activité utilisateur (RunMRU, TypedPaths, RecentDocs, ShellBags), périphériques (MountedDevices, USBSTOR).
8. Validez chaque découverte clé dans Registry Explorer, examinez les données brutes de la valeur et cherchez des clés supprimées à proximité.
9. Corrélez avec le système de fichiers et les journaux d'événements : une entrée de Registre est d'autant plus solide qu'un fichier Prefetch, un événement ou une entrée de la $MFT la confirme.
10. Documentez chaque découverte avec la ruche, le chemin complet de la clé, la valeur, les données et la source de l'horodatage (LastWrite ou interne).

Si vous débutez, commencez par Premiers pas en investigation forensique Windows et revenez ici une fois que vous avez une collecte de triage à analyser.