Forensic engagements often pivot on a single question: was this file ever on this computer? Not "is it there now" (that is dir). The harder question: can we show it was there yesterday, last week, last year? For NTFS volumes the answer is usually yes, and $MFT is the strongest single source. Frequently the file's contents come back too.
This is the practitioner's view of what you can prove from MFT metadata alone, what corroboration the journals add, and the cases where confident claims fall apart in review.
What survives a delete
When a file is deleted on NTFS, the IN_USE bit in the record header is cleared and the parent directory's index entry is removed. The record itself stays, holding:
$FILE_NAMEwith the original filename and the parent directory's MFT record reference.- Eight timestamps (four in
$STANDARD_INFORMATION, four in$FILE_NAME) frozen at the moment of deletion. - Logical and physical sizes of the file's data.
- For small files (~700 bytes or less of
$DATA), the entire file contents stored inline in the record. See resident data. - For larger files, the runlist of clusters that held the data. Those clusters may or may not still hold the original bytes.
- The sequence number of the record, which proves you are looking at the file that lived in that slot at that time (not a later tenant).
A deleted MFT record with $FILE_NAME = secret-plan.docx, parent reference resolving to \Users\bob\Documents, and SI created 2024-11-03T14:02:11Z demonstrates a file by that name existed in that directory on that day. The record is the evidence, and the evidence is signed by NTFS itself in the sense that the filesystem driver wrote it.
What makes the evidence defensible
Three properties make MFT records hold up in a review where someone is trying to break your case:
- NTFS writes them itself, not the user. Records are not user-editable through normal Windows APIs. A defendant cannot credibly claim a single record was planted unless they argue the entire
$MFTwas forged, which is a high bar with the journal cross-checks below. - Eight timestamps cross-check. Manipulation usually shows. SI changed but FN unchanged is the textbook timestomping signature; see the four MFT timestamps. SI created predating FN created is impossible naturally.
$UsnJrnland$LogFilecorroborate. If$MFTsays the file was created at time T, the USN journal should recordFILE_CREATEat the same time. Disagreements are themselves evidence (of forgery or of parser error; either way, worth chasing).- VSS snapshots are independent. A snapshot from before the deletion holds an MFT copy where the file was
IN_USE=1. The snapshot was written by VSS at a known time. Two independent witnesses (live$MFT+ snapshot$MFT) showing the same file is much stronger than either one alone. See Volume Shadow Copy and$MFT.
That fourth point is worth dwelling on. In serious cases I always look for VSS snapshots. They convert a single observation into a series of observations, each at a different point in time, and they are written by an entirely different code path than the live MFT. Hard to forge both consistently.
What you cannot prove from $MFT alone
The MFT proves the file existed in a particular directory at a particular time, with the particular size and timestamps in the record. It does not prove:
- Who created or accessed it. That requires Security event logs (4663 with SACLs, Sysmon Event ID 11/15, or 4688 process creation with command line if the file was named on a command line).
- What program produced it. Prefetch, Amcache, and Shimcache help here. Sysmon Event ID 1 is the gold standard if it was enabled.
- What the file contained, for large files, unless you recover the data clusters. Resident files give you the bytes; non-resident files require the cluster runlist to still point at unallocated, unoverwritten space.
- Whether a user actually opened it. Jump lists, LNK files, and RecentFileCache are more useful here.
- Whether it was viewed by anyone other than the user who owned the directory. That needs ACL audit logs.
A complete answer usually fuses the MFT with surrounding artifacts. The MFT is the cornerstone because without it the other pieces have nothing to anchor to. A Prefetch hit for secret-tool.exe is interesting; the same hit paired with an MFT record showing secret-tool.exe was dropped into \Temp\ at the same minute by a process whose Sysmon Event ID 1 is in the timeline is conclusive.
A workflow that holds up in review
- Acquire
$MFT,$UsnJrnl:$J,$LogFile, all VSS snapshots. Hash everything (SHA-256). Document acquisition time. - Parse the MFT. Find the record for the file in question, alive or deleted. Pull the sequence number, parent reference, all eight timestamps, the resident
$DATAif any, and the cluster runlist if not. - Resolve the parent reference by following the parent's MFT record. Repeat until you hit record 5 (the root). The resulting chain is the directory path. Cross-check it against any path you have from logs or witness reports.
- Cross-reference with the USN journal. For the same record/sequence pair, list every USN entry.
FILE_CREATEgives you the original creation;FILE_DELETEgives you the deletion. The reasons in between are the file's history. - Compare against the VSS snapshot MFTs. Each snapshot's copy of the same record gives you a checkpoint. If three snapshots show the record
IN_USE=1with consistent timestamps and the live MFT showsIN_USE=0, you have four independent witnesses agreeing on the file's existence and one witness for its deletion. - Document the impossibilities you ruled out. SI/FN divergence checked. Sequence numbers consistent. Snapshot timestamps coherent. The defense's narrative has to explain all of these to undermine your conclusion.
The last step is what separates a finding from an argument. Listing what you checked and what you ruled out makes the chain of reasoning visible.
Edge cases that bite
Hard links. A file with multiple hard links lives across multiple $FILE_NAME attributes. Deleting one link only removes that name; the file remains. Confirm the deletion you are tracking actually corresponds to the file going away, not a single name being removed.
File renamed before deletion. Some droppers rename their staging file to a benign name immediately before deletion, hoping the surviving $FILE_NAME reads as innocuous. The USN journal preserves the RENAME_OLD_NAME / RENAME_NEW_NAME pair. Pull it.
Record slot reused. A deleted file's slot has been claimed by a new file. The current MFT record is the new file at sequence N; the journal references the old file at sequence N-1. Use the sequence number to disambiguate. References that point to a sequence other than the current one are pointing at a previous tenant.
File never existed and someone is lying. Less common, but worth knowing. Pure metadata forgery is hard to do consistently across MFT, USN, and VSS, but a determined operator with admin access has tools. Look for inconsistencies between artifacts that should agree.
Further reading
- Brian Carrier, File System Forensic Analysis. The chapter on NTFS forensics is the standard reference for what MFT evidence can support.
- SANS, FOR500: Windows Forensic Analysis. The course materials cover MFT-driven prior-existence proofs with worked cases.
- Harlan Carvey, Investigating Windows Systems. Practical case studies showing the MFT-plus-journal corroboration pattern.