Master File Table Forensics: Recovering Evidence from NTFS MFT

Cybersecurity

The NTFS Master File Table is the authoritative record of every file that has ever existed on a volume. Orphaned records, slack space, and directory entry reconstruction make the MFT a forensic source that survives both deletion and log wiping.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 29, 2024 · 10 min read

The Master File Table ($MFT) is the core metadata database of every NTFS volume. Located at the beginning of the volume (its position is recorded in the volume boot record), it consists of 1024-byte records, each describing one file or directory. Every file on the volume, from the smallest text file to the largest database, has at least one MFT record. System files like $MFT itself, $Bitmap, $UsnJrnl, $LogFile, and $Boot also have MFT records. For forensic examiners, the $MFT is the single most comprehensive source of file system metadata on a Windows volume.

MFT Record Structure

Each 1024-byte MFT record begins with the FILE signature (or BAAD if corrupted), followed by a standard header containing the log file sequence number (LSN), the sequence number (incremented each time the record is reused for a new file), link count, first attribute offset, flags (in-use vs. deleted), and the actual record size. The body of the record consists of a sequence of attribute records, each with a type code, length, and resident or non-resident data.

• $STANDARD_INFORMATION (type 0x10): MACB timestamps, file attributes, security ID, and quota charges
• $FILE_NAME (type 0x30): filename, parent directory reference, MACB timestamps written by the kernel
• $DATA (type 0x80): for small files, file content stored resident in the MFT record itself (resident attribute)
• $DATA non-resident: for larger files, data runs (VCN to LCN mappings) describing cluster locations on disk
• $INDEX_ROOT and $INDEX_ALLOCATION (type 0x90 and 0xA0): B-tree index for directory entries
• $OBJECT_ID (type 0x40): distributed link tracking GUID for the file

Parsing with MFTECmd

MFTECmd.exe processes the raw $MFT file from a forensic image or a live volume accessed through a raw copy tool. Basic invocation: MFTECmd.exe -f '$MFT' --csv C:\output\ --csvf mft.csv. The output CSV contains one row per MFT entry with columns for EntryNumber, SequenceNumber, InUse, ParentEntryNumber, FileName, Extension, FileSize, Created0x10, Modified0x10, Changed0x10, LastAccess0x10, Created0x30, Modified0x30, Changed0x30, LastAccess0x30, and IsDirectory.

1. Acquire $MFT using KAPE (MFT target) or RawCopy.exe on a live system
2. Run MFTECmd.exe -f '$MFT' --csv C:\output\
3. In Timeline Explorer, filter InUse = False to see deleted file records
4. Sort Created0x30 (FN Born) by timestamp to reconstruct file creation order during the incident
5. Filter Extension for .ps1, .bat, .cmd, .tmp, .exe in non-standard directories
6. Check resident $DATA column for small files whose content was stored directly in the MFT record

Orphaned Records and Slack Space

When a file is deleted, its MFT record is marked not-in-use (the InUse flag is cleared) and may eventually be reused for a new file. Between deletion and reuse, the record is an orphaned entry: all its attributes are still intact and readable. The sequence number in the file reference (MFT entry number plus sequence number) increments on each reuse, allowing you to determine how many times the slot has been recycled. MFT record slack (the unused bytes at the end of a 1024-byte record after the last attribute) may contain residual data from a previous file that occupied the same record.

Directory Traversal Reconstruction

Every $FILE_NAME attribute contains a parent MFT entry number and sequence number. By recursively following parent references up the chain to the root directory (entry number 5), you can reconstruct the full path of any file, including deleted files whose directory entries are gone. This path reconstruction is what MFTECmd performs when it populates the ParentPath column. Orphaned files (where the parent entry has been reused and no longer points to a directory) appear with the tag OrphanedFile in MFTECmd output.

• MFT entry 0: $MFT (the MFT itself)
• MFT entry 1: $MFTMirr (partial MFT backup at volume midpoint)
• MFT entry 2: $LogFile (NTFS transaction journal)
• MFT entry 5: . (root directory, the terminus of all path reconstructions)
• MFT entries 0-15: reserved for NTFS system files
• MFT entries 16+: user files and directories

Correlating MFT with USN Journal

The MFT entry number is the join key between $MFT and $UsnJrnl analysis. When you find a deleted MFT record for a suspicious file, look up its entry number in the USN Journal to find the complete change history: create, rename, write, and delete events with precise timestamps. The combination gives you the file's complete life cycle from creation to deletion, with independent timestamps from two separate data sources.

The MFT does not lie and it does not forget quickly. Even after deletion, the metadata record persists until the slot is reused. On volumes with low churn, forensically significant MFT records from months before the incident may still be intact and parseable.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.