TL;DR. Ja. Ein ShimCache-Eintrag bleibt in der Registry erhalten, unabhängig davon, ob die Datei noch auf der Festplatte existiert. Das Löschen der Binärdatei löscht ihren ShimCache-Eintrag nicht. Genau deshalb ist das Artefakt so nützlich, um Tools zu fangen, die ein Angreifer abgelegt, benutzt und gewischt hat.
Der Cache speichert einen Pfad und einen Zeitstempel in einem Registry-Wert. Dieser Wert hat keine Verbindung zurück zum Dateisystem. Wenn NTFS die ausführbare Datei freigibt, bewegen sich die Registry-Daten nicht. Was der ganze Grund ist, warum das Artefakt es wert ist, gezogen zu werden, und der ganze Grund, warum es manchmal der einzige überlebende Beweis eines Eindringens ist.
Kurze Antwort: Ja
Der ShimCache speichert einen Pfad plus die $STANDARD_INFORMATION-mtime der Datei innerhalb des Werts unter HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Dieser Datensatz hat keine Verbindung zurück zum Dateisystem. Wenn die ausführbare Datei gelöscht wird, gibt NTFS die Datei frei. Der Registry-Wert bleibt unangetastet. Der Eintrag bleibt, bis er entweder von neueren Einträgen verdrängt wird (der Cache fasst bis zu ~1.024) oder der Wert selbst geleert wird.
Also kann eine Binärdatei, die ein Angreifer in C:\Users\Public\ abgelegt, ausgeführt und zehn Minuten später gelöscht hat, immer noch einen sauberen, lesbaren ShimCache-Eintrag hinterlassen, der den vollständigen Pfad zeigt, den sie einst belegte.
Warum das forensisch mächtig ist
Einträge gelöschter Dateien sind oft der einzige überlebende Beweis für Angreifer-Tooling:
- Ein umbenanntes
mimikatz.exe, gelöscht nach Diebstahl von Anmeldeinformationen. - Ein Staging-Archiv, entfernt nach Exfiltration.
- Ein Dropper, der sich nach der Installation einer Nutzlast selbst gelöscht hat.
- Eine
7z.exe-Kopie, die zum Bündeln von Daten vor der Übertragung verwendet wurde.
Die Datei ist weg. Der Cache-Pfad sagt dir, dass sie existierte, wo und (über den Last-Modified-Zeitstempel) verbindet sie mit einem Build. Das ist das Rückgrat von Malware mit dem ShimCache jagen und von Ransomware-Ermittlungen, in denen Angreifer ihre Tools routinemäßig wischen.
Quervergleich mit der MFT und dem USN-Journal. Wenn das Journal noch die Create-then-Delete-Sequenz trägt, hast du einen sauberen Timeline-Anker. Der Papierkorb hält diese fast nie (sie umgehen ihn), aber prüf trotzdem.
Wie lange überlebt ein Eintrag einer gelöschten Datei?
Zwei Grenzen gelten:
- Verdrängung. Der Cache ist bei rund 1.024 Einträgen begrenzt. Auf einem ausgelasteten Host kann starke Aktivität ausführbarer Dateien alte Einträge herausschieben. Auf einem ruhigen Server kann er Monate überleben.
- Flush-Timing. Neue Einträge persistieren erst beim sauberen Shutdown in den Hive. Wenn der Host seit dem Löschen nicht heruntergefahren wurde, ist der überlebende Eintrag möglicherweise nur im Speicher. Zieh ihn aus einem RAM-Dump, siehe den Leitfaden zur Speicherextraktion. Das Speicher- und Flush-Modell wird in wo der ShimCache gespeichert ist behandelt.
Was er nicht beweist
Ein Eintrag einer gelöschten Datei beweist, dass die Datei existierte und auf diesem Host untersucht wurde. Er beweist nicht, dass die Datei ausgeführt wurde, und er sagt dir nicht, wann sie gelöscht wurde. Der Zeitstempel ist die mtime der Datei, keine Löschzeit. Behandle ihn als starken Existenzzeugen und belege die Ausführung mit Prefetch oder AmCache. Siehe Beweist der ShimCache eine Ausführung?.
Um zu prüfen, welche Einträge auf einem Hive auf Dateien zeigen, die nicht mehr existieren, parse ihn mit dem Shimcache Parser und vergleiche die Pfade mit dem Live-Dateisystem (oder einem forensischen Image). Alles läuft lokal in deinem Browser.
Weiterführende Lektüre
- Mandiants Caching Out the Val. die Argumentation für den ShimCache als Zeugen gelöschter Tools.
- SANS DFIR program execution poster. wo der ShimCache zwischen den Ausführungsbeweisen sitzt.