MFTExplorer Hands-on Labs

Choose the Interactive Lab for a guided investigation inside a simulated MFTExplorer interface. Use the Full Lab when you are ready to examine an authorised $MFT working copy and preserve a reviewable case result.

Interactive Lab

Full Lab

Isolated Windows VM · 60–90 min

MFTExplorer Full Lab

Authorised NTFS evidence required

Hands-on NTFS record investigation

Find it. Validate it. Explain it.

Trace a deleted training file through its MFT identity, allocation state, timestamps, and a separately parsed change-journal sequence without overstating what the evidence proves.

⏱ Setup and core exercise: 60–90 min◆ Guided beginner✓ Evidence required

Start the Full Lab

Outcome-led, not screenshot-led

Interface labels can differ between releases. Use the workflow, record identities, checkpoints, and expected results below. Record meaningful version differences rather than trying to reproduce the supplied screenshot pixel for pixel.

Use supplied or authorised evidence

Do not acquire or examine a device without authority. Retain the source image or acquisition, verify a working copy, and keep all notes and exports outside the evidence directory.

Before you begin

You need: an isolated Windows analysis VM, a recorded MFTExplorer release, a supplied or authorised $MFT, its manifest or known hash, a matching $UsnJrnl:$J when available, and separate folders for working copies, exports, and notes.

How to use this lab

Complete each milestone before moving on. If the working-copy hash, parsed root, record identity, or companion-source match is missing, stop and correct that boundary instead of filling the gap with an assumption.

Recommended first

Beginner Core Lab

Locate one defined filename, validate its record and parent references, inspect its state and timestamps, then corroborate one change with a companion source.

Expected time: 60–90 minutes.

Optional extension

Wider time-window review

After the core succeeds, review neighbouring records or a narrow time window and compare the GUI observation with a repeatable MFTECmd export.

Expected time: one additional 30–45 minute session.

1. Session 1Prepare and verify
2. Session 2Locate and inspect
3. Session 3Corroborate and report

Objective

You are supporting case SUSA-MFT-204. Triage notes identify a filename of interest, invoice-review.txt, on authorised workstation WIN11-LAB01. Determine whether the preserved NTFS metadata represents the file, record its reconstructed path and allocation state, evaluate its timestamp fields, and use an independent file-system source to clarify the change sequence. State what remains unknown.

The core lab is successful when another analyst can reproduce your search from the same verified working sources and reach the same bounded conclusion.

01

Activity 1: Establish the evidence boundary

1. Record the case identifier, question, authority, examiner, source host, volume, collection time, source time zone, and analysis time zone.
2. Inventory the supplied image or extracted NTFS system files. Do not rename the protected source files.
3. Verify the supplied manifest or calculate a cryptographic hash of the protected $MFT and any companion sources.
4. Create identified working copies in a separate case directory and verify that their hashes match the protected sources.
5. Record the MFTExplorer executable path, version, hash, download source, and workstation time.
6. Create separate working, exports, screenshots, and notes directories. Confirm none is inside the protected source directory.

Use a preparation record such as:

Case: SUSA-MFT-204
Source host / volume:
Protected source path and SHA-256:
Working-copy path and SHA-256:
Companion source and SHA-256:
MFTExplorer path / version / SHA-256:
Time-zone basis:

Milestone 1Evidence basis verifiedThe protected source and identified working copy match, the tool is recorded, and derived material has a separate destination.

Expected result You can identify exactly which volume and `$MFT` will be examined and demonstrate that the working copy matches the retained source.

02

Activity 2: Locate and inspect the record

1. Launch MFTExplorer and record the version displayed in the title bar.
2. Use File > Open to load the verified $MFT working copy.
3. Wait for parsing to finish. Confirm that the tree and record grid populate and note warnings or parse errors.
4. Search for invoice-review.txt. Record the exact term, filters, sort order, number of matches, and displayed time basis.
5. Review every match. For the case-relevant record, capture:
6. entry and sequence number;
7. parent entry and sequence number;
8. reconstructed full path and filename type;
9. in-use state, directory state, size, flags, and ADS indication;
10. $STANDARD_INFORMATION and $FILE_NAME timestamps with their exact labels; and
11. any possible-timestomp indicator as a lead, not a finding.
12. Inspect the Overview, Details, and raw-record context. Confirm that the displayed path is consistent with the stored parent references.
13. Preserve a screenshot or structured note that includes the selected row, record identity, relevant details, search state, source identity, and tool version.
14. Search for a deliberately different filename as a negative control and record the result.

Answer before continuing:

• Are there multiple matches or filename namespaces?
• Is the record marked in use, and what does that state actually establish?
• Do parent entry and sequence references support the displayed path?
• Which timestamps differ, and what normal behaviours could explain the difference?
• Does the metadata establish content recovery, execution, authorship, or intent?

Milestone 2Record observation is reproducibleThe search, selected record, source, state, parent references, and timestamp fields are preserved without converting a parser flag into a verdict.

Expected result A reviewer can locate the same record and distinguish observed fields from interpretations and unknowns.

03

Activity 3: Corroborate and report

1. Use the entry and sequence number to search the supplied $UsnJrnl:$J, or use another independent source if the journal is unavailable.
2. Record the parser, command or interface, source hash, relevant records, reason flags, USNs, timestamps, and parent references.
3. Compare the MFT record state with the journal sequence. Explain whether they agree, conflict, or cover different parts of the question.
4. If a possible timestamp anomaly was identified, test normal explanations such as copying, extraction, restoration, application behaviour, clock context, and attribute-update rules before escalating it.
5. Write a bounded case note that separates observation, interpretation, confidence, limitations, and the next source required.

Use this structure:

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

An acceptable conclusion may support that a named record existed at a reconstructed path and is now marked unused, with a matching journal sequence. It must not invent an actor, intent, execution, or recoverable content.

Milestone 3Finding documentedAnother analyst can trace every claim to a verified source, reproduce the search, and understand both the conclusion and its limits.

Expected result The final note connects the MFT observation with an independent record sequence and clearly states what remains unknown.

Extend the core with a repeatable export

Run MFTECmd against the same verified working copy, record the exact arguments and output location, and compare the selected GUI record with the structured row. Explain any displayed-field, time-format, path, or filtering differences without treating either tool as automatically correct.

Full Lab evidence checklist

This checklist applies to the evidence-based Full Lab. If you completed the Interactive Lab, retain its downloaded evidence summary instead.

• Core completion

  Required to demonstrate a traceable MFT examination and bounded finding.

  • Authority, case question, examiner, source host and volume, collection boundary, and time-zone basis.
  • Protected source and identified working-copy paths, byte sizes, SHA-256 values, and confirmed match.
  • MFTExplorer path, version, hash, workstation time, and recorded warnings.
  • Exact search term, filters, sort order, match count, selected row, and negative control.
  • Entry and sequence, parent references, reconstructed path, allocation state, size, flags, and selected attribute context.
  • Exact SI and FN timestamp labels, displayed values, time basis, and qualified anomaly assessment.
  • Independent source, matching identifiers, parser or method, relevant records, and preserved output.
  • Observation, interpretation, confidence, limitations, next evidence, and a conclusion free of unsupported actor or intent claims.

• Good analyst practice

  Supplementary records that strengthen reproducibility and peer review.

  • Case directory layout, derived-file hashes, screenshot names, and cleanup or retention record.
  • Optional MFTECmd command, complete output, and comparison with the GUI observation.

0 of 10 recorded Mark each item after saving the evidence.Reset

Troubleshooting

Symptom	First check
The application does not start	Confirm the complete net9 release directory, supported Windows version, architecture, and security-control events
The tree and grid remain empty	Recheck that the selected file is the verified $MFT, parsing finished, and the source is not empty or truncated
The filename has several matches	Compare full path, entry and sequence, parent references, namespace, state, and source context
The path cannot be reconstructed	Check parent record availability, sequence mismatch, record reuse, hard links, corruption, and parse warnings
Timestamps appear contradictory	Record the exact SI or FN field and time basis, then test normal file-system and application explanations
No journal match exists	Check journal coverage, rollover, record version, source pairing, parser settings, and alternate corroborating sources

Clean up

Close working files, hash retained screenshots, notes, and exports, protect the final case package, remove disposable copies according to lab policy, and restore the isolated analysis VM when appropriate. Do not delete the protected source or required case evidence.

PreviousCorrelate and report