NTFS gibt forensischen Analysten drei große Metadatenquellen, und der schnellste Weg, einen Tag zu verlieren, ist, die falsche anzusehen. Die schnelle Übersicht:
| Artefakt | Was es aufzeichnet | Zeitfenster | Granularität | Speicherort |
|---|---|---|---|---|
$MFT | Den aktuellen Zustand jeder Datei und jedes Verzeichnisses auf dem Volume — Namen, Größen, Zeitstempel, Eltern | „Jetzt" plus gelöschte Einträge, bis sie wiederverwendet werden | Pro Datei | MFT-Eintrag 0 |
$UsnJrnl:$J | Ringlog jedes Anlegen/Löschen/Umbenennen/Ändern | Tage bis Wochen | Pro Operation | \$Extend\$UsnJrnl:$J (alternativer Datenstrom) |
$LogFile | Transaktionslog, das NTFS zur Crash-Recovery nutzt — Vorher/Nachher-Bilder von Metadaten-Schreibvorgängen | Minuten bis Stunden | Pro Metadaten-Transaktion | \$LogFile (MFT-Eintrag 2) |
Dieser Beitrag liefert den praktischen Entscheidungsbaum: zu welcher Frage welches Artefakt antwortet.
$MFT — „was existiert, gerade jetzt"
Die Master File Table ist das Rückgrat von NTFS. Jede Datei oder jedes Verzeichnis hat einen Eintrag (typischerweise 1024 Bytes), in dem $STANDARD_INFORMATION, ein oder mehrere $FILE_NAME und die Data Runs liegen. Microsoft dokumentiert die Struktur in der NTFS-Referenz, und Brian Carriers File System Forensic Analysis ist die kanonische Buchlänge dazu.
Nutze sie für:
- „Was liegt auf diesem Volume?" — inklusive der Zeitstempel pro Eintrag.
- Das Rekonstruieren vollständiger Pfade über die Eltern-MFT-Eintragskette (so löst unser Parser Pfade für Journal-Einträge auf, wenn du auch
$MFTlieferst). - Das Wiederherstellen kürzlich gelöschter Dateien — bis der Eintrag überschrieben ist, können die Data Runs intakt sein.
Sie sagt dir nicht:
- Was am Dienstag um 14:32 mit einer Datei passierte —
$MFTträgt nur die vier Zeitstempel aus$STANDARD_INFORMATIONund$FILE_NAME, und das ist ein Endzustand, keine Historie.
Tools: Eric Zimmermans MFTECmd ist der De-facto-Parser, mit mft (Rust) und analyzeMFT (Python) als solide Open-Source-Alternativen.
$UsnJrnl:$J — „was geschah, in welcher Reihenfolge"
Das Update-Sequence-Number-Journal zeichnet jedes Anlegen, Löschen, Umbenennen, Kürzen, Attribut-Ändern und Schließen auf dem Volume auf. Hintergrund in unserer Format-Einführung und der Reason-Code-Referenz.
Nutze es für:
- Das Rekonstruieren des Lebenszyklus einer Datei, auch nach dem Löschen.
- Timeline-Rekonstruktion in der Incident Response, vor allem
RenameOldName/RenameNewName-Paare undDataOverwrite-Cluster. - Das Erkennen von Ransomware-Mustern in der Breite (siehe unseren Beitrag dazu).
Es sagt dir nicht:
- Wer irgendetwas tat — kein Benutzer, kein Prozess, keine Kommandozeile. Kombiniere mit
Security.evtx(Event-ID4663) oder Sysmon. - Den Inhalt einer Datei — nur dass sie sich geändert hat.
- Irgendetwas außerhalb des Ringpuffer-Fensters. Standardgrößen reichen von ~10 MB auf Clients bis 1 GB+ auf Servern, was Tagen bis Wochen Historie entspricht.
Tools: usnrs, PoorBillionaire/USN-Journal-Parser, der Parser auf dieser Seite.
$LogFile — „was NTFS gleich tun wollte"
Das ist das Metadaten-Journal, das NTFS für Crash-Recovery führt. Es zeichnet Vorher/Nachher-Bilder jeder Metadaten-Schreiboperation auf — INDEX_ALLOCATION-Updates, Attributänderungen, MFT-Eintrag-Rewrites. Das Format ist undokumentiert, aber gut reverse-engineered; das libfsntfs-Repo von Joachim Metz ist die gründlichste offene Referenz.
Nutze es für:
- Das Wiederherstellen von Dateien, die innerhalb derselben Minuten angelegt und gelöscht wurden —
$LogFilekann noch das „Vorher"-Bild des Löschens haben, das den Dateinamen und das Elternverzeichnis enthält. - Das Aufspüren anti-forensischer Aktivität, die
$MFTdirekt angefasst hat —$LogFilezeichnet die Schreiboperation selbst dann auf, wenn der sichtbare Zustand sauber aussieht.
Es sagt dir nicht:
- Irgendetwas jenseits der letzten paar Tausend Transaktionen —
$LogFilerotiert schwer, auf einer aktiven Maschine teils innerhalb einer Stunde. - Dateiinhalte. Nur Metadatenänderungen werden geloggt.
Tools: LogFileParser und die auf libfsntfs aufbauenden Parser.
Der Entscheidungsbaum
Kennst du die genaue Datei?
├── Ja → Aktueller Zustand? → $MFT (Pfad, Zeitstempel, Größe)
│ Historie? → $UsnJrnl (dann $LogFile fürs ganz Frische)
└── Nein → Zeitfenster?
├── Letzte Minuten → $LogFile (am granularsten)
├── Tage bis Wochen → $UsnJrnl (bestes Signal/Rauschen)
└── Länger her → nur $MFT (Zeitstempel sind oft alles, was bleibt)
Korrelierst du über Dateien hinweg?
└── Nur $UsnJrnl hat eine sortierbare, operationsweise Timeline.
Sie kombinieren
Die drei Artefakte komponieren gut:
$MFT+$UsnJrnlist das kanonische Paar —$MFTliefert den Verzeichnisbaum zur Pfadauflösung,$UsnJrnldie Operationshistorie. Genau das tut der Parser auf dieser Seite, wenn du beide Dateien ablegst.$LogFileist das Auffangnetz für die jüngste Vergangenheit, besonders nützlich, wenn$UsnJrnlzu dünn ist (klein oder deaktiviert).- Für den breiteren Kontext ergänze
Security.evtx(Prozess-/Objekt-Events), Prefetch (Ausführungsbeleg) und die Registry-Hives — siehe das SANS-Poster Windows Forensic Analysis für den Gesamtblick.