NTFS gibt einem forensischen Analysten drei große Metadaten-Artefakte, und der sicherste Weg, einen Tag zu verlieren, ist, das falsche für die Frage zu lesen, die Sie tatsächlich haben. Die Kurzversion:
| Artefakt | Was es aufzeichnet | Zeitspanne | Granularität | Liegt bei |
|---|---|---|---|---|
$MFT | Aktueller Zustand jeder Datei und jedes Verzeichnisses — Name, Größe, Zeitstempel, Übergeordneter | "Jetzt" plus kürzlich gelöschte Einträge | Pro Datei | MFT-Eintrag 0 |
$UsnJrnl:$J | Zirkuläres Log jeder Datei-Erstellung/Löschung/Umbenennung/Änderung | Tage bis Wochen | Pro Operation | \$Extend\$UsnJrnl:$J (alternativer Datenstrom) |
$LogFile | Transaktionslog, das NTFS für die Absturzwiederherstellung verwendet — rohe Vorher-Nachher-Abbilder von Metadaten-Schreibvorgängen | Minuten bis Stunden | Pro Metadaten-Transaktion | \$LogFile (MFT-Eintrag 2) |
Lesen Sie weiter für den Entscheidungsbaum, den ich tatsächlich verwende, und die Gründe, warum jedes Artefakt Sie für sich allein im Stich lassen wird.
$MFT — "was existiert, jetzt gerade"
Die Master File Table ist das Rückgrat von NTFS. Jede Datei oder jedes Verzeichnis hat mindestens einen 1024-Byte-Eintrag, der $STANDARD_INFORMATION, eines oder mehrere $FILE_NAME-Attribute und die Data Runs enthält, die auf den eigentlichen Inhalt zeigen.
Greifen Sie zu $MFT, wenn die Frage lautet:
- Was existiert gerade jetzt auf diesem Volume, einschließlich kürzlich gelöschter Einträge, bevor sie wiederverwendet werden.
- Was sind die vier NTFS-Zeitstempel (M/A/C/B sowohl in
$STANDARD_INFORMATIONals auch in$FILE_NAME) für eine bestimmte Datei. - Kann ich die Bytes einer gelöschten Datei wiederherstellen, deren Eintrag noch zugewiesen ist.
- Was ist der vollständige Pfad eines Eintrags, der nur eine übergeordnete Referenznummer trägt — genau so löst der Parser auf dieser Seite USN-Einträge auf, wenn Sie auch
$MFTablegen.
Was es Ihnen nicht sagen wird, egal wie sehr Sie zusammenkneifen:
- Was mit einer Datei letzten Dienstag um 14:32 passiert ist. Die vier Zeitstempel sind ein Endzustand, keine Historie. Sie sagen Ihnen, wann die Datei erstellt und zuletzt berührt wurde. Sie sagen Ihnen nicht, dass sie umbenannt, dann zurück umbenannt, dann gekürzt, dann überschrieben, dann gelöscht wurde, dann eine neue Datei am selben MFT-Eintrag erstellt wurde.
Werkzeuge: Eric Zimmermans MFTECmd ist der De-facto-Parser. Omer BenAmrams mft Rust-Crate und David Kovars analyzeMFT Python-Skript decken die Open-Source-Seite ab.
$UsnJrnl:$J — "was passiert ist, in welcher Reihenfolge"
Das Update Sequence Number Journal zeichnet jede Erstellung, Löschung, Umbenennung, Kürzung, Attributänderung und jedes Schließen auf, das auf dem Volume passiert. Als Hintergrund deckt der Einführungsbeitrag das On-Disk-Format ab, und der Reason-Code-Beitrag ist die Bit-Level-Feldreferenz.
Greifen Sie danach, wenn die Frage lautet:
- Wie war der Lebenszyklus dieser Datei, einschließlich Umbenennungen, bevor sie gelöscht wurde.
- Hat etwas Dateien auf diesem Volume massenweise verschlüsselt — siehe Ransomware-Erkennung.
- Hat etwas Dateien massenweise gestaged und archiviert für die Exfiltration — siehe Exfiltrations-Erkennung.
- Wurden Zeitstempel manipuliert — siehe Timestomping.
- Was hat der Benutzer zwischen 14:00 und 16:00 gemacht — siehe Aktivitäts-Timeline-Rekonstruktion.
Was es Ihnen nicht sagen wird:
- Wer etwas getan hat. Kein Benutzer, kein Prozess, keine Kommandozeile. Korrelieren Sie mit Security.evtx
4663(nur wenn SACLs konfiguriert waren) oder Sysmon Event 11. - Den Inhalt irgendeiner Datei. Das Journal zeichnet auf, dass sich ein Stream geändert hat, nicht welche Bytes vorher dort waren.
- Irgendetwas, das älter ist als das Ringpuffer-Fenster. Defaults reichen von ~10 MB auf einem abgespeckten Client bis zu 1 GB+ auf einem ordnungsgemäß dimensionierten Server, was Tage bis Wochen an Historie bedeutet.
Werkzeuge: Airbus CERTs usnrs, PoorBillionaires USN-Journal-Parser, Eric Zimmermans MFTECmd (das $J auch parst) und der WebAssembly-Parser auf dieser Seite.
$LogFile — "was NTFS gleich tun wollte"
Das ist das Metadaten-Journal, das NTFS für die Absturzwiederherstellung verwendet. Es zeichnet Vorher-Nachher-Abbilder jedes Metadaten-Schreibvorgangs auf — INDEX_ALLOCATION-Updates, Attributänderungen, MFT-Eintrags-Umschreibungen. Das Format ist undokumentiert, aber gut reverse-engineered; Joachim Metzs libfsntfs ist die gründlichste offene Referenz.
Greifen Sie danach, wenn:
- Eine Datei innerhalb derselben paar tausend Transaktionen erstellt und gelöscht wurde und der Verzeichniseintrag des Übergeordneten bereits überschrieben wurde.
$LogFilekann immer noch das "Vorher"-Bild mit dem Blattnamen und dem Übergeordneten enthalten. - Sie direkte
$MFT-Manipulation vermuten.$LogFilezeichnet den rohen Schreibvorgang auf, selbst wenn der sichtbare Zustand danach sauber aussieht. - Das Journal zu spärlich ist (klein oder kürzlich rotiert), um den Moment von Interesse abzudecken, aber es ist innerhalb der letzten Stunde passiert.
Was es Ihnen nicht geben wird:
- Irgendetwas außerhalb des Rotationsfensters.
$LogFileist klein und wird stark wiederverwendet. Auf einem ausgelasteten Dateiserver kann die gesamte Transaktionshistorie in unter einer Stunde umlaufen. - Dateiinhalt. Die Vorher-Nachher-Abbilder sind nur Metadaten.
Werkzeuge: Jonas Schichts LogFileParser und jeder auf libfsntfs aufbauende Parser.
Der Entscheidungsbaum, den ich tatsächlich verwende
Wissen Sie WELCHE Datei?
├── Ja → Aktueller Zustand erwünscht? → $MFT (Pfad, Zeitstempel, Größe)
│ Historie erwünscht? → Zuerst $UsnJrnl, $LogFile für die sehr jüngste Vergangenheit
└── Nein → Zeitfenster?
├── Letzte paar Minuten → $LogFile (am granularsten)
├── Letzte Tage/Wochen → $UsnJrnl (bestes Signal/Rauschen)
└── Vor langer Zeit → Nur $MFT, erwarten Sie, sich mit End-Zustand-Zeitstempeln zu begnügen
Korrelieren Sie über viele Dateien gleichzeitig?
└── $UsnJrnl ist das einzige der drei mit einer sortierbaren, Per-Operation-Timeline.
Wurde die Datei gelöscht und Sie müssen beweisen, dass sie existierte?
└── Zuerst $UsnJrnl (FileDelete-Eintrag trägt übergeordnete Referenz und Zeitstempel)
$LogFile als Sicherheitsnetz, wenn die Löschung frisch ist
$MFT nur, wenn der Eintrag noch nicht wiederverwendet wurde
Sie zu kombinieren ist, wo die eigentliche Arbeit passiert
Die drei Artefakte komponieren sich gut, was der Teil ist, den niemand betont, bis er ihn braucht.
$MFT + $UsnJrnl ist das kanonische Paar. Die MFT liefert den Verzeichnisbaum für die Pfadauflösung; das Journal liefert die Operations-Historie. Der Parser auf dieser Seite löst automatisch vollständige Pfade für jeden Journal-Eintrag auf, wenn Sie beide Dateien ablegen. Erfassen Sie sie gemeinsam; Sie sparen sich neunmal von zehn eine zweite Runde.
$LogFile ist das Sicherheitsnetz. Wenn das Journal zu klein ist, um den Moment von Interesse abzudecken, oder wenn Sie direkte MFT-Manipulation vermuten, ist $LogFile der Ort, zu dem Sie greifen.
Für den breiteren Kontext paaren Sie die drei NTFS-Artefakte mit EVTX (Prozess- und Objekt-Ereignisse), Prefetch und AmCache (Ausführungsbeweise), Shimcache (Programm-irgendwann-gelaufen), Registry-Hives, LNK-Dateien und Jump Lists für Beweise vom Benutzer geöffneter Dateien, Browser-Historie, SRUM für Ressourcennutzung und dem RecentFileCache.
Weiterführende Literatur
- Microsoft Learn — Master File Table und Change Journals.
- Brian Carrier, File System Forensic Analysis — immer noch die Buchlängen-Referenz zu NTFS-Interna.
- Joachim Metz,
libfsntfs-Dokumentation — die detaillierteste offene Referenz zu$LogFile-Interna. - SANS DFIR — das Windows Forensic Analysis Poster ist eine einzelne laminierte Seite, die den Artefakt-Stack an einem Ort versammelt.