BIPI
BIPI

USN Journal Forensics: Recovering Deleted File Evidence from NTFS

Cybersecurity

The NTFS USN Journal logs every file create, rename, delete, and attribute change. Even after a file is gone, its change history persists in $UsnJrnl and can rebuild attacker file operations step by step.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 18, 2024 · 10 min read

#dfir#forensics#ntfs#usn-journal#deleted-files

The NTFS Change Journal, stored as the alternate data stream $UsnJrnl:$J on every NTFS volume, is a sequential log of file system activity. Every time a file or directory is created, renamed, overwritten, deleted, or has its security descriptor changed, the NTFS driver appends a USN record. The journal is circular: old entries are overwritten as the file grows. On a busy system the journal may cover only 24 to 72 hours of activity, but on a forensic image taken shortly after an incident it is an invaluable source of deleted file evidence.

USN Journal Structure

Each USN record contains: the Update Sequence Number (monotonically increasing 64-bit integer), the file reference number (MFT entry number plus sequence number), the parent file reference number, a timestamp in FILETIME format, reason flags, source info flags, security ID, file attributes, and the file name. There is no full path: the path must be reconstructed by walking parent references up through the MFT.

  • USN_REASON_FILE_CREATE: a new file was created on the volume
  • USN_REASON_FILE_DELETE: the file was deleted (last handle closed after deletion)
  • USN_REASON_RENAME_OLD_NAME: captured immediately before a rename operation
  • USN_REASON_RENAME_NEW_NAME: captured immediately after a rename operation
  • USN_REASON_DATA_OVERWRITE: file data was written and overwritten
  • USN_REASON_CLOSE: final record written when all handles to the file are closed

Parsing with fsutil and MFTECmd

On a live system, fsutil usn readjournal C: csv > usn_live.csv exports current journal records. For forensic images, Eric Zimmermann's MFTECmd can parse the raw $J stream from an offline image: MFTECmd.exe -f '$J' --csv C:\output\ --csvf usn.csv. The resulting CSV includes columns for UpdateTimestamp, Name, FileAttributes, UpdateReasons, ParentEntryNumber, and ParentSequenceNumber, giving you everything needed to reconstruct paths.

  1. Extract $J, $MFT, and $Boot from the forensic image using KAPE or Arsenal Image Mounter
  2. Run MFTECmd.exe -f '$MFT' --csv C:\output\ to build the MFT reference map
  3. Run MFTECmd.exe -f '$J' --csv C:\output\ to parse journal records
  4. Load both CSVs in Timeline Explorer and join on ParentEntryNumber to reconstruct paths
  5. Filter on USN_REASON_FILE_DELETE with timestamps bracketing the incident window

Attacker Blind Spots: What Adversaries Get Wrong

Sophisticated attackers delete files and clear event logs, but few think to purge the USN Journal. The reason is that $UsnJrnl is a system metadata stream: deleting it requires a privileged fsutil usn deletejournal /D C: call, which itself generates a detectable USN record before the journal is destroyed. Even then, sparse clusters on disk may retain earlier records. The sequence RENAME_OLD_NAME followed by RENAME_NEW_NAME followed by FILE_DELETE within seconds is a classic indicator of a rename-then-delete anti-forensic technique.

undefined
undefined
undefined
undefined
undefined
undefined
undefined
undefined

Recovering Deleted File Names and Paths

After a file is deleted, its MFT record may be reused. If the MFT entry has been reallocated, the file name in the USN record is your only source for the original name. This is critical when investigating malware droppers that write a payload to disk, execute it, then immediately delete it. The $J record will show: FILE_CREATE for the payload name, DATA_EXTEND records during write, CLOSE after execution, then FILE_DELETE within seconds.

  • Search for FILE_CREATE immediately followed by FILE_DELETE within 60 seconds
  • Look for RENAME operations on files in %TEMP% or %APPDATA% directories
  • Correlate USN timestamps with Prefetch last-run times for the same binary name
  • Check parent entry numbers to confirm the file lived in a suspicious directory
  • Use MFT sequence numbers to detect whether the entry was quickly reused (indicator of rapid churn)

Correlation with $LogFile

The NTFS $LogFile is a separate journal tracking metadata transactions for crash recovery. It contains overlapping information with $UsnJrnl but at a lower level (individual MFT record updates and B-tree page writes). MFTECmd can also parse $LogFile. When $UsnJrnl records are unavailable, $LogFile redo and undo records can corroborate file creation and deletion activity, though the data is harder to interpret without specialist knowledge.

The USN Journal is the file system's audit trail. It records the what and when of every file operation, and attackers who skip clearing it leave a timestamped breadcrumb trail from dropper to execution to deletion.

Tooling Summary

  • MFTECmd.exe (Zimmermann): parses $J and $MFT from offline images, outputs CSV
  • fsutil usn readjournal: live system USN enumeration (requires admin)
  • Timeline Explorer (Zimmermann): pivot and filter across USN and MFT CSVs
  • KAPE: automated collection of $J, $MFT, $LogFile, and $Boot in a single pass
  • Autopsy with NTFS module: GUI-based USN browsing integrated with case timeline

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.