TL;DR. Nutze Eric Zimmermans AppCompatCacheParser für Fallarbeit. Breiteste OS-Abdeckung, CSV-Ausgabe, gut getestet. Nutze Velociraptor für Live-Triage in Flottengröße. Nutze Mandiants Shim Cache Parser, wenn eine einfache Python-Referenz hilft. Nutze dieses Tool, wenn du null Installation und null Upload willst. Cross-validiere bei Unstimmigkeiten. Das Format ist heikel genug, dass zwei Parser gelegentlich Dinge unterschiedlich sehen.
Es gibt vier offene Tools, die für das ShimCache-Parsen zählen. Jedes hat seine Nische. Der Fehler, den ich Junior-Analysten machen sehe, ist, eines auszuwählen und es als Antwort für jeden Fall zu behandeln. Die richtige Antwort hängt davon ab, ob du skalierst, skriptest oder um zwei Uhr nachts vor einem einzelnen Hive sitzt.
Die vier Parser, die zählen
| Tool | Sprache | Distribution | Am besten für |
|---|---|---|---|
| Mandiant Shim Cache Parser | Python | Quellcode auf GitHub | Format lesen, individuelle Analysen skripten |
| Eric Zimmerman AppCompatCacheParser | C# / .NET | Einzelne Binärdatei | Fallarbeit. Verlässlichster Output für Produktivberichte. |
Velociraptor Windows.Registry.AppCompatCache | VQL | Velociraptor-Server | Live-Erfassung in Flottengröße |
| Shimcache Parser (dieses Tool) | Rust → WebAssembly | Nur Browser, keine Installation | Schnelle Triage ohne Setup, keine Daten verlassen die Maschine |
Wann was nehmen
Eric Zimmermans AppCompatCacheParser
Der De-facto-Standard für Offline-Analysen. Deckt jede Windows-Variante von XP bis Windows 11 ab, spielt SYSTEM-Transaktionsprotokolle automatisch ab und gibt CSV aus, das sauber in den Timeline Explorer fließt. Wenn deine Ausgabe in einen Endbericht geht, ist das das, was Reviewer erwarten, dass du genutzt hast.
AppCompatCacheParser.exe -f SYSTEM --csv .
Vorbehalte: Nur Windows-Binärdatei, benötigt .NET Framework oder Core, nicht für ad-hoc browserbasierte Triage gedacht.
Velociraptor
Wenn du ShimCache von Dutzenden oder Tausenden Hosts ziehen musst, gewinnt Velociraptor. Das Artefakt liest den In-Memory-Cache direkt von laufenden Endpunkten, was dieselbe Sicht ist, die das OS beim Shutdown geleert hätte, aber ohne auf den Shutdown zu warten. Siehe Den ShimCache aus einem Memory-Dump extrahieren für die Begründung.
Vorbehalte: erfordert Velociraptor-Infrastruktur. Overkill für einmalige Analysen.
Mandiant Shim Cache Parser
Der ursprüngliche Python-Proof-of-Concept. Weniger ausgefeilt als EZs Tool, aber nützlich, wenn du den Code lesen willst, um zu verstehen, wie genau das Format dekodiert wird, oder um eigene Analysen darum herum zu skripten. Die Ausgabe ist Klartext; integriere ihn mit anderen Python-Pipelines.
python ShimCacheParser.py -t -h /path/to/SYSTEM
Vorbehalte: erfordert Python 2.x oder einen Kompatibilitäts-Fork. CSV-/JSON-Ausgabe ist weniger ausgefeilt als EZs.
Dieser Shimcache Parser
Existiert für zwei Fälle, die die anderen nicht gut abdecken:
- Triage ohne Installation. Öffne die Seite, leg einen Hive ab, sieh Einträge. Nützlich, wenn du auf einem Host ohne DFIR-Tooling bist oder auf einem Laptop oder Leihgerät analysierst.
- Vertrauenssensible Analyse. Der Hive wird komplett in deinem Browser über WebAssembly geparst. Die Datei verlässt die Seite nie, trifft nie einen Server, taucht in keinem Log auf. Das zählt, wenn der Hive zu einem Kunden oder einem Fall gehört, in dem ein Upload nicht akzeptabel ist.
Kompromisse: kein Command-Line-Interface, keine Automatisierungs-Hooks. Nutze es für menschengetriebene Triage, nicht für Pipelines. Für Pipelines ist EZs Tool die richtige Antwort.
Cross-Validierung, wenn Parser nicht übereinstimmen
Das Binärformat verzeiht nichts. Die Windows-10/11-Layout-Referenz zeigt, warum ein einzelner Offset-Verzähler durch den Rest des Blobs kaskadieren kann. In der Praxis stimmen Parser meist überein, aber reale Hives liefern manchmal leicht von der Spezifikation abweichende Daten, und Parser sind sich uneinig bei:
- Bitness-Erkennung auf Win7-Hives. Der Header sagt nicht eindeutig x86 vs. x64, also wählen Parser heuristisch. Zwei Tools, die auf demselben Hive unterschiedliche Pfade produzieren, sind dein Indiz.
- Pfadnormalisierung. Backslash-Escaping, Groß-/Kleinschreibung von Laufwerksbuchstaben, führende
\??\-Marker. Verschiedene Parser normalisieren unterschiedlich. - Leere oder Platzhaltereinträge. Manche Tools geben leere Zeilen für ungenutzte Slots aus; andere überspringen sie.
Wenn es zählt, lass zwei Parser laufen und vergleiche. Die Kombinationen, zu denen ich greife:
- EZ + dieses Tool für schnellen Cross-Check.
- EZ + Mandiant für einen "Python vs. C#"-Sanity-Check.
- EZ + Velociraptor für "Live-In-Memory vs. On-Disk-Hive"-Vergleich.
Häufige Fallstricke
- Vergiss die Transaktionsprotokolle nicht.
SYSTEM.LOG1undSYSTEM.LOG2enthalten ausstehende Schreibvorgänge; ohne sie liest du einen veralteten Hive. EZs Tool spielt sie automatisch ab. Manche andere nicht. Siehe Einen SYSTEM-Hive beschaffen. - Vergleiche On-Disk- und In-Memory-ShimCache nicht direkt. Sie sind unterschiedliche Wahrheitsquellen. On-Disk hat nur den Stand des letzten sauberen Shutdowns. In-Memory hat die aktuelle Sitzung. Behandle sie als komplementär.
- Nimm keine Ausführung an. Kein Parser kann das beheben. Der Cache zeichnet eine Untersuchung auf, keine Ausführung.
Weiterführende Lektüre
- Eric Zimmermans AppCompatCacheParser. Referenzparser.
- Mandiants Shim Cache Parser. ursprüngliche Python-Implementierung.
- Velociraptor
Windows.Registry.AppCompatCache. VQL-Artefakt. - Windows 10/11 AppCompatCache deep dive auf Ø Security. erklärt, warum Parser gelegentlich nicht übereinstimmen.