USN Journal vs $MFT vs $LogFile: Which NTFS Artefact, and When

NTFS gives a forensic analyst three big metadata artefacts and the surest way to lose a day is to read the wrong one for the question you actually have. The short version:

Read on for the decision tree I actually use, and the reasons each artefact will fail you on its own.

$MFT — "what exists, right now"

The Master File Table is the spine of NTFS. Every file or directory has at least one 1024-byte entry holding $STANDARD_INFORMATION, one or more $FILE_NAME attributes, and the data runs that point at the actual content.

Reach for $MFT when the question is:

• What exists on this volume right now, including recently deleted entries before they are reused.
• What are the four NTFS timestamps (M/A/C/B in both $STANDARD_INFORMATION and $FILE_NAME) for a specific file.
• Can I recover the bytes of a deleted file whose entry is still allocated.
• What is the full path of a record that only carries a parent reference number — this is exactly how the parser on this page resolves USN records when you also drop $MFT.

What it will not tell you, no matter how hard you squint:

• What happened to a file last Tuesday at 14:32. The four timestamps are an end-state, not a history. They tell you when the file was created and last touched. They do not tell you it was renamed, then renamed back, then truncated, then overwritten, then deleted, then a new file created at the same MFT entry.

Tooling: Eric Zimmerman's MFTECmd is the de-facto parser. Omer BenAmram's mft Rust crate and David Kovar's analyzeMFT Python script cover the open-source side.

$UsnJrnl:$J — "what happened, in what order"

The Update Sequence Number Journal records every create, delete, rename, truncate, attribute change and close that happens on the volume. For background, the introduction post covers the on-disk format and the reason code post is the bit-level field reference.

Reach for it when the question is:

• What was the lifecycle of this file, including renames, before it was deleted.
• Did anything mass-encrypt files on this volume — see ransomware detection.
• Did anything mass-stage and archive files for exfil — see exfiltration detection.
• Were timestamps tampered with — see timestomping.
• What was the user doing between 14:00 and 16:00 — see activity timeline reconstruction.

What it will not tell you:

• Who did anything. No user, no process, no command line. Correlate with Security.evtx 4663 (only if SACLs were configured) or Sysmon event 11.
• The contents of any file. The journal records that a stream changed, not what bytes used to be there.
• Anything older than the ring-buffer window. Defaults range from ~10 MB on a stripped-down client to 1 GB+ on a properly sized server, translating to days or weeks of history.

Tooling: Airbus CERT's usnrs, PoorBillionaire's USN-Journal-Parser, Eric Zimmerman's MFTECmd (which parses $J too), and the WebAssembly parser on this page.

$LogFile — "what NTFS was about to do"

This is the metadata journal NTFS uses for crash recovery. It records before/after images of every metadata write — INDEX_ALLOCATION updates, attribute changes, MFT entry rewrites. The format is undocumented but well reverse-engineered; Joachim Metz's libfsntfs is the most thorough open reference.

Reach for it when:

• A file was created and deleted within the same few thousand transactions and the parent directory entry has already been overwritten. $LogFile may still hold the "before" image with the leaf name and parent.
• You suspect direct $MFT manipulation. $LogFile records the raw write even when the visible state looks clean afterwards.
• The journal is too sparse (small or recently rotated) to cover the moment of interest, but it happened within the last hour.

What it will not give you:

• Anything outside the rotation window. $LogFile is small and heavily reused. On a busy file server the whole transaction history can roll over in under an hour.
• File content. The before/after images are metadata only.

Tooling: Jonas Schicht's LogFileParser and any parser built on libfsntfs.

The decision tree I actually use

Do you know WHICH file?
├── Yes → Want current state? → $MFT (path, timestamps, size)
│         Want history?       → $UsnJrnl first, $LogFile for the very recent past
└── No  → Time window?
          ├── Last few minutes → $LogFile (most granular)
          ├── Last days/weeks  → $UsnJrnl (best signal/noise)
          └── Long ago         → $MFT only, expect to settle for end-state timestamps

Are you correlating across many files at once?
└── $UsnJrnl is the only one of the three with a sortable, per-operation timeline.

Was the file deleted and you need to prove it existed?
└── $UsnJrnl first (FileDelete record carries parent reference and timestamp)
    $LogFile as a backstop if the deletion is fresh
    $MFT only if the entry has not yet been reused

Combining them is where the real work happens

The three artefacts compose well, which is the part nobody emphasises until they need it.

$MFT + $UsnJrnl is the canonical pair. The MFT provides the directory tree for path resolution; the journal provides the operation history. The parser on this page automatically resolves full paths for every journal record when you drop both files. Acquire them together; you will save yourself a round trip nine times out of ten.

$LogFile is the backstop. When the journal is too small to cover the moment of interest, or when you suspect direct MFT tampering, $LogFile is where you reach.

For wider context, pair the three NTFS artefacts with EVTX (process and object events), Prefetch and AmCache (execution evidence), Shimcache (program-running-at-some-point), registry hives, LNK files and jump lists for user-opened-file evidence, browser history, SRUM for resource usage, and the RecentFileCache.

Further reading

• Microsoft Learn — Master File Table and Change Journals.
• Brian Carrier, File System Forensic Analysis — still the book-length reference on NTFS internals.
• Joachim Metz, libfsntfs documentation — the most detailed open reference on $LogFile internals.
• SANS DFIR — the Windows Forensic Analysis poster is a single laminated page that puts the artefact stack in one place.