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.

The key question for each deleted entry: is the record waiting to be reused (freed but intact), or has it already been partially consumed by a subsequent allocation? The used size field (offset 0x18 in the record header) provides a clue. If the used size is consistent with the attribute chain (header + $SI + $FN + $DATA = expected total), the record is intact. If the used size is inconsistent or the attribute chain is broken (an attribute length points past the end of the record), the record has been partially overwritten. Document this assessment for every recovered entry that will appear in your findings.

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. To test, extract the cluster range and examine the content. If the bytes are all zeros (or a repeating pattern the SSD controller uses for erased blocks), the data is unrecoverable from the disk.

When non-resident data is unrecoverable from disk (SSD TRIM, cluster overwritten), check for alternative sources. Volume Shadow Copies (VSS) are point-in-time snapshots created by Windows for System Restore and backup. If a VSS snapshot was taken while the deleted file existed, the file's content may be recoverable from the snapshot even though the live disk clusters are gone. Use vssadmin list shadows or Arsenal Image Mounter to access VSS snapshots from a forensic image.

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. For text-based files (logs, scripts, CSVs), partial fragments may be interpretable. For encrypted containers or compressed archives, partial data is unusable because the format requires the complete file to decrypt or decompress.

Recovery from the Recycle Bin

Before a file reaches the "permanently deleted" state, it typically passes through the Recycle Bin — the $Recycle.Bin directory in each volume's root. 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 with version (8 bytes), file size (8 bytes), deletion time as FILETIME (8 bytes), followed by the original path in Unicode. RBCmd (Eric Zimmerman's Recycle Bin parser) extracts this information automatically. The $R file is the actual file content, renamed but otherwise intact. The $R filename is random, so you cannot determine the original filename from the $R file alone — you need the corresponding $I file.

When the Recycle Bin is emptied, both the $I and $R files are deleted. They follow the same deletion lifecycle as any other file: MFT entries are freed, clusters are released, data persists until overwritten. An examiner can recover the $I file from its freed MFT entry to determine the original filename and deletion timestamp. The $I files are small enough to be resident (typically under 200 bytes), making their content recoverable from the MFT even after the Recycle Bin has been emptied and even on SSDs where cluster content is gone.

Each user has their own Recycle Bin directory: $Recycle.Bin\{SID}\. The SID (Security Identifier) identifies which user account deleted the file. This means the Recycle Bin provides attribution that the MFT entry itself does not — the SID in the Recycle Bin path tells you which user account performed the deletion. Correlate the SID with the SAM or domain directory to identify the user.

MFTECmd shows Recycle Bin files in its output. Look for entries in the $Recycle.Bin parent path with $I and $R prefixed filenames. Filter for InUse = False to find emptied Recycle Bin entries. The $I file timestamps reveal when the file was sent to the Recycle Bin, and the content (when recovered) reveals the original path and filename.

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. SHA256 of extracted content: [hash]." For non-resident recoveries, document the cluster range integrity: "Clusters 50,000-50,127 all contain non-zero data consistent with a PE executable. Volume bitmap confirms clusters are unallocated. No TRIM zeroing detected."

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."

InUse  Entry   Seq  FileName                 ParentPath                   Size      Resident
False  48271   7    svchost_update.exe       .\Windows\Temp               284,672   Non-res   ◄ Attacker tool, deleted
False  48272   3    config.log               .\Windows\Temp               412       Resident  ◄ Content in MFT record!
False  48273   5    debug_output.txt         .\Windows\Temp               89        Resident  ◄ Content in MFT record!
True   48274   2    notepad.exe              .\Windows\System32           290,816   Non-res