Correlate and Report MFT Findings

Corroborate the record

MFTExplorer examines the $MFT; it does not turn that one artefact into a complete activity history. Use the selected entry and sequence plus path and time context to query a companion source with an appropriate parser.

Turn a record into a defensible finding

1. 1ObserveRecord identity, path, state, attributes, and exact timestamp fields.
2. 2ValidateCheck parent and sequence references plus detailed or raw context.
3. 3CorrelateUse USN, $LogFile, $I30, content, and independent host artefacts.
4. 4QualifyState what the record supports, its limits, and the next evidence needed.

Companion source	What it may add	Boundary to retain
$UsnJrnl:$J	Change-reason records and a partial sequence linked by record identity	Coverage may roll over; reasons do not identify intent
$LogFile	Transaction context for recent NTFS metadata operations	Parsing and coverage vary; it is not a user-action narrative
Directory $I30	Directory-entry history or slack context	A directory index is not proof of execution or authorship
File content or image	Content validation, recovery attempts, and wider volume context	Metadata does not guarantee complete recoverability
Host artefacts	User, application, execution, or access context	Correlate clocks, identifiers, and provenance before joining claims

Keep tool roles explicit

Use MFTExplorer for the graphical $MFT examination. If you parse $UsnJrnl:$J, $LogFile, or another source with MFTECmd or a different tool, record that parser and its exact version separately.

Write a bounded finding

Use a structure another analyst can review:

Case and question:
Sources, hashes, and tool versions:
Search state and selected MFT record:
Observed path, state, attributes, and timestamp fields:
Corroborating source, parser, and matching identifiers:
Supported sequence and confidence:
What the evidence does not prove:
Next evidence and preservation actions:

Example: In the verified $MFT working copy, record 28432-3 represents C:\Users\Avery\Downloads\invoice-review.txt and is marked not in use. Separately parsed USN records with the same entry and sequence support a rename followed by deletion. The available evidence does not establish an actor, intent, execution, or complete content recovery.

Check your interpretation

Analyst decisionMFTExplorer shows a matching filename in record 28432-3 and marks it not in use. What is the most defensible next step?

Report that the logged-on user deliberately deleted the fileRecord the entry and sequence, then correlate matching journal and case evidenceState that the complete file can definitely be recovered

Select the conclusion supported by the record.

Troubleshooting shortcuts

Symptom	First check
MFTExplorer does not start	Confirm the complete current net9 package, supported Windows version, architecture, and that security controls did not quarantine a dependency
The workspace remains empty	Confirm you opened an actual $MFT, parsing completed, and the working copy is not zero-length or truncated
A path looks wrong	Review entry and sequence numbers, parent references, record reuse, hard links, and alternate filename attributes
Times conflict	Confirm the exact attribute and field, time-zone display, source clock context, and whether copying or extraction affected the value
You need all rows or repeatable output	Use MFTECmd with recorded arguments and preserve the complete structured output

PreviousExamine MFT recordsNextMFTExplorer Hands-on Labs