The single most useful sentence I can offer a new examiner about NTFS: deletion is not erasure. It is a flag change and an index update. The file's MFT record stays put. The data clusters get marked free in $Bitmap. Nothing is overwritten until something else asks for that space.
People know this in the abstract. The mistake I keep watching them make is assuming the survival window is generous on every machine. It is not. On a busy file server the slot is reused inside minutes. On a workstation that nobody uses on weekends the deleted record can sit for a month. You have to know which kind of host you are looking at before you commit to a story about whether something is still recoverable.
What the record still contains
A deleted MFT record looks structurally identical to a live one. The IN_USE bit (bit 0 in the flags field at offset 0x16) is cleared. Everything else, unless the record has been claimed, is what NTFS last wrote:
$STANDARD_INFORMATION(attribute type0x10): all four timestamps in SI, the DOS flags, the security descriptor reference, the owner ID, the USN pointer. The timestamps survive the delete intact. Note the SI you see is whatever the file looked like at the moment of deletion, not whenever it was originally created (Windows updates SI constantly while the file is alive).$FILE_NAME(0x30): one per hard link, plus the 8.3 short name on volumes withdisable8dot3off. Parent directory reference is the MFT record number of the directory the file lived in. That reference holds even if the directory itself was later deleted, which is howflsand MFTECmd reconstruct paths into deleted directory hierarchies.$DATA(0x80): for resident files (under ~700 bytes of data), the bytes themselves sit inline in the record. For non-resident files, the runlist points at the clusters that were the file. Those clusters are no longer marked allocated, but they have not been zeroed.$ATTRIBUTE_LIST(0x20) when present, with references to any extension records the file used. Those extension records are themselves deleted but, until reclaimed, still parseable.
The sequence number is the thing that makes deleted-file analysis defensible. Each record carries a 16-bit sequence number that increments every time the slot is reused. A USN journal entry or a $LogFile reference that points to record 12345 sequence 3 keeps pointing at sequence 3 even after the slot is now sequence 4. That mismatch is what tells you the slot has been reused since.
When the slot actually goes away
Two events independently end recoverability:
The MFT record slot is reused. NTFS does not have a fixed allocation strategy here. In practice, when a new file needs a record, the driver looks at $MFT:$BITMAP for the lowest-numbered free record and uses it. Deleted records get reclaimed roughly in order. On a heavily-used volume that order moves fast. The MFT itself only grows; it never shrinks, so old deleted records far above the current high-water mark can survive for years.
The data clusters are overwritten. Independent of the record. The clusters were marked free in $Bitmap, so any allocator might claim them. On a freshly-deleted file, both events have to happen before recovery becomes hopeless. I have seen records survive but clusters be long gone (you recover the metadata and resident data only) and the inverse (record is reused but the clusters still hold the original bytes and can be carved).
There is no clean timer on either. "How long do deleted files last on NTFS" has the same honest answer as "how long does an open seat at the bar last": until somebody takes it.
What the journals add
The MFT shows you the present. The USN journal shows you the verb. A FILE_DELETE USN record names the file, the parent directory, and the timestamp of the delete. Even if the MFT slot has since been reused, the USN entry still preserves the old name and the original record/sequence pair. Pair the two and you get something like:
2026-04-12T13:08:11Z USN FILE_DELETE | CLOSE rec=44231 seq=7 path=\Users\bob\Documents\secrets.zip
2026-04-12T13:08:11Z MFT rec=44231 IN_USE=0 seq=7 (still readable, deleted)
2026-04-12T13:08:11Z MFT FN parent=12, name=secrets.zip
That is a reconstructible answer to "what did this file look like at deletion time" even if the file is otherwise gone. $LogFile adds transaction-level detail in the seconds either side: the delete is bracketed by a DeleteAttribute and DeallocateFileRecordSegment pair, and you can usually identify the surrounding operations.
If VSS was active and a snapshot exists from before the deletion, the snapshot's $MFT still shows IN_USE=1 for the same record/sequence, and the data clusters were preserved by copy-on-write. See Volume Shadow Copy and $MFT for the extraction details.
The cases people get wrong
Secure-delete tools. SDelete in its default mode overwrites the data clusters but does nothing to the MFT record. You get a deleted record with full $FILE_NAME, full $STANDARD_INFORMATION, and $DATA pointing at zeroed clusters. The name and the timestamps absolutely survive. This trips up users who expected SDelete to be more thorough than it is.
File deletion through hard links. Removing one hard link does not delete the file; the $FILE_NAME attribute for that link is removed and the hardlink count drops. The file itself is only deleted when the last link is removed. If you see a deleted MFT record with a hardlink_count of zero and no remaining $FILE_NAME, the file was truly deleted. If you see a record with a non-zero hard link count and a missing $FILE_NAME, the deletion was partial.
Files renamed before deletion. Some droppers rename their staging file to a benign name immediately before deleting, hoping the surviving $FILE_NAME reads as innocuous. The USN journal preserves the RENAME_OLD_NAME and RENAME_NEW_NAME pair, so you can recover the original name from there. The MFT alone shows only the final name.
The recycle bin is not a delete. Files sent to the recycle bin are renamed and moved into \$Recycle.Bin\<SID>\. The MFT record stays IN_USE=1 and the file is intact under a $R<ID> name. The $I<ID> companion records the original path. Emptying the bin then deletes normally.
Tools that read deleted records well
For triage I reach for one of:
- MFTECmd with
--de 1(drop entries) or just unfiltered output filtered downstream. Tags resident data and gives you the sequence number. omerbenamram/mft_dumpwith-o json. Sequence number, resident flag, full attribute list. Good for piping into a script that pulls records whereIN_USE=0andseqmatches a USN reference.- Sleuth Kit's
fls -m -rfor a bodyfile that includes deleted entries. Old-school, still works.icat -rrecovers the data for non-resident files whose clusters are intact. - analyzeMFT if you specifically want a pure-Python option and you do not care about speed.
The browser parser on this site filters to IN_USE=0 with one click and surfaces resident data inline. If the volume mattered, the file was small, and the slot has not been reused, you often have the bytes in front of you in the table.
What you still cannot answer from MFT alone
The MFT tells you a record exists and was deleted. It does not tell you who deleted it. For that you want Security 4663 (object access) if SACLs were configured, or Sysmon Event ID 23 (FileDelete) which logs the user and process. On most hosts neither is enabled. In that case you fall back to corroborating evidence: a Prefetch hit for a deletion tool, an Amcache entry for an unfamiliar binary running at the right time, recent file cache entries from the same window.
The MFT is the floor. Build the rest of the story on top of it.
Further reading
- Brian Carrier, File System Forensic Analysis. The chapters on NTFS deletion semantics are still definitive.
- Sleuth Kit's
flsdocumentation for the canonical bodyfile output that includes deleted entries. - Microsoft, Master File Table. The MS-level reference for what NTFS guarantees and does not guarantee.