ShimCache aus einem Speicher-Dump extrahieren

3 Min. Lesezeit

TL;DR. Der ShimCache lebt im Speicher; die On-Disk-SYSTEM-Hive enthält nur Einträge, die beim letzten sauberen Shutdown geflusht wurden. Um die Einträge der aktuellen Session aus einem laufenden oder abgestürzten Host zu retten, lassen Sie Volatility 3s windows.shimcachemem (oder Velociraptors Windows.Registry.AppCompatCache-Artefakt) gegen ein Speicher-Image laufen.

Der ShimCache lebt im flüchtigen Speicher, solange Windows läuft, und wird erst bei einem sauberen Shutdown in die SYSTEM-Hive geschrieben (Details zum Timing). Das bedeutet: Ein Speicher-Image eines laufenden Hosts ist oft der einzige Ort, um ShimCache-Einträge der aktuellen Session zu finden — genau die Einträge, die für einen aktiven Vorfall am ehesten relevant sind.

Wann die Speicher-Kopie wichtiger ist als die Disk-Kopie

Sie wollen den ShimCache im Speicher, wenn:

  • Der Host seit dem Vorfall nicht sauber heruntergefahren wurde. Die meisten Hard-Reboots, BSODs und Force-Power-Offs hinterlassen den ShimCache in der SYSTEM-Hive veraltet.
  • Sie Anti-Forensik vermuten. Ein Angreifer, der die On-Disk-Hive editiert hat, hat die Speicher-Kopie eventuell nicht angefasst (sie wird in jeder Session neu aufgebaut). Siehe Anti-Forensik-Erkennung.
  • Sie Einträge brauchen, die beim letzten Flush aus der On-Disk-Hive verdrängt wurden. Die Obergrenze von 1.024 Einträgen rotiert ältere aus, sie können aber unter bestimmten Bedingungen noch im Speicher liegen.

Mit Volatility 2

Das klassische Plugin ist shimcachemem. Gegen ein Speicher-Image XP–Win10:

vol.py -f memory.raw --profile=Win10x64_19041 shimcachemem

Es läuft die AppCompatCache-Strukturen in der In-Memory-Darstellung der SYSTEM-Hive ab und gibt (mtime, Pfad)-Zeilen aus wie ein Offline-Parser. Quelle und Nutzungshinweise liegen im Volatility-2-Repo.

Mit Volatility 3

Volatility 3 trägt das als windows.shimcachemem weiter:

vol -f memory.raw windows.shimcachemem

Keine Profilauswahl mehr (Vol 3 erkennt das OS automatisch). Die Volatility-3-Dokumentation dokumentiert das Plugin zusammen mit den übrigen Windows-Artefakten.

Mit Velociraptor

Wer in Größe sammelt statt einen einzelnen Dump zu analysieren: Velociraptors Windows.Registry.AppCompatCache liest den In-Memory-ShimCache direkt vom laufenden Endpoint über die Live-Registry-Sicht. Das ist derselbe ShimCache, den das OS beim Shutdown geflusht hätte — ohne auf den Shutdown zu warten.

Beide Sichten kombinieren

In der Praxis haben Sie oft:

  • den ShimCache im Speicher von einem Volatility-Plugin oder einer Velociraptor-Sammlung,
  • den ShimCache auf Disk aus der SYSTEM-Hive desselben Hosts.

Solange kein sauberer Shutdown stattfand, ist die Speicher-Kopie eine Obermenge der Disk-Kopie — die Disk-Kopie kann aber Einträge enthalten, die nach langer Uptime bereits aus dem Speicher gedrängt wurden. Beide ziehen, nach (Pfad, mtime) deduplizieren und die Vereinigung in den Hunting-Workflow einspeisen.

Nützliche Folgeschritte

Wenn Sie die Einträge haben:

  • Den Shimcache Parser für eine schnelle Offline-Triage einer extrahierten Hive nutzen — läuft im Browser, ohne Upload.
  • Die Binärformat-Referenz ansehen, wenn Sie den Blob selbst dekodieren.
  • Den Proof-of-Execution-Beitrag lesen, bevor Sie aus einem aus dem Speicher gewonnenen Eintrag auf Ausführung schließen.

Weiterführende Quellen

Verwandte Artikel