$UsnJrnl — NTFS Change Journal

The $UsnJrnl records every file system change on an NTFS volume — every create, delete, rename, data extension, and security modification — in a chronological stream that persists even when the files themselves are gone. When an investigator needs to prove that 4,200 files were deleted in a two-minute window at 02:17 AM, the change journal is the artifact that answers the question.

What Is $UsnJrnl?

The Update Sequence Number Journal ($UsnJrnl) is an NTFS change journal that records metadata about every file system operation on a volume. It was introduced in Windows 2000 (NTFS 3.0) and is enabled by default on all modern NTFS volumes. Every time a file or directory is created, deleted, renamed, extended, truncated, or has its security descriptor changed, NTFS writes a USN record to the journal. Each record contains a timestamp, the filename, the parent directory’s MFT reference, and a set of reason flags that describe exactly what changed.

The journal exists as an alternate data stream named $J on the system file $Extend\$UsnJrnl. It operates as a sparse file — the OS maintains a maximum size (typically 32–64 MB), and as the journal grows, the oldest records are marked as sparse (effectively deleted) while new records are appended at the end. This means the journal is a rolling window: on a busy system, it may contain only a few days of history; on a quiet system, it may span weeks or months.

The $UsnJrnl is fundamentally different from the $MFT in what it captures. The $MFT stores the current state of a file (or the last state before entry reuse). The $UsnJrnl stores every change event — the complete sequence of operations. A file that was created, renamed three times, extended twice, and then deleted will produce six or more USN records, each with its own timestamp and reason flags. This event-level granularity makes the $UsnJrnl the primary timeline artifact for file system activity.

Location & Format

File Path & Properties

USN Record Structure

Each USN record (version 2, the most common) contains the following fields:

Key Reason Flags

What It Reveals

The $UsnJrnl answers the following investigative questions:

• What files were created, deleted, or renamed on the volume, and when? — Each USN record carries a timestamp and reason flags that describe the exact operation. The filename and parent MFT reference are recorded at the time of the event.
• Were files mass-deleted in a short time window? — Thousands of FILE_DELETE records within a narrow timestamp range indicate bulk cleanup or data destruction. This pattern is common in insider threat cases (staging directory cleanup) and ransomware (original file deletion after encryption).
• Was a file renamed to disguise its identity? — RENAME_OLD_NAME and RENAME_NEW_NAME records capture both the original and final filenames. An adversary renaming rclone.exe to svchost.exe is recorded in full: the journal shows the old name, the new name, and the exact timestamp of the rename.
• Was data written to a file (staging) before exfiltration? — DATA_EXTEND records for a file in a staging directory prove that data was being aggregated. Combined with $MFT file size data and SRUM network transfer volumes, this builds a complete staging-to-exfiltration timeline.
• Did a file exist even though the MFT entry has been reallocated? — If the MFT entry was reused by a new file, the original file’s creation and deletion events may still exist in the $UsnJrnl. The journal provides the only surviving record of the file’s existence.
• What was the chronological sequence of file operations? — The monotonically increasing USN values establish absolute ordering of events. Combined with FILETIME timestamps, investigators can reconstruct second-by-second activity timelines.
• Were security permissions changed on sensitive files? — SECURITY_CHANGE records identify when ACLs were modified, which may indicate privilege escalation or data access preparation.

Forensic Use Cases

1. Mass Deletion Detection

An insider prepares to leave the company and copies 4,200 proprietary documents to a staging directory. After uploading them via a cloud sync tool, they delete the staging directory. The $UsnJrnl records 4,200 FILE_DELETE entries between 02:17:42 and 02:19:11 — a 89-second burst. The parent MFT reference on all records points to a single directory: C:\Users\jdoe\Documents\backup_temp. The filename field on each record preserves the names of every deleted document. The MFT entries have already been partially reallocated, but the journal still holds the complete file list.

2. File Rename Tracking (Tool Masquerading)

An adversary downloads rclone.exe, renames it to rc.exe, and later renames it again to svchost.exe to blend in. The $UsnJrnl captures both renames as paired records: RENAME_OLD_NAME: rclone.exe / RENAME_NEW_NAME: rc.exe at 22:14:03, then RENAME_OLD_NAME: rc.exe / RENAME_NEW_NAME: svchost.exe at 22:14:17. The complete chain of names is preserved, and the FileReferenceNumber on all four records is identical, proving they refer to the same file.

3. Data Modification Timeline

During a ransomware investigation, the $UsnJrnl reveals the encryption sequence. Each original file generates a DATA_OVERWRITE record (content replaced with ciphertext), followed by a RENAME_NEW_NAME record (extension changed to .locked), followed by FILE_DELETE for the Volume Shadow Copy deletion commands. The timestamps show the encryption proceeded at approximately 1,200 files per minute, starting at 03:41 AM and completing at 04:17 AM.

4. Proving File Existence After MFT Reuse

An attacker’s PowerShell script (invoke-exfil.ps1) was created, executed, and deleted. Heavy system activity caused the MFT entry to be reallocated within hours. The $I30 slack for the parent directory was also overwritten. However, the $UsnJrnl still contains the original FILE_CREATE record (with filename invoke-exfil.ps1, timestamp 2026-03-14 01:22:08) and the subsequent FILE_DELETE record (timestamp 2026-03-14 01:47:33). The journal is the only surviving evidence that this file ever existed on the volume.

5. Anti-Forensics Activity Timing

After completing data theft, a subject runs a cleanup script. The $UsnJrnl captures the sequence: FILE_DELETE for browser history files, FILE_DELETE for Prefetch files (*.pf), FILE_DELETE for Recent Items (*.lnk), and DATA_OVERWRITE for the Recycle Bin index. The timestamps show the cleanup ran between 02:42 and 02:43 — one minute of automated anti-forensics. The journal itself records the attacker’s cleanup activity as evidence.

Acquisition Methods

Live System — fsutil (Built-in Windows Tool)

:: Query the current journal state
fsutil usn queryjournal C:

:: Read journal entries (outputs to console; redirect to file)
fsutil usn readjournal C: csv > C:\Evidence\usnjrnl_live.csv

:: Enumerate specific USN records by file reference
fsutil usn readdata C:\path\to\specific\file.txt

:: Note: fsutil output is limited on older Windows versions
:: Prefer KAPE or MFTECmd for production forensics

Live System — Raw Copy Utilities

:: Using KAPE (Kroll Artifact Parser and Extractor)
kape.exe --tsource C: --tdest C:\Evidence\KAPE_Output --target UsnJrnl

:: Using RawCopy (bypasses NTFS file locks)
RawCopy.exe /FileNamePath:C:\$Extend\$UsnJrnl /OutputPath:C:\Evidence\

:: Using Velociraptor (remote collection via VQL)
:: Artifact: Windows.KapeFiles.Targets with target "UsnJrnl"
:: Or: SELECT * FROM parse_usn(device="C:")

Forensic Image — Direct Extraction

# Mount the forensic image (read-only)
mount -o ro,noexec,nodev,show_sys_files /dev/sdb1 /mnt/evidence

# Extract $UsnJrnl using The Sleuth Kit
# First, find the inode for $UsnJrnl
fls /path/to/image.E01 11 | grep UsnJrnl
# Output: r/r 58-128-1: $UsnJrnl

# Extract the $J data stream (ADS)
icat /path/to/image.E01 58-128-4 > /analysis/usnjrnl/\$J

# Note: the stream number for $J may vary;
# use istat to enumerate all streams on the inode
istat /path/to/image.E01 58

Parsing Tools & Analysis

Parsing with MFTECmd

:: Parse $J stream to CSV
MFTECmd.exe -f C:\Evidence\$J --csv C:\Analysis\USN_Output --csvf usnjrnl_parsed.csv

:: Output columns include:
::   EntryNumber, SequenceNumber, ParentEntryNumber, ParentSequenceNumber
::   Usn, Timestamp, FileName, Extension, FileAttributes
::   UpdateReasons (human-readable reason flags)
::   UpdateSourceFlags, SecurityId

:: Parse with body file output for timeline integration
MFTECmd.exe -f C:\Evidence\$J --body C:\Analysis\USN_Output --bodyf usn_body.txt

Parsing with USN-Journal-Parser

# Install USN-Journal-Parser
pip install usn-journal-parser

# Parse the $J stream
usn_parser /analysis/usnjrnl/\$J -o /analysis/usnjrnl/usn_parsed.csv

# Or use the Python API for custom filtering
python3 -c "
from usn_journal_parser import UsnJournalParser
parser = UsnJournalParser('/analysis/usnjrnl/\$J')
for record in parser:
    print(f'{record.timestamp} | {record.filename} | {record.reason_string}')
"

Mass Deletion Detection Script

# Detect bulk file deletion events (insider threat / ransomware indicator)

import pandas as pd

df = pd.read_csv('/analysis/usnjrnl/usnjrnl_parsed.csv')

# Filter for deletion events
deletes = df[df['UpdateReasons'].str.contains('FileDelete', na=False)].copy()

# Parse timestamps and create 1-minute buckets
deletes['Timestamp'] = pd.to_datetime(deletes['Timestamp'])
deletes['Bucket'] = deletes['Timestamp'].dt.floor('1min')

# Count deletions per minute
burst = deletes.groupby('Bucket').agg(
    DeleteCount=('FileName', 'count'),
    UniqueParents=('ParentEntryNumber', 'nunique'),
    SampleFiles=('FileName', lambda x: ', '.join(x.head(3)))
).sort_values('DeleteCount', ascending=False)

# Flag minutes with more than 100 deletions
suspicious = burst[burst['DeleteCount'] > 100]

print(f"Suspicious deletion bursts: {len(suspicious)}")
print(suspicious.head(10).to_string())

Sample Output

Suspicious deletion bursts: 2

Bucket                DeleteCount  UniqueParents  SampleFiles
2026-03-14 02:17:00   2847         1              Q4_Revenue_Final.xlsx, Board_Deck_2026.pptx, Customer_List.csv
2026-03-14 02:18:00   1353         1              Patent_Filing_Draft.docx, Source_Code_v3.zip, API_Keys.txt

Retention & Persistence

Anti-Forensics Resilience

The $UsnJrnl occupies a middle ground in anti-forensics resilience. It is more resistant than Prefetch or browser history (which are trivially cleared) but less resistant than the $MFT (which cannot be directly modified on a live system). The journal can be administratively deleted, but doing so is itself a detectable event.

MITRE ATT&CK Detection Mapping

$UsnJrnl analysis provides evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & Case Studies

Corroborating Artifacts

Case Study

References

1. Eric Zimmerman, “MFTECmd — $UsnJrnl Parser” — https://ericzimmerman.github.io/
2. PoorBillionaire, “USN-Journal-Parser” — https://github.com/PoorBillionaire/USN-Journal-Parser
3. Microsoft, “Change Journals (NTFS)” — https://learn.microsoft.com
4. SANS Institute, “NTFS Change Journal Forensics” — https://www.sans.org/blog/
5. 13Cubed, “$UsnJrnl Analysis for DFIR” — https://www.13cubed.com/blog
6. Junghoon Oh, “NTFS Log Tracker” — https://sites.google.com/site/forensaboratory/
7. ForensicArtifacts.com, “Windows NTFS Artifact Definitions” — https://github.com/ForensicArtifacts/artifacts
8. Microsoft, “fsutil usn” command reference — https://learn.microsoft.com