deleted files leave a receipt in the ntfs mft

"i deleted it" is not the flex people think it is

somebody says they deleted the file. cool story. the drive disagrees. ntfs doesn't actually erase anything when you hit delete, it just flips a bit that says "this space is free now" and leaves the record sitting in the master file table until the system needs that spot for something else. that record still has the filename, the path, the size, and every timestamp. this post is about how to read that record on your own machine so you know exactly what your systems are keeping track of, whether that's for incident response, an audit, or just understanding why "i deleted it" doesn't mean what people think it means.

what the mft actually is

every ntfs volume has a master file table. think of it as the card catalog for every file and folder that has ever existed on that drive, including a lot of stuff that's technically "gone." each entry is a fixed size record with metadata: name, parent folder, size, permissions, and a set of timestamps. when you delete a file, ntfs marks the record as not in use and marks the clusters as free space. the record itself usually sticks around until the filesystem overwrites it with a new file. that's your receipt.

pulling the receipt with mftecmd

eric zimmerman's mftecmd is a free, well known forensic tool that parses the $MFT and dumps it into something readable. here's the basic pull:

MFTECmd.exe -f C:\$MFT --csv C:\out

breaking that down:

-f C:\$MFT points the tool at the actual mft file on the volume. yes, $MFT is a real file, it's just hidden and locked while the OS is running, which is why you usually run this from a boot disk, a mounted image, or against a copy pulled by a tool that can read locked system files.

--csv C:\out tells it to dump the parsed results as csv into that folder, one row per mft record. way easier to filter than raw hex.

once you've got the csv, you can dig through it in powershell:

Import-Csv C:\out\*.csv | ? { $_.FileName -like '*client_list*' }

this just filters every record down to ones matching a filename you care about. you'll get back rows even for files that were deleted, because remember, the record hangs around.

reading the fields that matter

two fields do most of the talking:

InUse : False means the record is marked deleted, but it's still fully intact in the mft. the file's gone from explorer, the record is not gone from the disk.

ParentPath : .\Users\j.doe\Desktop tells you exactly where the file lived, which is handy when someone claims a file "never existed" on their machine.

the interesting one is SI. ntfs actually stores two sets of timestamps for every file: one in $STANDARD_INFORMATION (SI) and one in $FILE_NAME (FN). windows exposes the SI timestamps to normal tools, which is why timestamp editing utilities only touch SI. the FN timestamps are much harder to change and usually get set once, at creation, by the filesystem itself. when SI

why this matters for defenders, not just investigators

if you're running incident response on your own environment, this is one of the fastest ways to catch anti-forensic behavior. an attacker (or a soon to be ex employee) who tries to cover tracks by deleting a file and faking its creation date leaves this exact pattern: a deleted record with mismatched SI and FN timestamps. you don't need to guess, you need to check the mft.

the takeaway

on your own systems, treat "i deleted it" as a hypothesis, not a fact, and go verify it. pull the $MFT with mftecmd, csv it, filter for the filename or path you're worried about, and check InUse and the SI