Als ich das erste Mal eine Windows-Timeline aus $MFT erstellte, gab ich acht Zeilen pro Datensatz aus, sortierte nach Zeitstempel, öffnete sie in Excel und fühlte mich, als hätte ich die Realität rekonstruiert. Hatte ich nicht. Ich hatte ein sortiertes Protokoll von NTFS-Metadatenänderungen. Das ist eine nützliche Sache. Es ist für sich genommen keine Untersuchung.
Dieser Beitrag ist das, was mir jemand über MFT-Timelining hätte sagen sollen, bevor ich meinen ersten Bericht abgeschickt habe.
Was eine MFT-Timeline tatsächlich ist
Jeder aktive und gelöschte MFT-Datensatz trägt acht Zeitstempel, die du zuverlässig extrahieren kannst: vier in $STANDARD_INFORMATION (SI) und vier in $FILE_NAME (FN). Erstellt, geändert, zugegriffen und MFT-geändert, in beiden Attributen. Durchlaufe die Tabelle, gib eine Zeile pro Nicht-Null-Zeitstempel aus, sortiere nach Zeit, und du hast eine Timeline davon, wann NTFS bestimmte Bytes bestimmter Datensätze geschrieben hat. Das ist die Untergrenze.
Die Obergrenze ist eine Super-Timeline, die MFT mit dem USN-Journal, $LogFile, Prefetch, Sysmon, Shimcache, Amcache, Registry-Hives, Browser-Verlauf und SRUM fusioniert. Die MFT ist das Rückgrat, weil sie die dichteste und für einen Angreifer am schwersten vollständig fälschbar ist. Alles andere wird daran ausgerichtet.
Das Layout, das ich tatsächlich verwende
Vergiss mactime als Zielformat. Verwende es als Zwischenformat. Die Form, die vor Gericht hält, ist eine Zeile pro Ereignis mit Provenienz, die du verteidigen kannst:
timestamp_utc | source | attribute | mft_record | seq | path | event
2026-05-15T10:23:01.123Z | MFT | SI | 12345 | 3 | /Users/alice/notes.txt | created
2026-05-15T10:23:01.123Z | MFT | FN | 12345 | 3 | /Users/alice/notes.txt | name_created
2026-05-15T10:24:18.456Z | MFT | SI | 12345 | 3 | /Users/alice/notes.txt | modified
2026-05-15T10:24:18.501Z | USN | - | 12345 | 3 | /Users/alice/notes.txt | DATA_OVERWRITE | CLOSE
source und das Paar Datensatz/Sequenznummer sind die Spalten, die Analysten überspringen und es dann bereuen. Die Sequenznummer sagt dir, ob zwei Ereignisse, die sich eine Datensatznummer teilen, sich auf dieselbe Inkarnation einer Datei beziehen oder auf einen gelöschten Vorgänger, dessen Platz wiederverwendet wurde. Ohne sie vermischt deine Timeline sie stillschweigend.
Die CSV-Ausgabe von MFTECmd ist das fertigste Layout, das dem nahe kommt. Leite ihre Zeilen durch ein dünnes Skript, das source=MFT hinzufügt und eine Zeile pro Zeitstempel ausgibt, und du hast ein arbeitsfähiges Korpus.
Die Zeitstempel nach dem Grad ihrer Verlässlichkeit
SI bewegt sich bei praktisch jeder Operation, die Windows an einer Datei vornimmt. Lesevorgänge aktualisieren accessed, wenn NTFS Lust dazu hat (Windows 7+ aktualisiert standardmäßig accessed aus Leistungsgründen nicht, es sei denn fsutil behavior set disablelastaccess 0 ist gesetzt). Schreibvorgänge aktualisieren modified und MFT-modified. Umbenennungen aktualisieren MFT-modified. Timestomping mit SetFileTime aktualisiert das, worauf der Angreifer es richtet.
FN wird beim Umbenennen, beim Erstellen eines harten Links und bei der initialen Erstellung der Datei aktualisiert. Danach bleibt FN weitgehend unberührt. Die Granularität von FN-Aktualisierungen durch Windows ist außerdem grober; viele Dateien enden legitim auf .0000000, wenn FN bei der Erstellung gesetzt und nie wieder angefasst wurde.
In der Praxis:
- FN erstellt ist das vertrauenswürdigste "Diese Datei erschien zuerst in diesem Verzeichnis"-Signal, das du aus der MFT allein hast.
- SI erstellt ist am einfachsten zu fälschen. Behandle es als Hinweis, nicht als Tatsache.
- SI modifiziert ist das Arbeitspferd. Kombiniert mit dem passenden USN
DATA_OVERWRITEsagt es dir, dass sich die Bytes der Datei genau in diesem Moment geändert haben. - SI zugegriffen ist auf Windows 7+ standardmäßig deaktiviert. Wenn du es sich ändern siehst, hat entweder ein Admin es wieder aktiviert, das Volume ist auf einer Server-SKU, oder etwas mountet Volumes und durchläuft Dateien (Backup-Software, AV-Scans, EDR-Introspection).
Sub-Sekunden-Granularität ist das Verräterische. NTFS speichert Zeitstempel in 100-Nanosekunden-Ticks. Native Windows-Operationen hinterlassen Rauschen in den unteren Ziffern. Timestomping-Tools wie SetMACE und das bekannte timestomp.exe runden auf die Sekunde. Eine Spalte von .0000000-Suffixen, sauber aufgereiht, ist ein Fingerabdruck.
Fusion mit dem USN-Journal
Die MFT zeigt dir die Gegenwart und eine eingefrorene Historie der Metadaten. Das USN-Journal zeigt dir die Verben. Paare sie, und eine einzelne Zeile in deiner Timeline wird zu einem Satz.
Wie ich fusioniere: parse $UsnJrnl:$J separat, gib eine Zeile pro Datensatz mit source=USN aus, dann sortiere den kombinierten Strom nach Zeitstempel. Die Reason-Codes der USN (FILE_CREATE, DATA_OVERWRITE, RENAME_OLD_NAME, RENAME_NEW_NAME, FILE_DELETE, CLOSE) geben dir die Operation; die MFT liefert den resultierenden Zustand. Ein USN RENAME_OLD_NAME, unmittelbar gefolgt von RENAME_NEW_NAME bei der gleichen USN, offenbart das Umbenennen. Ohne das Journal könnte ein MFT-Diff zwischen zwei Snapshots dir sagen, dass die Datei umgezogen ist; es kann dir nicht die Reihenfolge sagen.
Eine Falle: USN-Zeitstempel und MFT-SI-Zeitstempel weichen für dasselbe Ereignis um Millisekunden ab. Hänge dich nicht zu sehr an die Ausrichtung. Sortiere auf die Sekunde und nutze den USN-Reason-Code als Tiebreaker.
Was MFT-Timelines ruiniert
Akquise außerhalb der Reihenfolge. Wenn du MFT und USN zehn Minuten auseinander auf einem Live-System sammelst, lief das Journal weiter. Paare sie aus demselben Zeitpunkt, idealerweise aus einem VSS-Snapshot, den du selbst ausgelöst hast.
Vergessen des Fixup-Arrays. Jeder brauchbare Parser kümmert sich darum, aber wenn du deinen eigenen schreibst (bitte tu's nicht, es sei denn du lernst), liefert das Lesen roher 1.024-Byte-Brocken Müll an Offsets 510 und 1022 jedes Datensatzes. Wende zuerst Fixups an.
Vermischen von Datensatznummern über Sequenzgrenzen hinweg. Datensatz 12345 Sequenz 3 ist nicht dieselbe Datei wie Datensatz 12345 Sequenz 5. Der Slot wurde wiederverwendet. Wenn deine Timeline nur nach Datensatznummer gruppiert, wirst du eine gelöschte Datei mit der vermischen, die ihren Slot übernommen hat.
SI auf Systembinaries vertrauen. Windows Update fasst SI von gepatchten Dateien an. Ein modifiziertes SI auf C:\Windows\System32\svchost.exe ist fast immer eine CBS-Installation, kein Eindringen. Querverweise mit setupapi.dev.log und CBS.log, bevor du Behauptungen aufstellst.
Die Timeline als Schlussfolgerung behandeln. Sie ist der Input zur Analyse. Du musst weiterhin wissen, was jedes Ereignis im Kontext des Hosts, des Benutzers und des Falls bedeutet.
Ein Workflow, der hält
- Erwirb
$MFT,$UsnJrnl:$J,$LogFileund alle verfügbaren VSS-Snapshot-Kopien davon. Hashe alles (SHA-256) sofort. - Parse MFT und USN mit MFTECmd oder
mft_dumpplus einem USN-Parser. Stelle sicher, dass die Parser ohne Warnungen liefen. - Gib normalisierte Zeilen aus: eine pro Zeitstempel für MFT, eine pro Datensatz für USN, mit expliziter
source,mft_record,sequndpath. - Sortiere nach Zeitstempel in einen einzigen Strom. Dedupliziere noch nicht; Quasi-Duplikate tragen Signal.
- Pivotiere zum interessanten Zeitraum. Zieh ein Fenster von zwei Stunden vor und zwei Stunden nach dem vermuteten Ereignis.
- Lege den Rest darauf: Prefetch, Amcache, Sysmon 1/11/15, LNK- und Jump-Liste-Artefakte, Papierkorb
$I-Datensätze, SRUM für Netzwerk- und Prozessressourcennutzung. - Suche nach unmöglichen Reihenfolgen. SI erstellt vor FN erstellt. Ein
DATA_OVERWRITE-USN-Grund ohne entsprechende SI-Modified-Änderung in der MFT. ZweiFILE_CREATE-Ereignisse mit derselben Datensatznummer und derselben Sequenz (der Parser ist kaputt).
Dieser letzte Schritt ist der Grund, warum MFT-Timelines ihr Geld wert sind. Sie offenbaren Unmöglichkeiten. Jede Unmöglichkeit ist entweder ein Parser-Bug oder ein Angreiferartefakt, und beides ist es wert, verfolgt zu werden.
Was MFT dir nicht sagen kann
Sie kann dir nicht sagen, welcher Prozess eine Datei angefasst hat. Sie kann dir nicht sagen, welcher Benutzer. Sie kann dir nicht sagen, was in einer Datei größer als ein paar Hundert Bytes war, die gelöscht und teilweise überschrieben wurde. Dafür brauchst du die umgebenden Artefakte: 4688 mit Kommandozeilen-Audit (oder Sysmon 1), die Kette der Logon-IDs des Sicherheitsprotokolls und an einem guten Tag einen RAM-Dump, der den Prozess noch resident erwischt hat.
Die MFT ist das Rückgrat. Die anderen Artefakte sind die Muskeln. Keiner geht ohne den anderen.
Weiterführende Literatur
- Eric Zimmerman, MFTECmd. Das kanonische CSV-Layout und der Parser, auf den die meisten IR-Teams standardisieren.
- SANS, Windows Forensic Analysis Poster. Fügt MFT-Ereignisse korrekt in die umfassendere Timeline ein.
- Harlan Carvey, Investigating Windows Systems. Die Kapitel über Timeline-Konstruktion sind weiterhin die praktische Referenz.