USN Journal ($UsnJrnl:$J)

What it is

The Update Sequence Number (USN) change journal is an NTFS feature that appends a record every time a file or directory changes on a volume. Windows components such as the Search indexer and backup or replication software use it to find changed files without rescanning the disk. For investigators it is a compact, time-ordered log of file creation, renaming, writing and deletion that often covers days or weeks, and it keeps the names of files long after they are gone.

Location

$J is sparse: when old records are purged, their clusters are released and read back as zeros. The logical size of $J can be several gigabytes while only the most recent tens of megabytes contain data. On current Windows versions the system volume has an active journal; secondary and removable volumes may or may not.

What it proves

• File activity with timestamps: creation, deletion, rename (old and new name), content writes, truncation, attribute or timestamp changes, security changes and alternate data stream changes.
• Existence of deleted files: the file name and its file reference remain in the journal even after the MFT record has been reused.
• Location: the parent directory reference lets you rebuild the full path by joining with the $MFT.
• Anti-forensics: timestamp changes (BasicInfoChange), mass renames before deletion, and gaps or a recreated journal.
• It does not record who made the change, which process did it, or the file content. A write shows as DataExtend or DataOverwrite without detail.

Key fields

Common Reason flags: DATA_OVERWRITE (0x1), DATA_EXTEND (0x2), DATA_TRUNCATION (0x4), NAMED_DATA_* (0x10–0x40, alternate data streams), FILE_CREATE (0x100), FILE_DELETE (0x200), SECURITY_CHANGE (0x800), RENAME_OLD_NAME (0x1000), RENAME_NEW_NAME (0x2000), BASIC_INFO_CHANGE (0x8000), HARD_LINK_CHANGE (0x10000), STREAM_CHANGE (0x200000), CLOSE (0x80000000).

Timestamps

Retention and clearing

• The journal is bounded by its maximum size plus an allocation delta. When it exceeds that size NTFS purges the oldest records at the next checkpoint. On Windows 10/11 system volumes the maximum size is commonly 32 MB (0x2000000) with an 8 MB delta; check it with fsutil usn queryjournal. Retention is therefore measured in activity, not days: hours on a build server, weeks on a quiet laptop.
• Purged records can survive elsewhere: in volume shadow copies, in unallocated space (carving), and in $LogFile for very recent changes.
• fsutil usn deletejournal /d C: disables and deletes the journal. Windows or an application may recreate it later with a new journal ID, which you can see in $Max and fsutil usn queryjournal. A journal that starts suspiciously recently, or a missing $UsnJrnl, is an anti-forensics lead.
• An attacker can also enlarge or shrink the journal with fsutil usn createjournal m=<size> a=<delta> C:.

Collection

• KAPE target: $J (collects $J and $Max; also part of FileSystem)
• Velociraptor (Windows.Triage.Targets): $J
• Built-in: the stream is not readable through normal file APIs, so copy it with a raw-NTFS tool. fsutil gives live information and can read records:

fsutil usn queryjournal C:
fsutil usn readdata C:\Users\Public\payload.exe
fsutil usn readjournal C: > E:\case\usn_live.txt

Collect $J together with the $MFT of the same volume, at the same moment, so parent paths can be resolved.

Parsing tools

• MFTECmd (Eric Zimmerman): MFTECmd.exe -f E:\C\$Extend\$J -m E:\C\$MFT --csv E:\out parses the records and uses the $MFT to resolve parent paths.
• Velociraptor: Windows.Forensics.Usn parses the live or a collected journal, with filters on file name, path and date; Windows.Carving.USN carves older records from raw disk.
• dfir_ntfs (Maxim Suhanov): ntfs_parser --usn <$MFT> <$J> out.csv with path reconstruction.
• NTFS Log Tracker (Junghoon Oh, free): loads $UsnJrnl, $LogFile and $MFT into SQLite for combined queries.
• Plaso: the usnjrnl parser adds each record to a super timeline.

Investigation tips

• Filter on FileCreate for executables, scripts and archives in user-writable paths, then check whether a matching Prefetch file was created seconds later: a strong execution sequence.
• Look for RenameOldName/RenameNewName pairs that change extensions (.txt to .exe, many files to a ransomware extension) or move data into a staging folder before FileDelete.
• A BasicInfoChange record on a file whose $SI times are years old is a timestomping indicator; compare with the $MFT SI<FN flag.
• Search for deleted tool names (mimikatz, rclone, procdump): the journal often keeps them after $MFT records have been reused.
• Parse $J from every shadow copy and deduplicate by Usn to extend the timeline further back.
• Check SourceInfo: records from replication or data-management components are background activity, not user actions.