fr

Comment acquérir un hive SYSTEM Windows pour une analyse hors ligne du ShimCache

6 min de lecture

TL;DR. Tu ne peux pas copy C:\Windows\System32\config\SYSTEM pendant que Windows tourne. Le fichier est verrouillé. Utilise FTK Imager, KAPE, reg save, un snapshot VSS ou Velociraptor sur un hôte vivant. Lis-le directement depuis un disque hors ligne monté pour du travail dead-box. Quand tu copies le fichier brut, récupère toujours SYSTEM.LOG1 et SYSTEM.LOG2 avec. Sans eux, tu lis des données périmées. reg save n'en a pas besoin.

L'erreur d'acquisition la plus fréquente que je vois dans les preuves entrantes, c'est l'analyste qui a copié SYSTEM et zappé les journaux de transactions. La deuxième la plus fréquente, c'est l'analyste qui a essayé xcopy sur un hôte vivant, a eu "The process cannot access the file because it is being used by another process", et est parti chercher une copie collectée par l'EDR qui datait de trois jours. Ni l'un ni l'autre n'a besoin d'arriver. Choisis une méthode, applique-la correctement, et passe à la suite.

Pourquoi tu ne peux pas juste le copier

Le noyau garde le hive SYSTEM ouvert en accès exclusif tant que Windows tourne. Un copy simple retourne l'erreur access denied. Même si tu contournes le verrou et lis les octets, l'OS en cours d'exécution garde les écritures registre récentes en mémoire jusqu'au prochain arrêt propre, ce qui veut dire que les entrées ShimCache les plus utiles ne sont pas dans le fichier que tu viens de récupérer. Le modèle de stockage et de flush mérite d'être lu avant de choisir la méthode.

Ton objectif est l'un des suivants :

  1. Contourner le verrou proprement sur l'hôte en exécution (NTFS brut, VSS ou copie forensique).
  2. Lire le fichier directement depuis une image disque hors ligne montée ou une VM en pause.
  3. Récupérer la copie en mémoire depuis un dump RAM. La seule manière d'obtenir les entrées de la session active.

Méthode 1 : dead box ou disque hors ligne monté

Le chemin le plus simple. Éteins ou monte en lecture seule et copie :

<DriveLetter>:\Windows\System32\config\SYSTEM
<DriveLetter>:\Windows\System32\config\SYSTEM.LOG1
<DriveLetter>:\Windows\System32\config\SYSTEM.LOG2

Les trois fichiers. Un parser robuste rejoue .LOG1 et .LOG2 avant de lire le hive principal, donc tu ne rates pas d'écritures non encore fusionnées. Saute-les et tu lis une vue périmée.

Méthode 2 : système vivant, copie de qualité forensique

Plusieurs outils contournent le verrou, chacun à sa manière : FTK Imager et KAPE lisent le fichier au niveau volume, reg save passe par l'API du registre, et esentutl /vss ou un snapshot VSS lisent depuis un cliché instantané :

  • FTK Imager. GUI, gratuit. "Obtain Protected Files" → "Custom" → sélectionne SYSTEM, SYSTEM.LOG1, SYSTEM.LOG2. Sortie vers un disque externe.
  • KAPE. Ligne de commande, scriptable. La cible RegistryHives récupère tous les hives pertinents plus les logs : 
    kape.exe --tsource C: --target RegistryHives --tdest C:\out
  • reg save. Intégré à Windows, nécessite une invite élevée. Il demande au noyau d'écrire le hive chargé, donc le résultat est propre et cohérent et n'a pas besoin des journaux de transactions. Si tu veux plutôt le fichier brut, esentutl /y /vss le copie depuis un cliché instantané temporaire (relance-le pour SYSTEM.LOG1 et SYSTEM.LOG2) : 
    reg save HKLM\SYSTEM C:\out\SYSTEM.hiv /y
esentutl /y C:\Windows\System32\config\SYSTEM /vss /d C:\out\SYSTEM
    N'utilise pas robocopy /B sur le système vivant. Le mode backup contourne les ACL de fichier, pas le verrou exclusif du noyau sur un hive chargé, donc la copie échoue avec une violation de partage. Garde-le pour une image montée ou un cliché instantané, p. ex. robocopy E:\Windows\System32\config C:\out SYSTEM SYSTEM.LOG1 SYSTEM.LOG2 /B avec l'image montée en E:.
  • Snapshot VSS. Un cliché instantané ponctuel depuis lequel tu peux lire. Utile quand tu as besoin d'une vue cohérente et que tu ne peux pas arrêter le système. vssadmin create shadow ne fonctionne que sous Windows Server ; sur un poste client, esentutl /y ... /vss (ci-dessus) le crée et le supprime pour toi, ou crée-le dans un PowerShell élevé avec Invoke-CimMethod -ClassName Win32_ShadowCopy -MethodName Create -Arguments @{Volume='C:\'}.

Les quatre méthodes produisent une copie exploitable. FTK Imager et KAPE sont ce que les relecteurs s'attendent à voir référencé dans la section méthodologie d'un rapport. reg save dépanne sans rien installer ; précise dans ton rapport qu'il écrit le contenu actuel du hive et non une copie octet par octet du fichier, donc les cellules supprimées et le slack ne sont pas conservés.

Méthode 3 : image mémoire

Le hive sur disque ne contient que les entrées persistées au dernier arrêt propre. Sur un hôte qui n'a pas été rebooté proprement depuis l'incident, les entrées les plus récentes sont en mémoire et nulle part ailleurs.

Capture la mémoire avec WinPmem, Magnet RAM Capture ou AVML. Puis extrais soit le hive SYSTEM, soit le ShimCache directement avec Volatility 3 :

# Extraire le hive registre
vol -f memory.raw windows.registry.hivelist
vol -f memory.raw windows.registry.hivedump --offset <addr>

# Ou ignorer le hive et lire le ShimCache directement depuis la mémoire
vol -f memory.raw windows.shimcachemem

Extraire le ShimCache d'un dump mémoire traite cela en profondeur, y compris le chemin de collecte live avec Velociraptor.

Méthode 4 : triage live à grande échelle

Velociraptor lit le hive verrouillé via un accès NTFS direct et le retourne pour analyse hors ligne. Pour une collecte sur toute la flotte, collecte Windows.Triage.Targets avec la cible RegistryHivesSystem (anciens serveurs : Windows.KapeFiles.Targets avec RegistryHives). Cela récupère le hive SYSTEM avec ses journaux de transactions ; télécharge le ZIP de la collecte et analyse-le hors ligne.

Pour un triage registre plus large au-delà du ShimCache, voir le registry parser.

Ne saute pas les journaux de transactions

Les écritures en attente vivent dans SYSTEM.LOG1 et SYSTEM.LOG2 jusqu'au prochain checkpoint. Le delta peut inclure exactement les entrées qui t'intéressent le plus. L'AppCompatCacheParser d'Eric Zimmerman rejoue les logs automatiquement, mais seulement s'ils sont à côté du hive. Le Shim Cache Parser de Mandiant et cet outil ne rejouent rien : ils lisent le fichier principal du hive tel quel. Pour eux, rejoue d'abord les logs avec rla.exe (Registry Log Applier) d'Eric Zimmerman ou Registry Explorer, puis parse le hive nettoyé.

Si tu as collecté un hive il y a des mois sans les logs et tu as besoin de savoir ce qui manque : la réponse est "la partie la plus intéressante". Ré-acquiers si possible.

Puis parse-le

Dépose le hive SYSTEM dans le Shimcache Parser. Il prend ce seul fichier ; si le hive est dirty, rejoue d'abord ses .LOG1 et .LOG2 avec rla.exe ou Registry Explorer. Il tourne entièrement dans ton navigateur, sans étape de téléversement, et gère toutes les versions Windows de XP à Windows 11. Pour les détails de format, voir la référence du format binaire Windows 10/11.

Lectures complémentaires

Articles liés