Deleted File Recovery from MFT

Identifying deleted entries in MFTECmd output

MFTECmd marks deleted MFT entries in its output with the InUse column set to False. These entries have the record flags set to 0x00 (deleted file) or 0x02 (deleted directory) in the MFT record header. Every deleted entry in MFTECmd output is a potential recovery candidate — the filename, timestamps, parent path, and file size are available for analysis.

To find deleted entries systematically: load the MFTECmd output in Timeline Explorer, filter the InUse column for False, and sort by Created0x10 or Created0x30 descending (most recently created files first). Recently created files that have been deleted are often the most forensically interesting — malware that was deployed and then cleaned up, documents that were copied and then deleted from the staging location, or temporary files created during an attack that the attacker removed.

The sequence number on each deleted entry indicates how many times the MFT entry has been recycled. A deleted entry with sequence number 2 (allocated once at seq 1, freed at seq 2) is in its first free state — the metadata belongs to the one and only file that ever used this entry. A deleted entry with sequence number 14 has been through multiple allocation cycles — the metadata belongs to the most recent file that used the entry (the one freed at sequence 13 or 14, depending on the increment pattern).

Not all deleted entries are complete. If the entry was partially overwritten by a subsequent allocation that was itself deleted, the attributes may be damaged. MFTECmd handles most partial records gracefully — it extracts whatever attributes are parseable and flags incomplete records. But for critical evidence, always verify the raw hex to confirm the attributes are intact.

Recovering resident file content

For deleted files under approximately 700 bytes, the $DATA attribute is resident — the file's content is stored directly in the MFT record. When the file is deleted, the MFT entry is marked as free but the content remains in the record's $DATA attribute. This content is recoverable until the MFT entry is reallocated.

The recovery process: identify the deleted entry in MFTECmd output (InUse = False, file size under 700 bytes). Calculate the MFT record offset (EntryNumber × 1,024). Open the raw MFT in HxD. Navigate to the calculated offset. Walk the attribute chain to locate the $DATA attribute (type 0x80). Verify the non-resident flag is 0 (resident). Read the content offset and content size from the attribute header. Extract the specified bytes from the content area.

The extracted bytes are the literal file content. For a text file, the bytes are the ASCII or UTF-8 text. For a batch script, the bytes are the script commands. For a small configuration file, the bytes are the configuration data. No decoding or reconstruction is needed — the content is complete and intact.

MFTECmd does not export resident data content in its standard CSV output. To recover resident content, manual extraction from the raw MFT is required. Future tool versions may add this capability, but as of 2026, resident data recovery is a manual hex analysis task — which is why the binary analysis skills taught in WF1.1 through WF1.4 are essential.

Small files that are commonly resident and forensically valuable when recovered from deleted entries: PowerShell scripts (.ps1), batch files (.bat, .cmd), small configuration files (.cfg, .ini, .conf), text notes (.txt), CSV data snippets, small XML files, and registry export snippets. In the ransomware scenario (INC-NE-2026-1022), the attacker may have used a small batch script to deploy the ransomware across multiple hosts — that script, deleted after execution, may be recoverable from its MFT record if the entry hasn't been reallocated.

Assessing non-resident data recoverability

For deleted files larger than approximately 700 bytes, the content is stored in clusters on disk. The MFT record's $DATA attribute contains the data run list that maps the file's logical extent to physical clusters. When the file is deleted, the clusters are freed in the volume bitmap but the data persists in the clusters until overwritten.

The recoverability assessment depends on three factors:

Volume bitmap status. Check whether the file's clusters are still marked as free (unallocated) in the volume bitmap ($Bitmap, MFT entry 6). If free, no new data has been written to those clusters since deletion. If allocated, a new file has been assigned those clusters and the original data is partially or fully overwritten.

Storage type. On HDDs, freed clusters retain their data indefinitely until overwritten. On SSDs with TRIM enabled (default on Windows 10/11), the SSD controller may zero freed blocks at any time after the TRIM command. The TRIM command is sent when NTFS frees the clusters — meaning the zeroing can begin within seconds of deletion. On SSDs, even if the volume bitmap shows the clusters as free, the actual flash blocks may already be zeroed.

Fragmentation. If the file's data runs show contiguous clusters, recovery is all-or-nothing — either the entire cluster range is intact or it's been overwritten. If the file is fragmented across multiple non-contiguous runs, each run must be assessed independently. Some runs may be intact while others are overwritten, producing partial recovery.

Recovery from the Recycle Bin

Before a file reaches the "permanently deleted" state, it typically passes through the Recycle Bin — the $Recycle.Bin directory. When a file is sent to the Recycle Bin (not Shift+Delete), NTFS renames it with a $R prefix followed by a random identifier, and creates a companion $I file containing the original path, original filename, deletion timestamp, and file size.

The $I file is a small binary structure: a header (version, file size, deletion time) followed by the original path in Unicode. RBCmd (Eric Zimmerman's Recycle Bin parser) extracts this information. The $R file is the actual file content, renamed but otherwise intact.

When the Recycle Bin is emptied, both the $I and $R files are deleted — but they follow the same deletion lifecycle as any other file. The MFT entries for the $I and $R files are freed, the clusters are released, and the data persists until overwritten. An examiner can recover the $I file from its freed MFT entry to determine the original filename and deletion timestamp, and potentially recover the $R file content from its freed clusters.

MFTECmd shows Recycle Bin files in its output — look for entries in the $Recycle.Bin parent path with $I and $R prefixed filenames. The $I files are small enough to be resident (under 700 bytes), making their content recoverable from the MFT even after the Recycle Bin has been emptied.

Documenting recovery methodology

When including recovered deleted files in a forensic report, document five elements to establish the recovery's reliability:

The source. Which MFT entry, at which sequence number, with which allocation status (free, allocated, partially overwritten). "MFT entry 38,271 (sequence 6, flags 0x00 — not in use)."

The recovery method. How the data was extracted — MFTECmd parsing for metadata, manual hex extraction for resident content, cluster extraction for non-resident content. "Resident file content (412 bytes) extracted manually from the MFT record at offset 0x254FC00, $DATA attribute content area."

The integrity verification. How you confirmed the recovered data is intact — attribute chain validation, content consistency check, hash of extracted content. "The $DATA attribute header is intact (type 0x80, length 0x1C8, non-resident flag 0, content size 412). The extracted 412 bytes parse as valid ASCII text consistent with a Windows batch script."

The confidence assessment. Your assessment of the recovery's reliability based on the entry's allocation status and the data's integrity. "Recovery confidence: HIGH. The MFT entry is in a free state with intact attributes. The resident data is complete and parses correctly. No evidence of partial overwriting."

The limitations. What the recovery does not provide. "This recovery provides the file's content, name, timestamps, and parent directory at the time of deletion. It does not establish which user created or deleted the file — that determination requires correlation with authentication events and Prefetch data."