de

Den ShimCache aus einem Memory-Dump extrahieren

3 Min. Lesezeit

TL;DR. Der ShimCache lebt im Speicher. Der On-Disk-SYSTEM-Hive enthält nur Einträge, die beim letzten sauberen Shutdown geleert wurden. Um die Einträge der aktiven Sitzung von einem laufenden oder abgestürzten Host wiederherzustellen, führe Volatility 3s windows.shimcachemem gegen einen RAM-Dump aus, oder zieh live mit Velociraptors Windows.Registry.AppCompatCache-Artefakt.

Der Cache lebt im flüchtigen Speicher, während Windows läuft. Er wird nur beim sauberen Shutdown in den SYSTEM-Hive geschrieben. Das bedeutet, ein Speicher-Image ist oft der einzige Ort, an dem ShimCache-Einträge der aktuellen Sitzung zu finden sind, was genau die Einträge sind, die für einen aktiven Vorfall am wichtigsten sein dürften. Der Speicher-Timing-Post deckt das Warum ab.

Wann die Speicher-Kopie wichtiger ist als die Festplatte

Du willst den In-Memory-Cache, wenn:

  • Der Host seit dem Vorfall nicht sauber heruntergefahren wurde. Die meisten Hard-Reboots, BSODs und erzwungenen Power-Offs hinterlassen den On-Disk-ShimCache veraltet.
  • Du Anti-Forensik vermutest. Ein Angreifer, der den On-Disk-Hive bearbeitet hat, hat die In-Memory-Kopie, die jede Sitzung neu aufgebaut wird, vielleicht nicht angefasst. Siehe Anti-Forensik-Erkennung.
  • Du Einträge brauchst, die beim letzten Flush aus dem On-Disk-Hive verdrängt wurden. Das 1.024-Einträge-Cap rotiert alte Einträge heraus, aber sie können unter bestimmten Bedingungen immer noch im Speicher sein.

Mit Volatility 2

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

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

Geht die AppCompatCache-Strukturen innerhalb der In-Memory-Repräsentation des SYSTEM-Hives durch und gibt (mtime, path)-Zeilen aus, wie es ein Offline-Parser tun würde. Der Plugin-Quellcode liegt im Volatility-2-Repo.

Mit Volatility 3

Volatility 3 liefert das als windows.shimcachemem aus:

vol -f memory.raw windows.shimcachemem

Keine Profil-Auswahl mehr. Vol 3 findet das OS automatisch heraus. Die Volatility-3-Docs dokumentieren das Plugin neben dem Rest des Windows-Artefakt-Satzes. Solange du den Dump offen hast, kannst du gleich auch Prozesse, Netzwerkverbindungen und Modullisten ziehen. Der RAM-Parser deckt den breiteren Memory-Forensik-Workflow ab.

Mit Velociraptor

Zum Sammeln in großem Maßstab statt zur Analyse eines einzelnen Dumps liest Velociraptors Windows.Registry.AppCompatCache-Artefakt den In-Memory-ShimCache direkt von einem laufenden Endpunkt über die Live-Registry-Sicht. Derselbe Cache, den das OS beim Shutdown geleert hätte, ohne auf den Shutdown zu warten.

Die beiden Sichten kombinieren

In der Praxis hast du oft beide:

  • Den In-Memory-Cache von Volatility oder Velociraptor.
  • Den On-Disk-Cache aus dem SYSTEM-Hive auf demselben Host.

Die Speicher-Kopie ist zu jedem Zeitpunkt, an dem kein sauberer Shutdown stattgefunden hat, eine Obermenge der Festplattenkopie. Aber die Festplattenkopie kann Einträge enthalten, die nach langer Uptime bereits aus dem Speicher verdrängt wurden. Zieh beide, dedupliziere nach (path, mtime) und füttere die Vereinigung in deinen Hunting-Workflow.

Wenn die beiden Sichten bei Pfaden oder Zeitstempeln für denselben Slot nicht übereinstimmen, ist das ein Manipulationsindikator. Siehe Anti-Forensik.

Nützliche nächste Schritte

Sobald du die Einträge hast:

  • Nutze den Shimcache Parser für schnelle Offline-Triage eines extrahierten Hives. Läuft in deinem Browser, ohne Upload.
  • Siehe die Binärformat-Referenz, falls du den rohen Blob selbst dekodierst.
  • Siehe Beweis der Ausführung, bevor du behauptest, ein aus dem Speicher wiederhergestellter Eintrag bedeute, dass ein Programm lief.
  • Carve pagefile.sys, wenn du vermutest, dass der Cache teilweise aus Speicher und Festplatte gewischt wurde; Fragmente überleben manchmal im Swap.

Weiterführende Lektüre

Verwandte Artikel