de

Wie man einen Windows-SYSTEM-Hive für die Offline-ShimCache-Analyse beschafft

5 Min. Lesezeit

TL;DR. Du kannst C:\Windows\System32\config\SYSTEM nicht copy-en, während Windows läuft. Die Datei ist gesperrt. Nutze FTK Imager, KAPE, reg save, einen VSS-Snapshot oder Velociraptor auf einem Live-Host. Lies sie für Dead-Box-Arbeit direkt von einer gemounteten Offline-Platte. Wenn du die Rohdatei kopierst, greif immer SYSTEM.LOG1 und SYSTEM.LOG2 mit ab. Ohne sie liest du veraltete Daten. reg save braucht sie nicht.

Der mit Abstand häufigste Erfassungsfehler, den ich in eingehenden Beweisen sehe, ist der Analyst, der SYSTEM kopiert und die Transaktionsprotokolle übersprungen hat. Der zweithäufigste ist der Analyst, der xcopy auf einem Live-Host versucht hat, "The process cannot access the file because it is being used by another process" bekam und nach einer von EDR gesammelten Kopie suchte, die drei Tage alt war. Keines davon muss passieren. Wähle eine Methode, wende sie richtig an und mach weiter.

Warum du es nicht einfach kopieren kannst

Der Kernel hält den SYSTEM-Hive mit exklusivem Zugriff offen, solange Windows läuft. Ein einfaches copy gibt den Access-Denied-Fehler zurück. Selbst wenn du den Lock umgehst und die Bytes liest, hält das laufende OS aktuelle Registry-Schreibvorgänge im Speicher, bis zum nächsten sauberen Shutdown, was bedeutet, dass die nützlichsten ShimCache-Einträge nicht in der Datei sind, die du gerade gegriffen hast. Das Speicher- und Flush-Modell ist lesenswert, bevor du entscheidest, welche Methode du benutzt.

Dein Ziel ist eines von:

  1. Den Lock auf dem laufenden Host sauber umgehen (rohes NTFS, VSS oder forensische Kopie).
  2. Die Datei direkt von einem gemounteten Offline-Disk-Image oder einer pausierten VM lesen.
  3. Die In-Memory-Kopie aus einem RAM-Dump wiederherstellen. Der einzige Weg, Einträge aus der aktiven Sitzung zu bekommen.

Methode 1: tote Kiste oder gemountete Offline-Platte

Der einfachste Weg. Herunterfahren oder schreibgeschützt mounten und kopieren:

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

Alle drei Dateien. Ein robuster Parser spielt .LOG1 und .LOG2 vor dem Lesen des Haupt-Hives ab, sodass du keine noch nicht gemergten Schreibvorgänge verpasst. Lass sie weg, und du liest eine veraltete Sicht.

Methode 2: Live-System, forensische Kopie

Mehrere Tools umgehen die Sperre, jedes auf seine Art: FTK Imager und KAPE lesen die Datei auf Volume-Ebene, reg save geht über die Registry-API, und esentutl /vss oder ein VSS-Snapshot lesen aus einer Schattenkopie:

  • FTK Imager. GUI, kostenlos. "Obtain Protected Files" → "Custom" → wähle SYSTEM, SYSTEM.LOG1, SYSTEM.LOG2. Ausgabe auf ein externes Laufwerk.
  • KAPE. Kommandozeile, skriptfähig. Das Target RegistryHives zieht alle relevanten Hives plus Logs: 
    kape.exe --tsource C: --target RegistryHives --tdest C:\out
  • reg save. In Windows eingebaut, braucht eine erhöhte Eingabeaufforderung. Es lässt den Kernel den geladenen Hive herausschreiben, das Ergebnis ist also sauber und konsistent und braucht keine Transaktionslogs. Willst du stattdessen die Rohdatei, kopiert esentutl /y /vss sie aus einer temporären Schattenkopie (für SYSTEM.LOG1 und SYSTEM.LOG2 erneut ausführen): 
    reg save HKLM\SYSTEM C:\out\SYSTEM.hiv /y
esentutl /y C:\Windows\System32\config\SYSTEM /vss /d C:\out\SYSTEM
    Nutze robocopy /B nicht auf dem laufenden System. Der Backup-Modus umgeht Datei-ACLs, aber nicht die exklusive Sperre des Kernels auf einem geladenen Hive, die Kopie scheitert also mit einer Freigabeverletzung. Heb es dir für ein gemountetes Image oder eine Schattenkopie auf, z. B. robocopy E:\Windows\System32\config C:\out SYSTEM SYSTEM.LOG1 SYSTEM.LOG2 /B mit dem Image als E:.
  • VSS-Snapshot. Eine Point-in-Time-Schattenkopie, aus der du lesen kannst. Nützlich, wenn du eine konsistente Sicht brauchst und das System nicht herunterfahren kannst. vssadmin create shadow funktioniert nur unter Windows Server; auf einem Client erstellt und entfernt esentutl /y ... /vss (siehe oben) sie für dich, oder du erstellst sie in einer erhöhten PowerShell mit Invoke-CimMethod -ClassName Win32_ShadowCopy -MethodName Create -Arguments @{Volume='C:\'}.

Alle vier Methoden erzeugen eine verwertbare Kopie. FTK Imager und KAPE sind das, was Reviewer im Methodenteil eines Berichts erwartet zu sehen. reg save funktioniert im Notfall ohne Installation; vermerke im Bericht, dass es den aktuellen Inhalt des Hives herausschreibt statt einer bitgenauen Kopie der Datei, gelöschte Zellen und Slack-Space bleiben also nicht erhalten.

Methode 3: Speicherabbild

Der On-Disk-Hive enthält nur die beim letzten sauberen Shutdown persistierten Einträge. Auf einem Host, der seit dem Vorfall nicht sauber neu gestartet wurde, sind die aktuellsten Einträge im Speicher und nirgendwo sonst.

Erfasse Speicher mit WinPmem, Magnet RAM Capture oder AVML. Dann extrahiere entweder den SYSTEM-Hive oder zieh den ShimCache direkt mit Volatility 3:

# Den Registry-Hive extrahieren
vol -f memory.raw windows.registry.hivelist
vol -f memory.raw windows.registry.hivedump --offset <addr>

# Oder den Hive überspringen und den ShimCache direkt aus dem Speicher lesen
vol -f memory.raw windows.shimcachemem

Den ShimCache aus einem Memory-Dump extrahieren behandelt das ausführlich, einschließlich des Velociraptor-Live-Sammelpfads.

Methode 4: Live-Triage in großem Maßstab

Velociraptor liest den gesperrten Hive über direkten NTFS-Zugriff und gibt ihn für die Offline-Analyse zurück. Für flottenweite Sammlung sammle Windows.Triage.Targets mit dem Target RegistryHivesSystem (ältere Server: Windows.KapeFiles.Targets mit RegistryHives). Das holt den SYSTEM-Hive zusammen mit seinen Transaktionslogs; lade das Collection-ZIP herunter und analysiere es offline.

Für breitere Registry-Triage jenseits des ShimCache siehe den registry parser.

Überspring die Transaktionsprotokolle nicht

Ausstehende Schreibvorgänge liegen in SYSTEM.LOG1 und SYSTEM.LOG2 bis zum nächsten Checkpoint. Die Delta kann genau die Einträge enthalten, die dir am wichtigsten sind. Eric Zimmermans AppCompatCacheParser spielt die Logs automatisch ab, aber nur, wenn sie neben dem Hive liegen. Mandiants Shim Cache Parser und dieses Tool spielen nichts ab: Sie lesen die primäre Hive-Datei so, wie sie ist. Für diese spielst du die Logs vorher mit Eric Zimmermans rla.exe (Registry Log Applier) oder Registry Explorer ein und parst den bereinigten Hive.

Wenn du einen Hive vor Monaten ohne die Logs gesammelt hast und wissen musst, was fehlt: Die Antwort ist "das interessanteste Stück". Re-akquiriere, wenn möglich.

Dann parsen

Leg den SYSTEM-Hive in den Shimcache Parser. Er nimmt genau diese eine Datei; ist der Hive dirty, spiele seine .LOG1 und .LOG2 vorher mit rla.exe oder Registry Explorer ein. Er läuft komplett im Browser, ohne Upload-Schritt, und beherrscht jede Windows-Version von XP bis Windows 11. Für die Formatdetails siehe die Windows-10/11-Binärformat-Referenz.

Weiterführende Lektüre

Verwandte Artikel