Das NTFS Update Sequence Number Journal — meist einfach USN-Journal oder $UsnJrnl:$J genannt — ist eines der am meisten unterschätzten Artefakte der Windows-Forensik. Jedes Mal, wenn NTFS eine Datei auf einem Volume anlegt, löscht, umbenennt, kürzt oder anderweitig berührt, hängt es einen Eintrag an dieses Log. Die Einträge sind winzig (jeweils ein paar Dutzend Bytes), und das Journal wird als Ringpuffer mit fester Größe geführt — eine aktive Maschine bewahrt also rund die letzten paar Millionen Dateioperationen.
Wo das Journal liegt
Das Journal ist keine gewöhnliche Datei. Es ist ein alternativer Datenstrom namens $J, an die Datei \$Extend\$UsnJrnl im Volume-Root angehängt. Aus einem forensischen Image zieht man ihn typischerweise mit einem Werkzeug heraus, das NTFS-Metadatenströme versteht (FTK Imager, X-Ways, icat aus The Sleuth Kit, …). Das resultierende $J-Blob ist das, was Werkzeuge wie der WebAssembly-Parser dieser Seite oder usnrs konsumieren.
Struktur eines Eintrags (USN_RECORD_V2)
Jeder Eintrag ist eine Struktur USN_RECORD_V2:
| Feld | Bytes | Bedeutung |
|---|---|---|
| RecordLength | 4 | Gesamtgröße inklusive Dateiname |
| Major / Minor version | 2 + 2 | Aktuell 2.0 |
| FileReferenceNumber | 8 | MFT-Eintrag + Sequenz der Datei |
| ParentFileReferenceNumber | 8 | MFT-Eintrag + Sequenz des Elternordners |
| USN | 8 | Position dieses Eintrags im Journal |
| Timestamp | 8 | Windows-FILETIME (100-ns-Ticks seit 01.01.1601) |
| Reason | 4 | Bitmaske, beschreibt, was sich geändert hat (FileCreate, Close, …) |
| SourceInfo | 4 | Hinweise (z. B. DATA_MANAGEMENT für OS-getriebene Änderungen) |
| SecurityId | 4 | Index in $Secure:$SII |
| FileAttributes | 4 | Standard-NTFS-Attribute |
| FilenameLength / Offset | 2 + 2 | Lage des UTF-16-Namens im Eintrag |
| Filename | n | UTF-16 LE, ohne Null-Terminator |
Das Feld „Reason" ist das informativste: es ist eine Bitmaske, und der typische Lebenszyklus einer einzelnen Datei produziert eine Folge wie FileCreate | DataExtend → DataExtend | Close → BasicInfoChange | Close → FileDelete | Close. Diese Folge zu rekonstruieren ist der Weg, im Nachhinein zu erzählen, was wirklich mit einer Datei passiert ist.
Warum es in der DFIR zählt
Zwei Gründe:
- Überlebt das Löschen. Selbst nachdem eine Datei vom Dateisystem (und aus dem Papierkorb) verschwunden ist, bleibt ihre Operationshistorie im Journal — bis der Ringpuffer sie überschreibt.
- Günstig abzufragen. Ein 100-MB-
$Jhält typischerweise Millionen von Einträgen über Tage bis Wochen Aktivität, und jeder Eintrag ist selbstbeschreibend.
Wenn man das Journal mit der $MFT korreliert, lassen sich für nahezu jeden Eintrag vollständige Pfade auflösen — die $MFT liefert über das $FILE_NAME-Attribut jedes Eintrags die Eltern-Kette. Genau das tut auf dieser Seite die Option „lege deine $MFT hier ab".
Wie es weitergeht
Wer noch nie ein Journal angeschaut hat, holt sich am einfachsten eines von einer Testmaschine und legt es in das Feld oben auf dieser Seite. Folgeartikel dieser Reihe graben tiefer in die Reason-Flags, die Trade-offs des Journal-Carvings und die Einordnung des Journals neben den anderen Windows-Timeline-Artefakten ($LogFile, Prefetch, ShimCache).