← Back to blog

USN journal vs $MFT vs $LogFile: which NTFS artefact for which question?

A side-by-side reference for the three NTFS metadata artefacts every Windows forensic investigation eventually touches — what each one records, what it doesn't, and when to reach for which.

4 min read

NTFS gives a forensic analyst three big metadata sources, and the easiest way to lose a day is to read the wrong one. Quick map:

ArtefactWhat it recordsTimespanGranularityLives at
$MFTThe current state of every file and directory on the volume — names, sizes, timestamps, parent"Right now" plus deleted entries until reusedPer fileMFT entry 0
$UsnJrnl:$JA circular log of every file create/delete/rename/modifyDays to weeksPer operation\$Extend\$UsnJrnl:$J (alternate data stream)
$LogFileTransaction log NTFS uses to recover from a crash — raw before/after images of metadata writesMinutes to hoursPer metadata transaction\$LogFile (MFT entry 2)

This post gives the practical decision tree: given a question, which artefact answers it.

$MFT — "what exists, right now"

The Master File Table is the spine of NTFS. Each file or directory has one entry (1024 bytes typically), holding $STANDARD_INFORMATION, one or more $FILE_NAME attributes, and the data runs. Microsoft documents the structure in the NTFS reference and Brian Carrier's File System Forensic Analysis is the canonical book-length treatment.

Use it for:

  • "What's on this volume?" — including timestamps for every entry.
  • Reconstructing full paths from a parent-MFT-entry chain (this is how our parser resolves paths for journal records when you also supply $MFT).
  • Recovering recently deleted files — until the entry is overwritten, its data runs may still be intact.

It will not tell you:

  • What happened to a file last Tuesday at 14:32 — $MFT only carries the four $STANDARD_INFORMATION and $FILE_NAME timestamps, which are an end-state, not a history.

Tooling: Eric Zimmerman's MFTECmd is the de-facto parser, with mft (Rust) and analyzeMFT (Python) as solid open-source alternatives.

$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, see our introduction to the format and the reason code reference.

Use it for:

  • Reconstructing a file's lifecycle even after it has been deleted.
  • Timeline reconstruction for incident response, especially RenameOldName/RenameNewName pairs and DataOverwrite clusters.
  • Detecting ransomware patterns at scale (see our post on the topic).

It will not tell you:

  • Who did anything — no user, process or command line. Pair with Security.evtx (event ID 4663) or with Sysmon.
  • The contents of any file — only that it changed.
  • Anything older than the ring-buffer window. Default sizes vary from ~10 MB on a client to 1 GB+ on servers, which translates to days/weeks of history.

Tooling: usnrs, PoorBillionaire/USN-Journal-Parser, the parser on this site.

$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; the Joachim Metz libfsntfs repo is the most thorough open reference.

Use it for:

  • Recovering files that were created and deleted within the same minutes — $LogFile may still have the deletion's "before" image, which contains the file's filename and parent.
  • Catching anti-forensic activity that touched $MFT directly — $LogFile records the write even if the visible state looks clean.

It will not tell you:

  • Anything outside the last few thousand transactions — $LogFile is heavily rotated, often within an hour on a busy machine.
  • File content. Only metadata changes are logged.

Tooling: LogFileParser and the parsers built on top of libfsntfs.

The decision tree

Do you know WHICH file?
├── Yes → Want current state? → $MFT (path, timestamps, size)
│         Want history?      → $UsnJrnl  (then $LogFile for very recent)
└── No  → Time window?
          ├── Last few minutes → $LogFile (most granular)
          ├── Last days/weeks  → $UsnJrnl (best signal/noise)
          └── Long ago         → $MFT only (timestamps may be all you have)

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

Combining them

The three artefacts compose well:

  1. $MFT + $UsnJrnl is the canonical pair — $MFT provides the directory tree for path resolution, $UsnJrnl provides the operation history. This is exactly what the parser on this page does when you drop both files.
  2. $LogFile is a backstop for the very recent past, particularly useful when $UsnJrnl is too sparse (small or disabled).
  3. For wider context, add Security.evtx (process/object events), Prefetch (execution evidence), and the registry hives — see the SANS Windows Forensic Analysis poster for the full picture.