$MFT

Location & availability

NTFS volume metadata: $MFT

Record reuse, filesystem state and acquisition completeness affect recovery. A deleted entry can later belong to a different file.

Fields to examine

• $STANDARD_INFORMATION and $FILE_NAME attributes where present.
• Entry number, sequence, parent references and allocation state.
• Size, names and data-stream information supported by the parser.

What it can establish

• Support the presence and recorded metadata of a particular file record.
• Provide identifiers for reconstructing paths and correlating USN events.

What it cannot prove

• Prove execution or identify a person from file presence.
• Treat every timestamp as a user action or recoverable file content.

Use it in a screenshare

1. Acquire the MFT from the relevant volume and record the collection method.
2. Parse with MFTECmd, retaining entry and sequence identifiers. Compare timestamp sets without assuming every difference is tampering.
3. Resolve parent relationships and correlate a suspected rename or deletion with USN, Recycle Bin or other independent sources.

Worked example

A deleted MFT entry retains an executable name. It supports surviving metadata for that record, not necessarily recoverable bytes. Check sequence context before joining it to a recent USN event with the same entry number.

Cross-check the finding

• USN Journal / $UsnJrnl →Support recorded file/directory changes and a sequence within retained journal coverage.
• Directory indexes / $I30 →Support a directory/name association represented by a valid entry.
• Recycle Bin →Support a recorded move-to-Recycle-Bin operation and original path.

Sources

• Microsoft — Master File Table ↗
• MFTECmd — NTFS parser documentation ↗