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

3 Min. Lesezeit

TL;DR. Angreifer bekämpfen den ShimCache vor allem dadurch, dass sie saubere Shutdowns vermeiden (damit er nie geflusht wird). Direkte Registry-Edits hinterlassen den Blob meist malformiert. Manipulation erkennen Sie an ungewöhnlich kurzen Caches, fehlenden Dauergästen, malformierten Eintragsgrößen oder Divergenz zwischen Speicher und Disk.

Der ShimCache lässt sich schwerer manipulieren als die meisten Windows-Artefakte, ist aber nicht unantastbar. Dieser Beitrag geht durch, was Angreifer tatsächlich versuchen, warum die meisten Versuche Spuren hinterlassen und wie sich Manipulation in der Analyse erkennen lässt.

Das Anti-Forensik-Werkzeugset des Angreifers

1. Harter Reboot vor dem Flush. Die sauberste „Anti-Forensik" gegen den ShimCache ist, Windows gar nicht erst die Chance zu geben, ihn zu schreiben. Wer ein hartes Power-Off erzwingt (oder eine VM auf Hypervisor-Ebene killt), verliert den In-Memory-ShimCache der Session. Die On-Disk-Hive behält das, was beim vorherigen sauberen Shutdown geflusht wurde. Mechanik siehe Wann der Cache geschrieben wird.

2. Direkte Registry-Editierung des Value-Blobs. Ein privilegierter Angreifer kann den Wert HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache überschreiben. Theoretisch lassen sich damit einzelne Einträge entfernen — praktisch ist das Binärlayout nicht trivial genug, dass schlechte Edits in der Regel einen malformierten Blob hinterlassen.

3. Ersetzen der SYSTEM-Hive offline. Wenn der Angreifer das System offline nehmen kann, kann er die Hive austauschen. Bei opportunistischen Einbrüchen selten, in staatlichen Fällen kommt es vor.

4. Time-Stomping der Binärdatei. Weil der ShimCache den $STANDARD_INFORMATION-mtime der Datei speichert, verschiebt ein Angreifer, der die Datei vor der Windows-Prüfung umtimestampt, den gecachten Zeitstempel. Der ShimCache selbst lügt nicht — die erfassten Metadaten waren bereits manipuliert.

5. Wischen von AmCache und Prefetch. Angreifer, die die korroborierenden Artefakte kennen, löschen sie häufig auch und lassen den ShimCache als einzigen Zeugen — in der Hoffnung, dass er aus den Gründen unseres Proof-of-Execution-Beitrags entwertet wird.

Erkennungssignale

Bei Manipulationsverdacht achten Sie auf:

  • Ungewöhnlich kurzer ShimCache. Windows füllt den Cache im Normalbetrieb auf ~1.024 Einträge. Ein Blob mit nur wenigen Einträgen auf einem tagelang laufenden System ist ein starkes Manipulationssignal.
  • Fehlende Dauergäste. Mehrere Windows-Binaries tauchen verlässlich in fast jedem ShimCache auf (versionsabhängig: Shell, Scheduled-Task-Helfer, Windows-Update-Tooling). Ihr Fehlen auf einer genutzten Workstation ist verdächtig.
  • Malformierte Eintragsgrößen. Ein Blob, der mittendrin scheitert und im Rest mit Nullen oder Müll gefüllt ist, ist ein klassisches Indiz für unsaubere Editierung. Der Shimcache Parser bringt das als explizite Fehlermeldung heraus.
  • Divergenz Speicher / Disk. Vergleichen Sie den aus dem Speicher gewonnenen ShimCache (Anleitung) mit der On-Disk-Hive. Einträge, die im Speicher, aber nicht auf Disk sind, können ein Hard-Reboot bedeuten — Einträge auf Disk, die der Speicher widerlegt (andere Pfade oder mtimes für denselben Slot), deuten auf direktes Schreiben in die Hive.
  • AmCache und ShimCache stimmen nicht überein. Wenn AmCache eine Ausführung zeigt, der entsprechende ShimCache aber leer ist, fragen Sie warum. ShimCache-Wipes, die AmCache nicht anrühren, sind häufig, weil Angreifer AmCache nicht immer kennen.

Was das Ermittlern sagt

Praktische Faustregeln:

  • Ein leerer oder fast leerer ShimCache ist Evidenz, nicht das Fehlen von Evidenz. Dokumentieren Sie ihn.
  • Speicher-Image ziehen, wann immer möglich. Es fängt häufig auf, was die Hive verloren hat.
  • Immer mit AmCache und Prefetch korroborieren (Referenz). Drei Artefakte sind viel schwerer konsistent zu wischen als eines.
  • Behaupten Sie nicht „der Angreifer hat den ShimCache gelöscht", ohne zu zeigen, was gelöscht wurde — Lücken in der Eintragszahl, fehlende Baseline-Binaries oder Speicher/Disk-Divergenz.

Weiterführende Quellen

Verwandte Artikel