TL;DR. Der ShimCache-Zeitstempel ist die $STANDARD_INFORMATION-Änderungszeit der ausführbaren Datei, vom Dateisystem kopiert — nicht der Ausführungszeitpunkt, nicht der Cache-Zeitpunkt. Behandeln Sie ihn als Eigenschaft der Datei, niemals als Ereignis auf einer Zeitleiste.
Der häufigste Fehler in der ShimCache-Analyse ist, die Zeitstempelspalte als „wann das lief" zu lesen. Das ist sie nicht. Diese Fehldeutung hat schon falsche Zeiten in echte Incident-Reports gebracht. Dieser Beitrag erklärt präzise, was der Wert ist und wie man ihn ohne falschen Schluss verwendet.
Was der Zeitstempel wirklich ist
Jeder ShimCache-Eintrag speichert die letzte Änderungszeit ($STANDARD_INFORMATION-mtime) der ausführbaren Datei, so wie sie auf dem NTFS-Volume war, als Windows den Eintrag erfasste. Es ist eine direkte Kopie eines Dateisystem-Attributs. Sie sagt nichts über Prozesserstellung, Modul-Laden oder Herunterfahren.
Drei unmittelbare Folgen:
- Eine letztes Jahr kompilierte und heute ausgeführte Binärdatei zeigt das Datum von letztem Jahr.
- Eine mit einem zeitstempel-erhaltenden Tool kopierte Datei behält ihre ursprüngliche mtime, nicht die Kopierzeit.
- Zwei Hosts, die dieselbe signierte Binärdatei ausführen, zeigen den gleichen Zeitstempel — weil er eine Eigenschaft der Datei ist, nicht der Maschine.
Warum es nicht der Ausführungszeitpunkt ist
Windows fügt einen ShimCache-Eintrag hinzu, wenn es eine Datei aus Kompatibilitätsgründen untersucht — was oft, aber nicht immer, mit der Ausführung zusammenfällt. Selbst wenn es zusammenfällt, speichert der Cache die mtime der Datei, nicht den Moment der Untersuchung. Der Zeitstempel beantwortet also „Wann wurde diese Datei zuletzt geändert?" und niemals „Wann lief sie?". Die Unterscheidung Ausführung/Existenz wird ausführlich in Beweist der ShimCache, dass ein Programm ausgeführt wurde? behandelt.
Wann der Zeitstempel trotzdem wertvoll ist
Schwach als Ereigniszeit, stark als Identitätsanker:
- Manipulationserkennung. Zeigt eine System-Binärdatei wie
svchost.exeeine mtime, die nicht zum Patch-Stand des Hosts passt, wurde diese Datei ersetzt. - Build-Korrelation. In einer Kampagne kompilierte Malware teilt oft einen mtime-Cluster über Opfer hinweg — nützlich zum Gruppieren.
- Reihenfolge, mit Vorsicht. Auf einem Host werden Einträge in grober Einfügereihenfolge gespeichert. Die Reihenfolge ist für die Sequenzierung verlässlicher als die absoluten Zeitstempel.
Wie Angreifer ihn missbrauchen
Da es nur ein Dateisystem-Attribut ist, lässt es sich trivial fälschen. Timestomping (z. B. eine mtime auf den 2009-07-14 setzen, das klassische kernel32.dll-Datum) lässt einen Dropper unter den Windows-Systemdateien verschwinden. Der ShimCache zeichnet den gefälschten Wert getreu auf — ein „sauberer" 2009-Zeitstempel auf einem Pfad in C:\Users\Public\ ist somit selbst ein Warnsignal. Anti-Forensik-Muster sind in Können Angreifer den ShimCache löschen? katalogisiert.
Ihn korrekt in einer Zeitleiste verwenden
Setzen Sie die ShimCache-mtime in eine separate Spalte getrennt von Ereigniszeiten — fügen Sie sie nie in die Haupt-Zeitleiste ein, als wäre sie eine Aktion. Untermauern Sie die Sequenz mit Artefakten, die tatsächlich Ereigniszeiten tragen: Prefetch-Laufzeiten, AmCache-Installation/Erstausführung, Security 4688, Sysmon 1. Die vollständige Querverweisung steht in Prefetch, AmCache, ShimCache: schnelle Referenz.
Um die Rohwerte selbst zu prüfen, ziehen Sie eine SYSTEM-Hive in den Shimcache Parser — er zeigt die exakt gespeicherte mtime pro Eintrag, im Browser, ohne Upload.
Weiterführende Quellen
- Mandiant: leveraging the ShimCache — die ursprüngliche Veröffentlichung, die den forensischen Einsatz des Artefakts definierte.
- Eric Zimmermans AppCompatCacheParser — Referenz-Parser, dessen Ausgabe dieselbe mtime-Semantik nutzt.