← Back to blog

Recovering evidence of deleted files with the USN journal

When a file has been deleted, gone from the recycle bin, and the MFT entry has been recycled — the USN journal often still has its name, parent and timeline. A guide to extracting that evidence.

5 min read

The most common question forensic analysts get from non-technical stakeholders is some variant of "can you prove that this file existed?". When the file has been deleted from disk, the recycle bin emptied, and enough time has passed that the $MFT entry has been overwritten, the answer usually depends on what the USN journal still remembers.

This post walks through what the journal preserves about deleted files, how to extract that evidence, and the situations in which the journal is your last witness.

What the journal keeps after deletion

When a file is deleted on NTFS, several things happen:

  1. The $FILE_NAME entry in the parent directory is unlinked.
  2. The MFT entry is marked unused — but not zeroed.
  3. The USN journal gets a FileDelete | Close record naming the file, its parent reference, its MFT entry, and the timestamp.

The journal record is the most resilient of the three. The directory entry disappears the moment the parent is rewritten; the MFT entry can be reused as soon as a new file is created; the journal record sits in a ring buffer that turns over only after days or weeks of activity.

That means, for files deleted days ago, the journal often gives you:

  • The filename (just the leaf name, not full path).
  • The parent directory MFT reference — combine with a parsed $MFT and you have the path.
  • The deletion timestamp in UTC.
  • The MFT entry number the file occupied (useful for cross-referencing carved artefacts).
  • A lifecycle trace: the FileCreate, DataExtend, BasicInfoChange records before deletion tell you when the file was created, how it was written, and whether its timestamps were ever modified.

A minimal recovery workflow

Once you have a parsed journal (the parser on this page or usnrs work; see the extraction guide for how to obtain $J and $MFT):

  1. Filter by FileDelete to surface every deletion in the window. Sort by timestamp.
  2. For each deletion of interest, group by FileReferenceNumber to see the file's full history — creation, writes, rename pairs, attribute changes, and finally the delete.
  3. Resolve the parent path via the $MFT. With both files supplied, our parser does this automatically.
  4. Cross-check $LogFile if the deletion is very recent — it may still contain the "before" image of the directory entry, giving you a second, independent witness.

The combination "I have an MFT reference, a filename, a parent, a creation and a deletion timestamp" is usually enough to satisfy a legal hold or to anchor a deeper investigation.

When the parent path can't be resolved

Sometimes the parent MFT entry has itself been recycled by the time you look — particularly on filesystem-busy hosts. In that case the journal gives you the filename and the parent reference number, but $MFT no longer knows what folder that number used to be.

Three things usually help:

  • Earlier RenameNewName records on the parent reference — these may carry a path-resolvable parent at the time of the rename.
  • $LogFile index entries — undocumented but covered by libfsntfs.
  • Sibling files in the same parent reference — group all journal records by parent. If one of the siblings was renamed into a directory whose MFT entry is still valid, you can pivot through it.

This is also why provisional reports from this tool say "filename: notes.docx" with no path: we err on the side of not inventing a path we can't verify.

"Wiped" doesn't mean gone

A handful of file-shredding tools (CCleaner, Eraser, BleachBit) overwrite the file content and then delete it. They leave the same journal records as a normal delete plus the overwrite records. The journal therefore makes "secure deletion" loud, not silent:

  • Multiple DataOverwrite | Close records on the file before its FileDelete | Close indicate intentional content overwriting.
  • A FileCreate and FileDelete of the same file within seconds, with overwrites in between, is the canonical pattern.
  • Where the shredder also wiped slack space by writing temp files, those temp files have their own create/extend/overwrite/delete sequences — a swarm of records around the moment of evidence destruction.

The MITRE ATT&CK technique that maps to this is T1485 Data Destruction and T1070.004 File Deletion.

What about the file's content?

The USN journal never carries content — only metadata about operations. If you need bytes back, the journal points you at:

  • The MFT entry number of the deleted file. If the entry hasn't been reused, the MFT still holds the data runs and the file content may be recoverable via The Sleuth Kit's icat or X-Ways.
  • The $LogFile before-images for very recent deletions.
  • Volume Shadow Copies (VSS) if they exist — the deleted file may live in a previous snapshot.
  • Application-specific stores — OneDrive's recycle bin, the Office "Autosaved" folder, browser caches.

The journal's role here is to tell you that a file existed and when it was deleted — the rest of the recovery is downstream.

Practical limits

  • The journal has a time window. Files deleted before the ring buffer wrapped to the oldest record we have are simply gone from this artefact. Pull $LogFile and shadow copies as a complement.
  • Some operations don't hit the journal: file-system-level encryption changes, sparse-region writes that touch only the allocation map, and NTFS reparse-point manipulations may produce no DataExtend/DataOverwrite records.
  • FileDelete without a preceding FileCreate in the same window means the file was created before the journal's current oldest record — its lifecycle is partial, but you can still anchor the deletion timestamp.

For deeper artefact context, see the SANS Windows Forensic Analysis poster and the Microsoft Learn change-journal reference.