The NTFS Update Sequence Number Journal — usually called the USN Journal or just $UsnJrnl:$J — is one of the most underrated artefacts in Windows forensics. Every time NTFS creates, deletes, renames, truncates or otherwise touches a file on a volume, it appends a record to this log. The records are tiny (a few dozen bytes each) and the journal is rolled in a fixed-size ring buffer, so a busy machine retains roughly the last several million file operations.
Where the journal lives
The journal is not a regular file. It is an alternate data stream named $J attached to the file \$Extend\$UsnJrnl in the volume root. From a forensic image you typically carve it with a tool that understands NTFS metadata streams (FTK Imager, X-Ways, icat from The Sleuth Kit, etc.). The resulting $J blob is what tools like this site's WebAssembly parser, or usnrs, consume.
Record structure (USN_RECORD_V2)
Each record is a USN_RECORD_V2 struct:
| Field | Bytes | Meaning |
|---|---|---|
| RecordLength | 4 | Total record size including filename |
| Major / Minor version | 2 + 2 | Currently 2.0 |
| FileReferenceNumber | 8 | MFT entry + sequence of the file |
| ParentFileReferenceNumber | 8 | MFT entry + sequence of the parent directory |
| USN | 8 | Position of this record in the journal |
| Timestamp | 8 | Windows FILETIME (100-ns ticks since 1601-01-01) |
| Reason | 4 | Bitmask describing what changed (FileCreate, Close, ...) |
| SourceInfo | 4 | Hints (e.g. DATA_MANAGEMENT for OS-driven changes) |
| SecurityId | 4 | Index into $Secure:$SII |
| FileAttributes | 4 | Standard NTFS attributes |
| FilenameLength / Offset | 2 + 2 | Where the UTF-16 name lives in the record |
| Filename | n | UTF-16 LE, no null terminator |
The "reason" field is the most informative: it is a bitmask, and a typical lifecycle for a single file produces a sequence such as FileCreate | DataExtend → DataExtend | Close → BasicInfoChange | Close → FileDelete | Close. Reconstructing this sequence is how you tell, after the fact, what really happened to a file.
Why it matters for DFIR
Two reasons:
- Survives deletion. Even after a file is gone from the filesystem (and from the recycle bin), its history of operations is still in the journal until the ring buffer wraps over it.
- Cheap to query. A 100 MB
$Jtypically holds millions of records covering days to weeks of activity, and every record is self-describing.
When you correlate the journal against the $MFT, you can resolve full paths for nearly every record — the $MFT gives you the parent chain via each entry's $FILE_NAME attribute. That's exactly what the "drop your $MFT" option on this site does for you.
What's next
If you've never looked at a journal before, the easiest way to get a feel is to grab one from a test machine and parse it in the box at the top of this page. Subsequent posts in this series will dig into the reason flags, the trade-offs of journal carving, and how the journal fits next to other Windows timeline artefacts ($LogFile, Prefetch, ShimCache).