the usn journal logs every ntfs file change

your file system has a security camera and most people don't know it exists

every windows machine with ntfs has been quietly filming file activity this whole time. not in a spooky way, in a "this is literally how the filesystem stays consistent" way. it's called the usn journal (update sequence number journal) and it logs every create, rename, and delete on the volume with a timestamp and a reason code. attackers who drop a tool, run it, then delete it to "clean up" don't actually clean up anything. they just leave three log entries instead of one file. this post is about how that journal works and how you, as the person defending your own machine, can read it.

what the usn journal actually is

ntfs keeps a running log of changes to files and directories so things like search indexing, backup software, and file replication can figure out what changed without rescanning the whole disk. the log lives in a special hidden file at C:\$Extend\$J. every entry records things like the file name, the parent directory, a timestamp, and a "reason" flag such as file created, file deleted, renamed, or data extended. it's not designed as a security tool, it's a convenience feature. but convenience features that log timestamped activity are basically a gift to defenders.

the key thing to understand: the usn journal is separate from the file itself. deleting a file removes the file record eventually, but the journal entry describing that deletion often survives, especially on a system that hasn't been rebooted or heavily used since. that's the whole point of using it defensively, it can outlive the thing it's describing.

pulling the journal with mftecmd

MFTECmd.exe -f "C:\$Extend\$J" --csv .

this is eric zimmerman's mftecmd tool, and here's what each part does:

-f "C:\$Extend\$J" tells the tool exactly which file to parse, in this case the usn journal file itself rather than the master file table (mftecmd can parse both, they just live in different spots).

--csv . tells it to dump the parsed output as a csv file in the current directory. csv output matters here because it means you can pipe it straight into powershell for filtering, instead of scrolling through a giant text dump by hand.

run this from an elevated prompt, because reading system files like this requires admin rights. the output will be a file usually named something like YYYYMMDD_HHMMSS_UsnJrnl.csv in your working directory.

filtering for the stuff that matters

Import-Csv *_UsnJrnl.csv | ? UpdateReasons -match 'FileDelete' | select UpdateTimestamp,Name

breaking this down: Import-Csv loads the parsed journal into powershell as objects you can actually work with. ? UpdateReasons -match 'FileDelete' (the ? is shorthand for Where-Object) filters down to entries where the reason code includes a file deletion. select UpdateTimestamp,Name trims the output to just the two columns you actually care about right now, when it happened and what it was called.

you can swap 'FileDelete' for things like 'FileCreate' or 'RenameOldName' to trace the full life cycle of a file. that drop, execute, delete pattern attackers love shows up as three entries close together in time, usually in a temp folder or somewhere weird like a recycle bin subpath. that clustering is the tell.

why this beats just checking recent files

windows keeps other artifacts like the mft, recycle bin records, and prefetch, but those can be overwritten or cleared. the usn journal is different because it's an append-only log by design, and it's not something most cleanup scripts or "anti-forensic" tools even think to touch. an attacker who deletes a file and empties the recycle bin has done nothing to the journal entry recording that the delete happened in the first place.

the takeaway

the usn journal isn't there to catch attackers, it's a side effect of how ntfs stays consistent, and that's exactly why it's so useful. on your own machine, if you ever suspect something ran and got deleted, pull $J with mftecmd, filter for deletions and creations around the timeframe you care about, and look for that create-use-delete cluster. do this regularly enough on systems you're responsible for and you'll start recognizing normal noise versus something that actually needs a closer look. the camera's already rolling, you just have to check the tape.