Timestomping mit dem NTFS-$LogFile erkennen

Q: Warum ist das $LogFile nützlich, um Timestomping zu erkennen?

Weil die Änderung selbst protokolliert wird. Ein UpdateResidentValue auf $STANDARD_INFORMATION trägt die neuen Zeitstempel in seinen Redo-Bytes und die vorherigen in seinen Undo-Bytes. So sehen Sie den Wert vor und nach dem Überschreiben, statt ihn aus einer Abweichung zu erschließen.

TL;DR. Timestomping-Werkzeuge schreiben $STANDARD_INFORMATION ($SI) meist über SetFileTime oder NtSetInformationFile neu. Der klassische Test — Erstellung in $SI früher als Erstellung in $FILE_NAME ($FN) — zeigt nur eine Abweichung. Das $LogFile zeigt das Überschreiben: ein UpdateResidentValue auf $SI mit den alten Zeiten in den Undo-Bytes und den neuen in den Redo-Bytes. Vier Indizien sind eine Markierung wert: Erstellungszeit überschrieben, ein Wert geht zurück, Werte auf volle Sekunden, Erstellung in $SI vor der in $FN. Alle vier haben harmlose Erklärungen; bestätigen Sie mit USN-Journal, Ausführungsartefakten und den umliegenden Einträgen.

Timestomping (MITRE ATT&CK T1070.006) ist billig für den Angreifer und teuer für die Analyse: Eine zurückdatierte Binärdatei fällt aus jedem Filter „während des Vorfalls angelegte Dateien“ heraus. Das $LogFile ist eines der wenigen Artefakte, die die Änderung als Änderung festhalten.

Wie Zeitstempel überschrieben werden

NTFS führt pro Datei zwei Sätze von je vier Zeitstempeln (Erstellung, Änderung, MFT-Änderung, Zugriff):

Attribut	Wer es aktualisiert	Aus dem User-Mode leicht zu setzen?
`$STANDARD_INFORMATION`	Die meisten Dateioperationen; Anwendungen über `SetFileTime`	Ja, mit Schreibzugriff auf die Datei
`$FILE_NAME`	Das Dateisystem, vor allem beim Anlegen, Umbenennen und Verschieben	Nicht direkt

Die meisten Werkzeuge fassen nur $SI an. Manche gehen weiter und manipulieren $FN indirekt, etwa indem sie $SI setzen und die Datei danach verschieben, sodass NTFS die Werte in das neue $FN übernimmt; Palmbach und Breitinger untersuchen sieben Drittanbieter-Werkzeuge und einen PowerShell-Ansatz in Artifacts for Detecting Timestamp Manipulation in NTFS on Windows and Their Reliability (DFRWS EU 2020).

Zeitstempel sind FILETIME-Werte: Intervalle von 100 Nanosekunden seit dem 1601-01-01 UTC. Wegen dieser Genauigkeit fallen Werte auf volle Sekunden auf.

Warum die $MFT allein nicht reicht

Die $MFT zeigt den aktuellen Zustand. Aus ihr gewinnen Sie den $SI/$FN-Vergleich und Prüfungen der Sekundenbruchteile, mehr nicht. Sie erfahren nicht:

welcher Wert vorher dastand;
ob er sich einmal oder mehrmals geändert hat;
ob auch $FN manipuliert wurde (dann stimmen beide Sätze überein, und der klassische Test schlägt nicht an).

Chos Aufsatz von 2013 (Computers & Security 34) baut genau darauf eine Erkennungsmethode auf: frühere Zeitstempelwerte aus dem $LogFile, kombiniert mit den erwarteten Zeitstempelmustern gängiger Dateioperationen.

Wie das Überschreiben im Log aussieht

Ein Aufruf von SetFileTime auf eine bestehende Datei führt typischerweise zu einem UpdateResidentValue-Eintrag, dessen Ziel das $SI-Attribut im FILE-Record dieser Datei ist:

Feld	Wert
Redo / Undo	`UpdateResidentValue` / `UpdateResidentValue`
Zielattribut	`$MFT:$DATA` (der FILE-Record)
Eintrags-Offset	Offset von `$SI` im FILE-Record (`0x38`, wenn es das erste Attribut eines NTFS-3.1-Records ist)
Attribut-Offset	Offset des ersten geänderten Bytes in `$SI`
Redo-Bytes	Neue Zeitstempelwerte
Undo-Bytes	Vorherige Zeitstempelwerte

Der Attribut-Offset ist entscheidend. Aktualisierungen können partiell sein — dfir.ru weist darauf hin, dass eine Aktualisierung von $SI beim M-Zeitstempel beginnen kann (How the $LogFile works?) —, daher muss ein Parser die Bytes den richtigen Feldern zuordnen. Normale Aktivität (Schreiben in eine Datei) erzeugt ebenfalls solche Einträge: neue Werte für Änderung / MFT-Änderung / Zugriff, Erstellung unverändert. Die Aufgabe besteht darin, diese von echtem Überschreiben zu trennen.

Vier Indizien und was sie sonst auslöst

Der $LogFile-Parser im Browser markiert eine $SI-Änderung als Zeitstempeländerung (mögliches Timestomping), wenn mindestens eines der folgenden Indizien zutrifft, und nennt, welche:

Indiz	Warum es zählt	Harmlose Ursachen
Erstellungszeit überschrieben	Normale Schreibvorgänge ändern die Erstellungszeit nicht	Kopier-/Wiederherstellungswerkzeuge, die Zeiten erhalten, Installer, Sync-Clients
Ein Wert ging zurück	Normale Aktivität bewegt Zeiten nach vorn	Entpacken von Archiven mit gespeicherten Zeiten, Wiederherstellung aus Backup, Korrektur der Systemuhr
Wert auf volle Sekunden (`.0000000`)	NTFS speichert 100 ns; Werkzeuge und Skripte im Stil von `SetFileTime` übergeben oft volle Sekunden	Das DOS-Zeitfeld von ZIP hat eine Auflösung von zwei Sekunden, entpackte Dateien können also Zeiten auf volle Sekunden tragen; Dateien, die von FAT stammen
Erstellung in `$SI` vor der in `$FN`	`$FN` wird beim Anlegen vom Dateisystem gesetzt	Datei mit erhaltenen Zeiten kopiert oder entpackt

Noch eine harmlose Quelle alter Erstellungszeiten: File System Tunneling. Wird eine Datei gelöscht oder umbenannt und kurz danach (standardmäßig innerhalb von 15 Sekunden) im selben Ordner eine Datei gleichen Namens angelegt, gibt Windows der neuen Datei die Erstellungszeit der alten. Editoren, die über eine temporäre Datei plus Umbenennung speichern, lösen das routinemäßig aus.

Eine Kombination sagt mehr aus als jedes einzelne Indiz. Eine Datei in einem vom Benutzer beschreibbaren Ordner, deren Erstellungszeit von heute auf ein Datum mit vollen Sekunden vor Jahren springt, ohne dass in der Nähe ein Archiv entpackt wurde, verdient Aufmerksamkeit. Tausend Dateien mit zurückgesprungenen Änderungszeiten, angelegt innerhalb einer Sekunde nach einer Prefetch-Datei von 7z.exe, sind vermutlich ein Entpackvorgang.

Durchgerechnetes Beispiel (synthetisches Beispiel)

Das Beispiel-Log des Parsers (synthetisch, fiktiver Host FIN-WKS-07) enthält für MFT-Eintrag 322 diese Abfolge:

Anlegen von \Users\svc_backup\Downloads\tools\m64.exe — Erstellung in $FN 2026-09-14 10:06:52.3551871.
Umbenennen / Verschieben nach \ProgramData\Intel\m64.exe — Änderung in $FN 10:09:40.5560318.
$SI-Änderung — vorher: Erstellung 10:06:52.3551871, MFT-Änderung 10:09:40.5560318; nachher: alle vier Zeiten 2019-03-19 07:14:22.0000000.

Alle vier Indizien schlagen an: Erstellungszeit überschrieben, Werte gingen zurück, volle Sekunden, Erstellung in $SI (2019) früher als Erstellung in $FN (2026). Beachten Sie, was der Parser mit der Ereigniszeit macht: Da die neuen Werte zurückgingen, verwendet er sie nicht als Zeitpunkt der Änderung. Das Ereignis übernimmt die Zeit seines Nachbarn (die Verschiebung um 10:09:40) und wird mit ≈ gekennzeichnet. Den tatsächlichen Zeitpunkt des Überschreibens würde der BASIC_INFO_CHANGE-Eintrag im USN-Journal liefern.

Dasselbe Muster zeigte in der $MFT allein $SI = 2019 und $FN = 2026 — genug für einen Verdacht, aber nicht genug, um den ursprünglichen Wert oder die Reihenfolge der Ereignisse (zuerst verschoben, dann zurückdatiert) zu belegen.

Einen Befund bestätigen

Den Roheintrag finden. Öffnen Sie die Logeinträge des Ereignisses, prüfen Sie, dass es ein UpdateResidentValue auf dem $SI des richtigen Eintrags ist, und lesen Sie die Undo- und Redo-Bytes selbst.
Das USN-Journal prüfen. Ein BASIC_INFO_CHANGE-Eintrag für dieselbe Dateireferenz datiert die Änderung (USN-Journal-Parser).
Nach dem Werkzeug suchen. Prefetch (Prefetch-Parser), Amcache (Amcache-Parser), PowerShell- und Sysmon-Logs (EVTX-Parser) können zeigen, dass ein Timestomping-Werkzeug oder ein Skript mit SetFileTime-Fähigkeit lief.
Die Nachbarn prüfen. Ein einzelnes Überschreiben an einer ausführbaren Datei in ProgramData ist etwas anderes als eine Reihe von Überschreibungen während eines Entpackvorgangs.
Mit einem zweiten Parser gegenprüfen, wenn der Befund in einen Bericht kommt: Der Parser im Browser ist bisher nur mit synthetischen Logs validiert. $LogFile-Parser im Vergleich: LogFileParser, NTFS Log Tracker nennt Alternativen; NTFS Log Tracker bringt eigene Muster für Zeitstempelmanipulation mit.

Grenzen

Vorhaltezeit. Fand das Überschreiben auf einem stark genutzten Systemvolume vor Stunden statt, ist der Eintrag vermutlich weg (Wie weit reicht das $LogFile zurück? Grenzen und Fallstricke).
Fehlender Kontext. Lag das Anlegen der Datei außerhalb des Logs, stammen die „Vorher“-Werte nur aus den Undo-Bytes, die womöglich nur einen Teil von $SI abdecken.
Manipulation von $FN. Hat der Angreifer die Datei zusätzlich verschoben, um die Zeiten nach $FN zu übertragen, entfällt das $SI/$FN-Indiz; dann bleiben das Überschreiben und die Umbenennungseinträge als Beweismittel.
Heuristiken, keine Urteile. Jedes der obigen Indizien hat legitime Ursachen. Berichten Sie die Beobachtung (alter Wert, neuer Wert, LSNs der Einträge) und die Bestätigung, nicht die Markierung.

Häufige Fragen

Warum ist das $LogFile nützlich, um Timestomping zu erkennen?

Weil die Änderung selbst protokolliert wird. Ein UpdateResidentValue auf $STANDARD_INFORMATION trägt die neuen Zeitstempel in seinen Redo-Bytes und die vorherigen in seinen Undo-Bytes. So sehen Sie den Wert vor und nach dem Überschreiben, statt ihn aus einer Abweichung zu erschließen.

Ist eine Erstellungszeit in $SI vor der in $FN ein Beweis für Timestomping?

Nein. Sie ist ein starker Hinweis, aber auch Kopiervorgänge, das Entpacken von Archiven, Installer und Wiederherstellungen aus Backups können Zeiten in $STANDARD_INFORMATION in die Vergangenheit setzen. Suchen Sie das Überschreiben im $LogFile, einen passenden BASIC_INFO_CHANGE im USN-Journal und Ausführungsspuren eines Werkzeugs, das Zeiten ändert.

Weiterführende Literatur

D. Palmbach, F. Breitinger, Artifacts for Detecting Timestamp Manipulation in NTFS on Windows and Their Reliability, FSI: Digital Investigation, 2020.
G.-S. Cho, A computer forensic method for detecting timestamp forgery in NTFS, Computers & Security, 2013.
MITRE ATT&CK, Indicator Removal: Timestomp (T1070.006).