Tracing Reused $MFT Entries Paths : Recovering Deleted File Paths Forensically with CyberCX UsnJrnl Rewind

Hey there! If you’ve been following my articles, you might already know the answer to this question.

But let me ask it again:

If we have $MFT, why do we need $UsnJrnl?

Understanding the Difference Between $MFT and $UsnJrnl

1. $MFT vs. $UsnJrnl

   While the $MFT (Master File Table) gives you a snapshot of the file system at specific points in time, the $UsnJrnl ($J) keeps a detailed record of file system changes over time.

   
   

2. Tracking Subtle Changes

   Example Exfiltration often involves small but significant actions—modifying, renaming, or deleting files. These actions may not always be captured by the $MFT, but $UsnJrnl logs them in detail, which is crucial for uncovering sophisticated exfiltration techniques.

   
   

   Example: Let’s say an attacker creates a ZIP file to exfiltrate data.

   • The $MFT will log the creation of the ZIP file.

   • The $UsnJrnl, however, will document every step: adding files to the ZIP, zipping the data, renaming the file, and moving it.

------------------------------------------------------------------------------------------------------------

This answers the initial question, but let’s raise a new one.

What Happens When MFT Entries Are Reused?

Here’s the scenario:

• A file is created, and its details are stored in the $MFT with a sequence number or file record.

• The file is deleted, and while $UsnJrnl logs this event, the $MFT entry becomes available for reuse.

• When a new file is created, it might reuse the same MFT sequence number or file record.

  
  

As $UsnJrnl/$J doesn’t track full file paths but instead logs file names, entry numbers, and sequence numbers, a question arises: If a file's $MFT record is removed or reused by another file, how can you reconstruct the original file path using $MFT and $J?

Screenshot of $J

Forensic tools often correlate $UsnJrnl with $MFT to reconstruct file paths, but reused MFT entries can complicate this process.

------------------------------------------------------------------------------------------------------------

Okay, Lets give you practical example so u can understand easily

Example: Recovering the Path

Files Used:

• $MFT parsed file : mftOutput.csv

• $UsnJrnl parsed file: j Output.csv

Observations:

Lets choose a file name creds.txt.txt

1. In the $UsnJrnl:$J file, creds.txt.txt was identified with:

   

   • Entry Number: 1124

   • Sequence Number: 4

   • Update Reason: File Delete | Close(This update reason means file was deleted correct and $mft file record available for reuse)

   
   

2. Searching with file name in the $MFT file revealed no file with the name(creds.txt.txt) exits.

   

   
   

3. Now Searching for Entry Number 1124 in the $MFT file revealed that the entry had been reused. The sequence numbers confirmed it had been overwritten four times, with the current file being log.old.

   

4. This reuse makes it impossible to locate the deleted file's path directly in the $MFT. (Correct)

------------------------------------------------------------------------------------------------------------

Solution: Using CyberCX UsnJrnl Rewind

Research and tools from CyberCX come to the rescue. They developed a script called UsnJrnl Rewind, which correlates $MFT and $UsnJrnl:$J data to reconstruct deleted file paths, *********even for entries that have been reused************.

Steps to Use:

1. Clone the tool from the GitHub repository:CyberCX UsnJrnl Rewind

   

2. Set up the environment (e.g., WSL or Linux).

3. Run the script with the $MFT and $UsnJrnl parsed files as inputs:

python usnjrnl_rewind.py -m MFT_Output.csv -u UsnJrnl_Output.csv output-path

4. The tool produces two outputs:

   • NTFS.sqlite

   • USNJRNL.fullpath

------------------------------------------------------------------------------------------------------------

Verifying the Results

• Open the USNJRNL.fullpath file to locate the path of creds.txt.txt.

• Additionally, you can trace the (File record) file's lifecycle:

• Sequence 1: Overflowset → Deleted

• Sequence 2: NewTextDocument.txt → Deleted

• Sequence 3: log.old~rf14 → Deleted

• Sequence 4: log → Currently active on the system.

And there you have it! This research has taught us valuable insights into forensic investigations. With that, we wrap up this article.

See you in the next one—until then, take care and goodbye!

----------------------------------------------Dean----------------------------------------------------