de

Den Windows-ShimCache (AppCompatCache) verstehen

3 Min. Lesezeit

Die meisten Analysten begegnen dem ShimCache auf dieselbe Weise: Jemand im Team sagt "zieh den AppCompatCache, schau, ob die Datei drin ist", und das funktioniert oft genug, dass das Artefakt einen Ruf bekommt, den es nicht ganz verdient. Ich habe genug Stunden in Fallreviews über ShimCache-Einträge gestritten, um zu wissen, dass das Artefakt sein Gewicht wert ist, aber nur, wenn man es als das behandelt, was es tatsächlich ist. Kein Ausführungsprotokoll. Kein Prozess-Audit. Eine Liste ausführbarer Dateien, die Windows genau genug betrachtet hat, um zu entscheiden, ob ein Kompatibilitäts-Shim greifen soll.

Das ist die Einordnung. Der Rest ist Mechanik.

Was der Cache tatsächlich aufzeichnet

Der Application Compatibility Cache, fast immer als ShimCache oder AppCompatCache abgekürzt, liegt im SYSTEM-Hive und hält auf modernem Windows bis zu rund 1.024 Einträge. Jeder Eintrag enthält den vollständigen Dateipfad einer ausführbaren Datei, die $STANDARD_INFORMATION-Last-Modified-Zeit der Datei und (in älteren Versionen) ein Flag, das beschreibt, ob die Binärdatei tatsächlich ausgeführt wurde. Dieses Flag gibt es unter Windows 10 und 11 nicht mehr. Tu so, als hätte es nie existiert.

Windows baut den Cache bei jedem Boot im Speicher auf und schreibt ihn nur bei einem sauberen Shutdown auf die Festplatte. Ein BSOD, ein Hard-Reset oder ein VM-Kill auf Hypervisor-Ebene frisst alles, was im flüchtigen Speicher lag. Diese eine Tatsache erklärt die Hälfte der "aber ich habe die Binärdatei in Produktion gesehen"-Geschichten, die zu "der On-Disk-Hive zeigt nichts"-Tickets werden.

Wo er liegt

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache

Das abschließende AppCompatCache ist ein Wert, kein Unterschlüssel. Sein Inhalt ist ein einzelner Binär-Blob, dessen Layout sich bei jedem größeren Windows-Release geändert hat: XP, 7, 8, 8.1 und die 10/11-Familie verwenden alle unterschiedliche Schemata. Offline parsen bedeutet, den SYSTEM-Hive (plus seine SYSTEM.LOG1- und SYSTEM.LOG2-Transaktionsprotokolle) zu ziehen und den Blob gegen die korrekte Version zu dekodieren. Dieses Tool parst diese eine SYSTEM-Hive-Datei in deinem Browser, ohne Upload. Die Logs spielt es nicht ab: Ist der Hive dirty, spiele sie vorher mit Eric Zimmermans rla.exe ein.

Warum Ermittler darauf zurückgreifen

Der ShimCache verdient sein Geld, weil er überlebt. Ein Angreifer kann eine Binärdatei ablegen, ausführen, löschen, den Prefetch-Ordner leeren, und der ShimCache hält trotzdem den vollständigen Pfad fest. Das macht ihn zu einem starken Existenzzeugen für:

  • Malware, die bereits von der Festplatte gewischt wurde.
  • Umbenannte System-Binärdateien, die als Living-off-the-Land-Payloads verwendet werden.
  • Tooling, das von einem Netzwerkfreigabe-Share gestartet wurde, das niemand lokal heruntergeladen hat.

Kombiniere die Pfaddaten mit AmCache für die Hash-Zuordnung, und du kannst auf Threat Intel pivoten, selbst wenn die Datei längst weg ist.

Drei Dinge, die Leuten zum Verhängnis werden

  1. Der Zeitstempel ist die mtime der Datei, nicht der Ausführungszeitpunkt. Timestomping ändert, was der Cache aufzeichnet.
  2. Ein Eintrag ist kein Beweis für eine Ausführung. Der Win10/11-Cache hat überhaupt kein Ausführungs-Flag.
  3. Der Cache wird nur bei sauberem Shutdown geleert. Harte Reboots zerstören aktuelle Einträge lautlos.

Behandle jede Zeile als Hypothese. Bestätige sie mit Prefetch, AmCache, EVTX / Sysmon oder Registry-Hives, bevor du etwas Definitives in einen Bericht schreibst.

Wie es weitergeht

Der Rest des Blogs ist in zwei Cluster gegliedert.

Den ShimCache verstehen

In Ermittlungen einsetzen