USN Journal Deletion
Deleting the NTFS change journal erases a record of file activity, but it is recoverable from the MFT, $LogFile, and shadow copies.
The NTFS Update Sequence Number journal ($Extend\$UsnJrnl:$J) is one of the most valuable artifacts in a Windows investigation: it records a compact, ordered log of every file create, write, rename, and delete on the volume, often retaining weeks of activity. Because it can reveal payload names that were dropped and deleted long ago, attackers — especially ransomware operators staging for impact — delete it to erase the trail of their tooling.
Deletion is trivial with a built-in command, which is exactly why it appears in many ransomware playbooks. But the journal is not the only place this activity is recorded, and the deletion command itself is loud.
How it works
A single fsutil call destroys the journal and resets its sequence space:
:: Delete the change journal on C: (often paired with shadow-copy deletion)
fsutil usn deletejournal /d C:Ransomware frequently chains this with vssadmin delete shadows /all /quiet and wevtutil cl in a single cleanup script. Deleting the journal does not zero the underlying clusters immediately — the old $J data stream becomes sparse/unallocated and the resident metadata is rewritten, but historical USN records often persist in slack and unallocated space until overwritten.
Detection & analysis
Static analysis:
- Carve unallocated space and volume slack for USN record signatures (
USN_RECORD_V2: a record-length field followed by major version2, minor version0). Tools:MFTECmd/UsnJrnlparser (Eric Zimmerman),usn.py, Velociraptor'sWindows.Forensics.Usn. Carved records frequently survive adeletejournal. - Inspect the
$MFTrecord for$Extend\$UsnJrnl: a journal that was deleted and recreated shows a recent$SIcreation time and aMaxUsn/FirstUsnreset, revealing both the deletion and its approximate time. - Reconstruct file activity from the
$LogFile(NTFS transaction log), which records MFT changes independently and overlaps the lost USN window for the most recent operations.
Dynamic analysis:
- Process auditing (Event ID 4688 / Sysmon 1) captures the
fsutil usn deletejournalcommand line — treat any such invocation on a server or workstation as high-severity, since legitimate use is rare. - Pull
$UsnJrnl:$Jfrom Volume Shadow Copies that predate the deletion; VSS snapshots frequently retain a full journal the live volume no longer has.
Detection rule hint: Alert on any process command line containing fsutil usn deletejournal (or the equivalent DeviceIoControl FSCTL_DELETE_USN_JOURNAL from non-administrative tooling), and on a $UsnJrnl MFT record whose creation time is far more recent than the volume's. Recovery path: carve unallocated space for USN_RECORD_V2 signatures and restore the journal from the most recent shadow copy.