$LogFile vs $UsnJrnl vs $MFT: Which NTFS Artifact When

TL;DR. $MFT tells you what exists now. $UsnJrnl:$J tells you what kind of change happened to which file and when, over days to weeks. $LogFile tells you exactly what bytes changed — old and new names, old and new timestamps — but only for the last minutes to hours and without a clock of its own. Start with the $MFT and the USN journal, then go to $LogFile for the questions they cannot answer: "what was the value before?" and "what happened in the last hour that the other two lost?"

All three live in the same volume, describe the same files by the same MFT references, and are routinely collected together. They are not interchangeable. Picking the wrong one first costs hours; ignoring the third one costs findings.

The three in one table

The last line matters in intrusions. The USN journal is an optional feature that an administrator — or an attacker with admin rights — can delete. $LogFile is part of how NTFS works; it cannot be disabled on a mounted volume, only resized (chkdsk /L, per Microsoft's chkdsk reference).

What each one sees when a file is renamed

Take one event: rc.tmp in C:\Users\Public becomes rclone.exe.

• $MFT after the fact: one FILE record named rclone.exe, parent Public. The old name is gone unless a stale $I30 slack entry survives.
• $UsnJrnl:$J: two records with the same file reference — RENAME_OLD_NAME with rc.tmp, then RENAME_NEW_NAME with rclone.exe — each with a timestamp.
• $LogFile: a DeleteIndexEntry removing rc.tmp from the parent's index, an AddIndexEntry adding rclone.exe, and $FILE_NAME attribute changes in the FILE record. The index entries embed full $FILE_NAME structures, including the four $FILE_NAME timestamps.

For a rename, the USN journal is simpler and dated. $LogFile only wins if the USN records are gone or you need the embedded values.

What each one sees when a timestamp is rewritten

Now the case where $LogFile is unique. An attacker sets m64.exe's creation time to 2019-03-19.

• $MFT: $STANDARD_INFORMATION created = 2019-03-19. $FILE_NAME created = today. That mismatch is a classic hint, but it is only a hint: a copy, an archive extraction or an installer can produce odd combinations too.
• $UsnJrnl:$J: a record with reason BASIC_INFO_CHANGE at the time of the change. You know something in the basic information (times or attributes) changed, not what.
• $LogFile: an UpdateResidentValue on $STANDARD_INFORMATION whose undo bytes hold the previous creation time and whose redo bytes hold 2019-03-19. That is the rewrite itself.

This is why timestomping analysis leans on the log. The method, and its false positives, are in detecting timestomping with the $LogFile. Cho's 2013 paper (Computers & Security 34) makes the same point: past time values found in $LogFile turn a suspicious timestamp into evidence.

How they link together

The three artifacts share keys, which is what David Cowen called the NTFS TriForce:

That last row is useful. The LogFileParser readme notes that when the USN journal is active, the USN records written during the log's lifetime are also present inside $LogFile, and it decodes them into a separate CSV. In practice the USN journal usually still reaches further back, but for the most recent window the log can fill a gap.

Which one first? Four scenarios

"Which files did this account create this morning?" USN journal first (dated, long history), $MFT for paths. $LogFile only if the morning is still in it.

"Was this binary backdated?" $MFT to spot the $SI/$FN mismatch, then $LogFile to find the actual rewrite and the original value. The USN journal gives the time of the BASIC_INFO_CHANGE.

"The attacker deleted the USN journal." $LogFile for the last minutes to hours; $MFT for current state and deleted-but-not-reused entries; Volume Shadow Copies for older copies of all three.

"What did that deleted text file say?" Only $LogFile has a chance, and only if the file was small enough to be resident and the relevant records survive. See recovering deleted-file evidence.

Tools for each

• $MFT: any MFT parser (MFTECmd, analyzeMFT, commercial suites).
• $UsnJrnl:$J: the sibling USN journal parser in the browser, or MFTECmd. usnparser.com also has its own comparison of the three artifacts, written from the USN side.
• $LogFile: the in-browser $LogFile parser (drop the $MFT next to it for full paths), LogFileParser, NTFS Log Tracker, TZWorks mala — compared in $LogFile parsers compared.

Remember that the same volume's files must be collected together. A $LogFile from Monday and an $MFT from Tuesday will resolve some MFT entries to the wrong names once entries have been reused.

Frequently asked questions

What is the difference between $LogFile and $UsnJrnl?

$UsnJrnl:$J is a change journal meant for applications: one record per change with a timestamp, reason flags, file reference and name, often covering days or weeks. $LogFile is NTFS's crash-recovery log: low-level redo and undo bytes for every metadata change, with no timestamps of its own, covering minutes to hours.

If I have the USN journal, do I still need the $LogFile?

Yes when the question is about values rather than events. The USN journal says a file's basic information changed; the $LogFile can show the old and new timestamps. It also helps when the USN journal was deleted or disabled, for the most recent activity.

Further reading

• Microsoft Learn, Change Journals.
• David Cowen, NTFS TriForce — a deeper look inside the artifacts.
• Maxim Suhanov, How the $LogFile works?

Related articles

• NTFS $LogFile forensics: the complete guide
• How far back does the $LogFile go?
• Detecting timestomping with the NTFS $LogFile