Updated 18 Feb,2025
Ever wonder how your computer keeps track of all the changes happening to files and folders?
That’s where NTFS journaling comes in. Think of it as a built-in security camera for your file system, constantly recording what’s going on. For forensic investigators, this is a goldmine of information, helping them rewind time and see exactly what happened on a system.
--------------------------------------------------------------------------------------------------------
The Two Journals: $LogFile and $UsnJrnl
NTFS actually has two separate journaling features, each with its own purpose:
$LogFile – This is like a system safety net. It records every change happening at a low level, ensuring that if the system crashes, it can recover without corrupting data.
$UsnJrnl – This is more like an activity tracker, logging file and folder changes so applications (like antivirus or backup software) can react efficiently.
Both of these logs give investigators an incredible amount of visibility into past file system activity. Since they’re also backed up inside Volume Shadow Copies, they can provide insights stretching back days, weeks, or even months!
--------------------------------------------------------------------------------------------------------
How These Logs Help Investigators
Think of an airplane’s black box.
There are two recorders: one tracks flight data (like altitude and speed), and the other records cockpit conversations. In a similar way:
$LogFile is like the flight data recorder, tracking deep system changes at a technical level.
$UsnJrnl is like the cockpit voice recorder, summarizing higher-level file activity.
A better analogy might be comparing them to network security tools:
$LogFile is like full packet capture—detailed but heavy on data.
$UsnJrnl is like NetFlow logs—less detailed but covers a longer time span.
--------------------------------------------------------------------------------------------------------
Breaking Down $LogFile
$LogFile’s main job is keeping NTFS stable, making sure the system doesn’t corrupt itself if something goes wrong.
Changes to the Master File Table (MFT)
Directory updates in $I30 indexes
Modifications to $UsnJrnl itself (if enabled)
Changes in the $Bitmap file, which tracks disk space
Even self-maintenance events (it logs its own updates!)
What makes $LogFile especially valuable is that it doesn’t just log what changed—it records the actual data that was modified. This means forensic analysts can sometimes recover deleted data by analyzing these logs. However, since NTFS constantly updates multiple system files at once, even simple actions like creating a new file can generate dozens of log entries.
--------------------------------------------------------------------------------------------------------
The Downside: $LogFile is Short-Lived
The catch?
$LogFile is only 64MB by default. That might sound like a lot, but with so much happening under the hood, it typically only holds a few hours’ worth of data on active systems. However, if a system is mostly idle or you’re looking at logs from a secondary drive, you might find logs stretching back days or even weeks.
Want to check or increase your $LogFile size? Use these commands:
Check current size: chkdsk <volume> /L
Increase size: chkdsk <volume> /L:<size>
--------------------------------------------------------------------------------------------------------
What NTFS Journaling Won’t Do
While NTFS journaling is great at tracking file system changes, it doesn’t protect actual file content. If your system crashes while a file is being written, NTFS can repair the file system, but the file itself might still be corrupt. This is why databases and critical applications maintain their own transaction logs—to ensure their data stays intact even if the system crashes.
--------------------------------------------------------------------------------------------------------
$UsnJrnl
The NTFS file system has a hidden gem called the Update Sequence Number (USN) Change Journal, stored in a system file named $UsnJrnl. This file keeps a log of all file and directory changes, along with a reason code indicating what type of modification occurred. While it does help with system recovery in some cases (like quickly re-indexing a volume), its primary role is to let applications efficiently track file changes across the system.
Why Does $UsnJrnl Matter?
Think about how Windows Backup works. Instead of scanning every single file to see what’s changed, it just checks the USN journal for recent modifications—saving tons of time. The same applies to antivirus software, the Windows Search Index,
File Replication Service (FRS), and other applications that need to monitor file activity. Because of its efficiency, Microsoft made sure that $UsnJrnl was enabled by default starting with Windows Vista (it was available in Windows XP and 2000 but usually disabled).
--------------------------------------------------------------------------------------------------------
How It Works: A Simpler View
Compared to another NTFS journal, $LogFile, which tracks every tiny system change, $UsnJrnl is much more concise and user-friendly. If a new file is created, for instance, $LogFile might log over 20 detailed system events, while $UsnJrnl simplifies it down to just a few records. This makes it a lot easier for investigators and forensic tools to interpret.
Each USN record logs:
File or folder name
MFT number (unique identifier in NTFS)
Parent directory’s MFT number
Timestamp of change
Reason code (what changed?)
File size and attributes (hidden, read-only, archived, etc.)
Because it logs only major changes, $UsnJrnl can store several days or even weeks of history, depending on system activity. And since these logs are often backed up in volume shadow copies, forensic investigators can sometimes recover over a month’s worth of historical file activity.
--------------------------------------------------------------------------------------------------------
Where and How Is It Stored?
$UsnJrnl isn’t stored like a regular file—it’s actually an alternate data stream (ADS) of the $UsnJrnl system file. Specifically, the USN records are kept in a data stream called $J. Unlike numbered log entries, each record is positioned based on its offset into the $J stream. Every file and directory has an Update Sequence Number in its MFT record, which links to the matching entry in $J.
Since $UsnJrnl is a locked and hidden system file, standard tools won’t allow access. You’ll need forensic utilities to extract it. Also, because $J is a sparse file (meaning it appears large but isn’t fully written to disk), when you try to copy it, the system will fill in the missing parts, leading to massive file sizes. It can often exceed 3 GB on a typical workstation, making remote collection tricky. Fortunately, it compresses well.
--------------------------------------------------------------------------------------------------------
A Hidden Benefit: Recovering Deleted USN Records
Even though the journal size is capped (usually 32 MB), Windows tricks NTFS into thinking it’s a much larger file. When new entries are added, Windows allocates disk space at the end while deallocating older parts, marking them as sparse (empty). This means deleted USN records often remain in unallocated space, allowing forensic tools to recover them.
--------------------------------------------------------------------------------------------------------
The $Max Data Stream
There’s another small alternate data stream in $UsnJrnl called $Max. It’s tiny (about 32 bytes) and stores metadata like the maximum allowed size of the journal.
--------------------------------------------------------------------------------------------------------
Investigation with Kape.
Use KAPE to acquire the NTFS Master File Table (MFT) and journals. Then, we'll employ MFTECmd to parse the MFT and USN Journal, as the $LogFile parsing functionality is not available in MFTECmd.
Kape triage uses compound target, showcasing snippets of the MFT, $J, $LogFile and link files targets. The output structure of Kape, with raw files and parsed outputs, is detailed, emphasizing the efficiency of this workflow in gathering artifacts for analysis.
Now as Kape can be used as GUI version or Cmd version its depend on your choice.
command
-------------------------------------------------------------------------------------------------
Final Thoughts
The NTFS USN journal is an incredibly valuable forensic resource. It logs file changes in a structured, efficient manner and can provide a historical view of system activity stretching back weeks or even months. While Windows limits its size, forensic analysts can often recover old records, making it a powerful tool in investigations. Whether for system maintenance, security monitoring, or digital forensics,
----------------------------------------------Dean----------------------------------------------
Comments