Was der ShimCache-Zeitstempel tatsächlich bedeutet (und was nicht)

TL;DR. Der ShimCache-Zeitstempel ist die $STANDARD_INFORMATION-Last-Modified-Zeit der ausführbaren Datei, kopiert vom Dateisystem. Nicht die Zeit, zu der sie ausgeführt wurde. Nicht die Zeit, zu der sie gecacht wurde. Behandle ihn als Eigenschaft der Datei, niemals als Ereignis auf einer Timeline.

Der häufigste Fehler in der ShimCache-Analyse ist, die Zeitstempelspalte als "wann das lief" zu lesen. Sie ist es nicht. Ich habe Analysten beobachtet, die diese Interpretation Kunden und Regulierern vorlegten, und ich habe den Bericht im Review von jedem zerlegen sehen, der NTFS halbwegs kennt. Sei nicht dieser Analyst.

Was der Zeitstempel tatsächlich ist

Jeder Eintrag speichert die $STANDARD_INFORMATION-Last-Modified-Zeit der Datei (SI mtime), wie sie auf dem NTFS-Volume in dem Moment war, in dem Windows den Eintrag aufzeichnete. Direkte Kopie eines Dateisystem-Attributs. Sagt nichts über Prozesserstellung, Modulladen oder Shutdown.

Drei direkte Konsequenzen:

Eine Binärdatei, die letztes Jahr gebaut und heute ausgeführt wird, zeigt das Datum vom letzten Jahr.
Eine Datei, die mit einem Tool kopiert wurde, das Zeitstempel erhält, behält ihre Original-mtime, nicht die Kopierzeit.
Zwei Hosts, auf denen dieselbe signierte Binärdatei läuft, zeigen denselben Zeitstempel, weil er eine Eigenschaft der Datei ist, nicht einer der Maschinen.

Warum er nicht die Ausführungszeit ist

Windows fügt einen Cache-Eintrag hinzu, wenn es eine Datei aus Gründen der Anwendungskompatibilität untersucht. Oft, aber nicht immer zeitgleich mit der Ausführung. Selbst wenn es zusammenfällt, speichert der Cache die mtime der Datei, nicht den Moment der Untersuchung. Also beantwortet der Zeitstempel "wann wurde diese Datei zuletzt geändert?" und niemals "wann lief sie?" Die Ausführung-vs-Existenz-Unterscheidung wird ausführlich in Beweist der ShimCache die Ausführung? behandelt.

Wenn du eine echte Ausführungszeit brauchst, brauchst du Prefetch-Laufzeiten, AmCache-First-Run, Security 4688 oder Sysmon Event ID 1. Der Cache kann dir das nicht geben.

Wann der Zeitstempel trotzdem wertvoll ist

Er ist schwach als Ereigniszeit, aber stark als Identitätsanker:

Tampering-Erkennung. Wenn eine System-Binärdatei wie svchost.exe eine mtime zeigt, die nicht zum Patch-Level des Hosts passt, wurde diese Datei ausgetauscht. Quervergleich mit dem $FILE_NAME-Attribut der MFT, das schwerer zu stompen ist.
Build-Korrelation. Malware, die in einer Kampagne kompiliert wurde, teilt oft einen mtime-Cluster über Opfer hinweg. Nützlich, um Vorfälle demselben Akteur zuzuordnen.
Ordnung, mit Vorsicht. Innerhalb eines Hosts werden Einträge in grober Reihenfolge der Insertion gespeichert. Die Reihenfolge ist verlässlicher als die absoluten Zeitstempel zum Sequenzieren von Aktivität. Aber Reihenfolge ist keine Zeit, und die Insertion-Sequenz wird beim Boot zurückgesetzt.

Wie Angreifer ihn missbrauchen

Weil es nur ein Dateisystem-Attribut ist, ist es trivial fälschbar. Timestomping (eine mtime auf 2009-07-14 setzen, das klassische kernel32.dll-Datum) lässt einen Dropper unter Windows-Systemdateien aufgehen. Der Cache zeichnet den gestompten Wert treu auf, also ist ein sauberer 2009-Zeitstempel auf einem Pfad in C:\Users\Public\ selbst ein Warnsignal. Anti-Forensik-Muster sind in Können Angreifer den ShimCache leeren? katalogisiert.

Das $FILE_NAME-Attribut der MFT behält in der Regel die wahre Erstellungszeit, selbst nachdem $STANDARD_INFORMATION gestompt wurde. Der MFT-Parser geht den Vergleich durch. Das USN-Journal erfasst das ursprüngliche Create-Event in den meisten Fällen ebenfalls.

Ihn richtig in einer Timeline nutzen

Setze die ShimCache-mtime in eine separate Spalte von Ereigniszeiten. Verschmelze sie nie mit der Haupt-Timeline, als wäre sie eine Aktion. Belege die Sequenzierung mit Artefakten, die tatsächlich Ereigniszeiten tragen: Prefetch-Laufzeiten, AmCache-Install / First-Run, Security 4688, Sysmon Event ID 1. Der vollständige Querverweis steht in Prefetch, AmCache, ShimCache: Eine Kurzreferenz.

Um die Rohwerte selbst zu inspizieren, leg einen SYSTEM-Hive in den Shimcache Parser. Er zeigt die exakt gespeicherte mtime pro Eintrag, in deinem Browser, mit nichts hochgeladen.

Weiterführende Lektüre

Mandiants Caching Out the Val. das ursprüngliche Write-up, das den forensischen Nutzen des Artefakts definiert hat.
Eric Zimmermans AppCompatCacheParser. Referenzparser, dessen Ausgabe dieselbe mtime-Semantik verwendet.