de

Können Angreifer den ShimCache leeren? Anti-Forensik und Erkennung

4 Min. Lesezeit

TL;DR. Angreifer bekämpfen den ShimCache hauptsächlich, indem sie saubere Shutdowns vermeiden, sodass der Cache nie geleert wird. Direkte Registry-Edits hinterlassen den Blob meist fehlerhaft. Erkenne Manipulationen über ungewöhnlich kurze Caches, fehlende, immer vorhandene Windows-Binärdateien, fehlerhafte Eintragsgrößen oder Divergenz zwischen Speicher und Festplatte.

Der Cache ist schwieriger zu manipulieren als die meisten Windows-Artefakte. Nicht unmöglich. Nach ein paar Vorfällen bist du nicht mehr überrascht, was Angreifer versuchen, sondern überrascht, wie oft sie Fingerabdrücke hinterlassen. Hier ist der Katalog der Techniken, die ich tatsächlich gesehen habe, und was jede hinterlässt.

Was Angreifer wirklich versuchen

1. Hard-Reboot vor dem Flush. Die sauberste Anti-Forensik gegen den Cache ist, Windows nie die Chance zu geben, ihn zu schreiben. Erzwinge ein hartes Power-Off oder kille die VM am Hypervisor, und der In-Memory-ShimCache für diese Sitzung ist einfach verloren. Der On-Disk-Hive enthält weiterhin, was beim vorherigen sauberen Shutdown geleert wurde. Das ist mit Abstand das häufigste Muster in Ransomware-Einsätzen. Siehe wann der Cache geschrieben wird für den Mechanismus.

2. Direkte Registry-Edits am Wert-Blob. Ein Angreifer auf SYSTEM-Level kann HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache überschreiben. Theoretisch entfernt das spezifische Einträge. In der Praxis ist das Binärlayout komplex genug, dass Handarbeit den Blob meist fehlerhaft oder die Eintragsanzahl unsinnig hinterlässt.

3. Offline-Hive-Austausch. Wenn der Angreifer das System herunterfahren kann, kann er den SYSTEM-Hive komplett tauschen. Außerhalb staatlicher Akteure selten, aber kommt vor. Der registry parser kann dir zeigen, ob die SYSTEM-Hive-Zeitstempel und -Struktur mit dem Rest der Artefakte des Hosts konsistent sind.

4. Timestomping der Binärdatei. Weil der Cache die $STANDARD_INFORMATION-mtime der Datei speichert, verschiebt ein Angreifer, der die Binärdatei timestompt, bevor Windows sie untersucht, den gecacheten Zeitstempel. Der Cache lügt nicht; die Datei-Metadaten, die er erfasst hat, waren bereits manipuliert. Quervergleich mit dem $FILE_NAME-Attribut der MFT, das schwerer zu stompen ist.

5. Wischen begleitender Artefakte. Angreifer, die lernen, was ShimCache tut, leeren oft auch AmCache, Prefetch, EVTX und den Papierkorb und lassen den ShimCache als einsamen Zeugen zurück, in der Hoffnung, dass er aus den Gründen im Proof-of-Execution-Post abgetan wird.

Erkennungssignale

Wenn du Manipulationen vermutest, achte auf:

  • Ungewöhnlich kurzer Cache. Windows füllt den Cache im normalen Gebrauch auf rund 1.024 Einträge. Ein Blob mit einer Handvoll Einträgen auf einem System, das seit Tagen läuft, ist ein starkes Manipulationssignal.
  • Fehlende, immer vorhandene Einträge. Mehrere Windows-Binärdateien erscheinen je nach Version verlässlich in fast jedem ShimCache: Shell-Komponenten, Helfer für geplante Tasks, OS-Update-Tooling. Ihre Abwesenheit auf einer benutzten Workstation ist verdächtig.
  • Fehlerhafte Eintragsgrößen. Ein Blob, der mitten beim Parsen fehlschlägt, mit dem Rest des Puffers genullt oder mit Müll gefüllt, ist ein klassischer Indikator für plumpe Bearbeitung. Der Shimcache Parser zeigt das als expliziten Fehler.
  • Divergenz zwischen In-Memory und On-Disk. Vergleiche den aus einem RAM-Dump extrahierten Cache mit dem On-Disk-Hive (Extraktionsleitfaden). Einträge im Speicher, aber nicht auf der Festplatte, können einen Hard-Reboot bedeuten. Einträge auf der Festplatte, die dem Speicher widersprechen (andere Pfade oder mtimes für denselben Slot), deuten darauf hin, dass jemand in den Hive geschrieben hat.
  • AmCache- und ShimCache-Mismatch. AmCache zeigt, dass eine Binärdatei ausgeführt wurde, aber der ShimCache ist für diese Datei leer. Frag warum. Angreifer, die ShimCache wischen, vergessen oft, dass AmCache existiert.
  • Fußabdrücke von Anti-Forensik-Tools. Such in Prefetch, Sysmon Event ID 1 und im USN-Journal nach Hinweisen auf reg.exe, PowerShell Remove-ItemProperty oder Hive-Editoren von Drittanbietern im relevanten Fenster.

Was das Ermittlern sagt

Ein paar praktische Regeln, die ich in jedem Bericht durchsetze:

  • Behandle einen leeren oder fast leeren ShimCache als Beweis. Nicht als Abwesenheit von Beweisen. Dokumentiere es explizit.
  • Zieh wenn möglich einen RAM-Dump. Er fängt häufig ab, was der Hive verloren hat.
  • Belege immer mit AmCache und Prefetch. Siehe die Artefakt-Referenz. Drei Artefakte sind viel schwerer konsistent zu wischen als eines.
  • Behaupte nicht "der Angreifer hat den ShimCache gewischt", es sei denn, du kannst zeigen, was gewischt wurde. Zeige auf Lücken in der Eintragsanzahl, fehlende Baseline-Binärdateien oder Divergenz zwischen Speicher und Festplatte.

Weiterführende Lektüre

Verwandte Artikel