Das NTFS USN Journal verstehen ($UsnJrnl:$J)

Das NTFS Update Sequence Number Journal ist das Artefakt, zu dem ich auf jedem Windows-Host als Erstes greife, wenn ich wissen muss, was die Festplatte berührt hat und wann. Es ist standardmäßig auf jedem NTFS-Volume aktiviert, das Windows seit Vista ausliefert, fast niemand deaktiviert es, und fast niemand liest es, bevor etwas schiefgeht. Diese Asymmetrie macht es nützlich.

Jede Dateierstellung, Löschung, Umbenennung, Kürzung, Attributumschaltung und jedes Schließen auf dem Volume hängt einen Eintrag an $UsnJrnl:$J an. Die Einträge sind klein, jeweils ein paar Dutzend Byte, und die Datei ist ein Ringpuffer fester Größe, sodass eine ausgelastete Maschine ungefähr die letzten mehreren Millionen Operationen behält. Auf einem Desktop mit der Standardzuweisung von 32 MB sind das ein paar Tage. Auf einem Dateiserver, der auf 1 GB dimensioniert ist, sind das Wochen.

Wo das Journal tatsächlich liegt

Das Journal ist keine reguläre Datei. Es ist ein alternativer Datenstrom namens $J, der an die Metadatendatei \$Extend\$UsnJrnl am Volume-Stamm angehängt ist. Zwei Konsequenzen, die Personen treffen, die das noch nie gemacht haben:

• Ein Drag-and-Drop im Explorer, ein xcopy oder ein robocopy kopiert stillschweigend den leeren Standard-Stream, und Sie erhalten am Ende eine Null-Byte-Datei. Verwenden Sie ein Werkzeug, das ADS versteht: FTK Imager, X-Ways, icat aus The Sleuth Kit, RawCopy.exe, PowerForensics. Der Begleitbeitrag zum Extrahieren von $J aus einem Festplatten-Image geht jedes davon durch.
• Es gibt einen Geschwister-Stream namens $Max auf derselben Metadatendatei. Er enthält nur Größen- und Konfigurationsmetadaten. Wenn Sie versehentlich $Max extrahieren, erhalten Sie nichts Brauchbares. Wählen Sie immer $J.

Die Datei selbst ist sparse. NTFS reserviert die konfigurierte Maximalgröße auf der Festplatte, lässt den führenden ungenutzten Bereich aber genullt. Wenn Sie $J aus einem Image extrahieren, sind die ersten paar hundert Megabyte oft komplett Nullen, bevor Sie den ersten echten Eintrag erreichen. Jeder vernünftige Parser (usnrs, PoorBillionaires USN-Journal-Parser, MFTECmd, der WebAssembly-Parser auf dieser Seite) überspringt die führenden Nullen automatisch.

Eintragsstruktur (USN_RECORD_V2)

Jeder Eintrag ist eine USN_RECORD_V2-Struktur. Microsoft dokumentiert das Layout in winioctl.h; die feldweise Zusammenfassung:

Die Reason-Bitmaske ist das Feld, das seinen Wert beweist. Sie ist additiv, nicht exklusiv: Ein einzelner Eintrag kann FileCreate | DataExtend | Close zusammen tragen. Ein typischer Dateilebenszyklus sieht so aus: FileCreate | DataExtend → DataExtend | Close → BasicInfoChange | Close → FileDelete | Close. Diese Sequenz nachträglich zu rekonstruieren, ist die Art, wie Sie herausfinden, was wirklich mit einer Datei geschehen ist. Der Reason-Code-Beitrag ist die Feldreferenz für jedes Bit.

Zwei Felder, die neue Leser oft unterschätzen:

• FileReferenceNumber ist Ihr Verknüpfungsschlüssel. Gruppieren Sie Einträge danach, und Sie haben die gesamte Geschichte der Datei über Umbenennungen, Attributänderungen und Löschung hinweg. Beachten Sie, dass die oberen 16 Bits eine Sequenznummer sind. Eine gelöschte Datei und eine neue Datei, die demselben MFT-Eintrag zugewiesen wird, teilen den Eintrag, unterscheiden sich aber in der Sequenz.
• ParentFileReferenceNumber ist die einzige Pfadinformation im Eintrag. Der Dateiname ist nur das Blatt. Sie benötigen eine geparste $MFT, um die Eltern-Kette zu einem vollständigen Pfad zu verfolgen. Erfassen Sie immer beide.

Warum es sich in DFIR auszahlt

Zwei Gründe, die bei fast jedem Einsatz auftauchen.

Erstens überlebt das Journal Löschungen. Sobald eine Datei aus dem Namensraum verschwunden ist und ihr MFT-Eintrag für etwas anderes wiederverwendet wurde, ist der Eintrag über ihre Erstellung, ihr Wachstum, ihre Umbenennung und ihre Löschung immer noch in $J, bis der Ringpuffer ihn überschreibt. Dasselbe gilt für aus dem Papierkorb geleerte Dateien: Die $I-Dateien des Papierkorbs werden gelöscht, aber das Journal erinnert sich. Bei der Suche nach "hat diese Datei jemals existiert" überdauert das Journal meistens sowohl den MFT-Eintrag als auch die Papierkorb-Metadaten.

Zweitens ist es günstig und selbstbeschreibend. Ein 100 MB großes $J enthält typischerweise fünf bis zehn Millionen Einträge über Tage bis Wochen. Jeder Eintrag trägt seinen eigenen Zeitstempel, Reason, Dateireferenz und übergeordnete Referenz. Sie können es in Sekunden durch einen Parser schicken und auf jedem Feld pivotieren. Es gibt kein anderes Windows-Artefakt zu diesem Preis.

Was es Ihnen nicht sagt, ist wer. Es gibt keinen Benutzer, keinen Prozess, keine Kommandozeile in irgendeinem Eintrag. Um einen Akteur zuzuordnen, korrelieren Sie nach Zeitstempel mit Security.evtx Event 4663 (Object Access, erfordert SACLs, die Sie mit ziemlicher Sicherheit nicht konfiguriert haben), Sysmon Event 11 (File Create) oder Prozessbäumen aus Sysmon Event 1. Das Journal beantwortet das Was und Wann. Andere Logs beantworten das Wer.

Wo es im Artefakt-Stack sitzt

Das mentale Modell, das ich verwende, geordnet von "aktueller Zustand" zu "historischer Geschichte":

• $MFT — der Index des aktuellen Zustands. Jede Datei und jedes Verzeichnis auf dem Volume, einschließlich einiger kürzlich gelöschter Einträge. Vier Zeitstempel pro Attribut, keine Historie.
• $UsnJrnl:$J — Operation-für-Operation-Historie, Tage bis Wochen davon. Das, worüber Sie hier lesen.
• $LogFile — NTFS-Transaktionslog für die Absturzwiederherstellung. Minuten bis Stunden roher Vorher-Nachher-Abbilder. Der Beitrag zu USN Journal vs $MFT vs $LogFile schlüsselt auf, wann man zu welchem greift.

Bringen Sie das Journal zusammen mit Prefetch, AmCache, Shimcache, LNK-Dateien und Jump Lists, und Sie können in der Regel rekonstruieren, was ausgeführt wurde, was geöffnet wurde und was die Festplatte minutengenau berührt hat.

Was als Nächstes kommt

Wenn Sie noch nie ein Journal geöffnet haben, ist der schnellste Weg, eine Intuition aufzubauen, eines von einer Testmaschine zu nehmen und es zusammen mit der passenden $MFT in den Parser oben auf dieser Seite zu laden. Filtern Sie nach FileCreate und lesen Sie die Datei so, wie Windows sie geschrieben hat. Die folgenden Beiträge in dieser Serie vertiefen sich in die Reason-Flags, die Extraktionsprozedur und die Muster, die das Journal für Ransomware, Exfiltration, Timestomping und die Wiederherstellung gelöschter Dateien aufdeckt.

Weiterführende Literatur

• Microsoft Learn — Change Journals und die USN_RECORD_V2-Referenz.
• Airbus CERTs usnrs — der sauberste Open-Source-USN_RECORD_V2-Parser, der auch das WebAssembly-Modul auf dieser Seite antreibt.
• Brian Carrier, File System Forensic Analysis — die Buchlängenbehandlung der NTFS-Interna, die immer noch nicht ersetzt wurde.