$MFT (Master File Table)

The NTFS file system is fundamentally organized as a database, and the Master File Table is its index. The securitymatrixblogs NTFS forensics primer captures the central role: “The Master File Table (MFT) is the backbone of the NTFS filesystem and it reserves 12.5% of the drive. Think of it as a giant database that keeps track of every single file and directory on the volume.”¹

Everything is a file

NTFS treats everything as a file, including its own metadata structures. The $MFT is itself a file; its first record (record 0) describes the MFT, including how many records it currently has and where its non-resident data extents live on disk. This recursive design has practical consequences: tools that read the MFT have to read the $MFT’s own record first to know where to find the rest. The Volume Boot Record provides the bootstrap pointer that lets the operating system find $MFT initially.

The Volume Boot Record bootstrap

The deaddisk MFT analysis documentation describes the entry point: “The MFT exists as a special file designated $MFT, positioned as the first entry in NTFS metadata files. Its location is specified in the Volume Boot Record (VBR) at offset 0x30, ensuring the file system can locate its central registry even after significant disk damage.”² The VBR is the first sector of an NTFS partition; it contains the metadata necessary to bootstrap NTFS, including:

• OEM ID (“NTFS”) at offset 0x03
• Bytes per sector at offset 0x0B
• Sectors per cluster at offset 0x0D
• Total sectors in the volume at offset 0x28
• MFT cluster location at offset 0x30
• $MFTMirr cluster location at offset 0x38
• Clusters per MFT record at offset 0x40

From a recovery perspective, the VBR is critical: if the VBR is intact, finding the MFT is straightforward; if the VBR is damaged, recovery tools must search for the MFT signature (“FILE”) at known cluster boundaries.

The 12.5% MFT zone

NTFS reserves a substantial portion of every volume for MFT growth by default. The Omar Haggag NTFS forensics primer notes the specific allocation: 12.5% of the drive is reserved as an MFT zone, ensuring the MFT can grow without becoming severely fragmented as files are added. The reservation is not a hard limit; the MFT can grow beyond it if the volume becomes very full and other space is needed, and NTFS will allocate non-MFT data into the MFT zone if free space is otherwise unavailable. The 12.5% reservation is one reason “available space” reported by Windows differs from “free clusters”; some clusters are reserved but not yet used.

A row per file (and per directory)

Every file on the volume has at least one MFT record; every directory does too. Files with many attributes (large files with hundreds of fragmented extents, files with extensive Alternate Data Streams, files with many hard links) may need multiple linked records. The fundamental rule is consistent: nothing exists on an NTFS volume without an MFT record describing it. This makes the MFT the comprehensive inventory of the volume’s contents, both currently-existing files and (via deleted-but-not-overwritten records) historical artifacts of files that have been removed.

Each MFT record has a fixed structure that’s consistent across NTFS versions and across files. Understanding the structure is essential for both MFT parsing and forensic analysis.³

Record header

Each record begins with a header containing:

• “FILE” signature (4 bytes): identifies a valid MFT record. Damaged records often start with “BAAD” instead.
• Update sequence offset and array: protects against torn writes by storing values at sector boundaries that can be cross-checked.
• $LogFile sequence number (LSN): links the record to the most recent transaction.
• Sequence number: increments each time the record is reused for a new file; combined with the file reference number to form a unique file identifier.
• Hard link count: number of hard links pointing at this file.
• Attribute offset: where the attributes section begins inside the record.
• Flags: 0x01 = in use, 0x02 = directory, 0x04 = extension record.
• Real size and allocated size: how much of the record is used vs allocated.
• File reference of base record: for extension records, points to the primary record.

The fixed 1024-byte size

The Shakil MFT documentation captures the simplifying property: “Each MFT record is 1024 bytes, making the MFT very simple to parse.” The fixed size means the offset of any record can be calculated directly: record N lives at MFT offset N × 1024 bytes. Recovery tools exploit this regularity; even on damaged volumes where directory structure is gone, scanning the MFT region in 1024-byte increments and looking for the “FILE” signature can identify intact records.

Key attributes

Beyond the header, each record contains a sequence of attributes. The most important for both normal operation and forensic recovery:

Type ID	Name	Purpose
0x10	$STANDARD_INFORMATION	Timestamps (created, modified, accessed, MFT modified), DOS file attributes, security ID
0x20	$ATTRIBUTE_LIST	For large files, lists where additional attributes live
0x30	$FILE_NAME	Filename, parent directory reference, separate timestamps (often differ from SI)
0x40	$OBJECT_ID	Unique object identifier (used by Distributed Link Tracking)
0x50	$SECURITY_DESCRIPTOR	Access control list (now usually replaced by $Secure system file)
0x60	$VOLUME_NAME	The volume’s label (only on $Volume system file)
0x70	$VOLUME_INFORMATION	NTFS version, volume flags (only on $Volume)
0x80	$DATA	The file’s actual content (resident or non-resident)
0x90	$INDEX_ROOT	For directories, the root of the directory’s B-tree index
0xA0	$INDEX_ALLOCATION	For directories, the rest of the directory’s B-tree
0xB0	$BITMAP	Used in $MFT to track which records are in use

Resident vs non-resident attributes

Attributes can be stored in two ways. Resident attributes have their data inside the MFT record itself; this works for small attributes whose total size fits in the remaining space of the 1024-byte record. Non-resident attributes have their data stored in clusters elsewhere on the volume, with the MFT record holding only a list of cluster runs (start cluster + length pairs) pointing to the data. The $DATA attribute is resident for small files (up to roughly 700 bytes after other attributes are accounted for) and non-resident for larger files; this means very small files exist entirely within the MFT and can be recovered without consulting the rest of the volume.

MFT slack space

Most files don’t need the full 1024 bytes of their MFT record; the unused portion is “slack space” within the record. The Sygnia 2025 forensic research describes this as “a largely unexplored, hidden part of the NTFS file system, often overlooked by digital forensics software… However, it holds critical data for forensic investigations.”⁴ When MFT records are reused for new files, the new attributes typically don’t fully overwrite the previous record’s contents; remnants of the previous file’s metadata persist in the slack space until completely overwritten. The Sygnia research notes that mainstream tools like dfir_ntfs and MFTECmd don’t extract this content, leaving substantial forensic value unexplored.

The first 16 entries in every MFT (file numbers 0 through 15) are reserved for system files that manage the volume itself. Understanding these is essential for both NTFS internals work and recovery scenarios.⁵

The system file inventory

File #	Name	Purpose
0	$MFT	The Master File Table itself
1	$MFTMirr	Backup of first 4 MFT records
2	$LogFile	Transaction log for crash recovery
3	$Volume	Volume metadata (label, version, flags)
4	$AttrDef	Definitions of valid attribute types
5	$. (root)	Root directory of the volume
6	$Bitmap	Cluster allocation bitmap
7	$Boot	Boot sector and bootstrap loader
8	$BadClus	Tracking of bad clusters
9	$Secure	Centralized security descriptors
10	$UpCase	Uppercase mapping for case-insensitive comparison
11	$Extend	Directory containing additional system files
12-15	Reserved	For future use

$MFTMirr: redundancy for critical records

The TryHackMe NTFS analysis walkthrough captures the role of the MFT mirror: “As the name suggests, the MFT Mirror is a duplicate copy of the first few records of the Master File Table, designed to ensure redundancy. Its main purpose is to provide a backup copy to recover data in case the primary MFT becomes corrupted. It also ensures file system stability and reliability. It is typically located in a separate part of the disk.” $MFTMirr only mirrors the first four records; it doesn’t protect the entire MFT, but it does protect the most critical records (the MFT itself, the mirror, the log file, and the volume metadata) that are needed to begin recovery operations.

$LogFile: the NTFS journal

The DFIR-Notes documentation describes the journal: “The $LogFile is a transactional log that records changes to the NTFS volume. It ensures data consistency in the event of a system crash by replaying or rolling back transactions during recovery.” NTFS uses write-ahead logging: changes are recorded in $LogFile before being applied to the actual file system structures. If a crash occurs, NTFS can replay the log to apply uncommitted changes or roll back partial changes. For recovery work, $LogFile sometimes contains uncommitted writes that aren’t reflected in the MFT; specialized recovery tools can extract these for additional context.

$Extend folder: additional system files

The $Extend directory (file 11) holds additional system files beyond the original 16-entry block:

• $ObjId: distributed link tracking object IDs.
• $Quota: per-user disk quota information.
• $Reparse: reparse point tracking (used for symbolic links, mount points, etc.).
• $UsnJrnl: the USN change journal that records file system changes for consumption by applications and forensics tools.

The MFT is the central artifact of NTFS forensics and the cornerstone of NTFS recovery. Its design produces several recovery-favorable properties that experienced recovery engineers exploit routinely.⁶

Deleted file records persist

The ResearchGate MFT recovery research captures the critical forensic property: “NTFS, the most commonly used file system, keeps the files in the disk as a list in the MFT (Master File Table) file. Even if the file is deleted, the file record in this table will not be deleted.” When a file is deleted, NTFS:

1. Marks the MFT record’s flag as not in use (clears the 0x01 bit).
2. Removes the directory entry that pointed to the file.
3. Updates the cluster bitmap to mark the file’s clusters as available.

What NTFS doesn’t do: actually clear the MFT record’s contents or overwrite the file’s data. The record still contains the file’s name, timestamps, attributes, and either the data itself (resident files) or pointers to the clusters where it lived (non-resident files). Until that MFT record is reused for a new file or the data clusters are overwritten, the deleted file is fully recoverable.

Timeline reconstruction

The MFT preserves comprehensive timestamp information. Each $STANDARD_INFORMATION attribute has four timestamps (created, modified, accessed, MFT entry modified); each $FILE_NAME attribute has its own four timestamps. The deaddisk MFT analysis documentation describes the dual-timestamp value: “Dual Timestamp Analysis: The comparison of $STANDARD_INFORMATION and $FILE_NAME timestamps provides the most reliable method for detecting timestamp manipulation attempts.” Timestomping (anti-forensic timestamp modification) typically affects only the $STANDARD_INFORMATION timestamps, leaving $FILE_NAME timestamps intact; investigators compare the two to detect tampering.

The NTFS Triforce methodology

The deaddisk documentation describes a comprehensive analytical approach: “NTFS Triforce Methodology: Combining MFT analysis with $LogFile and $UsnJrnl examination creates unprecedented visibility into file system activity and change tracking.” The three artifacts complement each other:

• MFT: current state of every file and directory, plus deleted records that haven’t been reused.
• $LogFile: recent transactions, including changes that may not yet be reflected in the MFT.
• $UsnJrnl: longer-running history of file-level changes for the volume.

Combining all three produces a near-complete picture of file system activity that no single artifact provides alone.

Alternate Data Streams

NTFS supports Alternate Data Streams (ADS): multiple data streams stored in a single file. The Ali Sefer Windows forensics article notes the malicious-use angle: “Alternate Data Streams (ADS) is a feature in NTFS that allows files to have multiple data streams stored in a single file. Internet Explorer and other browsers use Alternate Data Streams to identify files downloaded from the internet (using the ADS Zone Identifier). Malware has also been found to hide their code in ADS.” Each ADS is stored as an additional named $DATA attribute in the file’s MFT record. From a recovery perspective, ADS recovery requires reading the MFT record completely; tools that only extract the primary $DATA attribute miss alternate streams entirely.

Volume Shadow Copies

Beyond the MFT itself, NTFS supports Volume Shadow Copies (VSC): point-in-time snapshots of the volume that preserve historical states. Each shadow copy contains references to MFT records and clusters that have changed since the snapshot was taken. Shadow copies sometimes preserve evidence that ransomware or other attackers tried to destroy; ransomware operators routinely delete shadow copies specifically because of their forensic and recovery value.

Damaged MFT recovery

When the MFT is damaged but not destroyed, recovery is still typically possible. The standard procedure:

1. Read the VBR to confirm volume parameters and MFT location.
2. If VBR is intact, read $MFT directly; if not, search for “FILE” signature at cluster boundaries.
3. If the primary $MFT is unreadable, use $MFTMirr to recover the first 4 records.
4. Use the recovered $MFT records to find $MFT data extents.
5. Iterate through MFT records, parsing each one independently; skip records with bad checksums or “BAAD” headers.
6. Cross-reference $LogFile to recover any uncommitted transactions.
7. Output recovered files based on parsed MFT records.

An ecosystem of tools handles MFT analysis and recovery, ranging from open-source command-line utilities to commercial forensic suites. Each has different strengths and use cases.

Open-source tools

• The Sleuth Kit (TSK): the foundational open-source NTFS analysis suite. The fls command lists files and Alternate Data Streams; istat shows MFT record details for a given file; icat extracts file content; mmls shows partition layout.
• MFTECmd: Eric Zimmerman’s MFT parser, widely used in DFIR. Outputs comprehensive timeline data in CSV or JSON formats.
• dfir_ntfs: Python NTFS parser focused on forensic use cases.
• analyzeMFT: Python tool that parses MFT and outputs Excel-compatible CSV.
• ntfsundelete: part of the ntfs-3g package; recovers deleted files using MFT records.
• TestDisk: partition recovery tool with NTFS-specific MFT understanding.

Commercial forensic suites

The DFIR-Notes documentation notes the major commercial tools: “X-Ways Forensics: Provides detailed NTFS analysis. AccessData FTK: Comprehensive file system investigation capabilities. EnCase: Offers robust NTFS parsing and artifact extraction.” These tools typically include comprehensive MFT analysis alongside other forensic capabilities (timeline analysis, registry parsing, hash matching, etc.). Commercial suites are standard in legal and corporate forensic work; their MFT capabilities are mature but the workflow integration with other artifacts is what justifies their cost.

Consumer recovery software

Most consumer NTFS recovery software (Disk Drill, EaseUS Data Recovery, Recuva, etc.) reads the MFT to identify recoverable files. The typical workflow:

1. Read the volume’s MFT.
2. For each MFT record, check if it represents a file (vs directory or system file) and whether the in-use flag is set.
3. For deleted records (in-use flag clear), present the file to the user as recoverable.
4. For files marked for recovery, read the cluster runs from the $DATA attribute.
5. Read the actual data from those clusters and write to the recovery destination.
6. Verify the recovered file’s checksum or use file signature to detect corruption.

When MFT is unrecoverable

Some failure scenarios destroy the MFT beyond recovery: severe physical damage to the platter region holding the MFT, ransomware encryption that overwrites the MFT, or accidental quick-format that may overwrite the MFT-zone start. In these cases, recovery falls back to file carving: scanning the entire volume looking for file signatures (header byte patterns) that identify file types regardless of file system metadata. Carving recovers file content but loses original filenames, timestamps, and directory structure; it’s substantially less useful than MFT-based recovery but provides a fallback when the MFT itself is gone.