$MFT — Master File Table

Every file that has ever existed on an NTFS volume has an entry in the Master File Table — a 1024-byte record containing timestamps, filenames, permissions, and data run locations. When an investigator needs to prove a file existed, determine when it was created, or detect timestamp manipulation, the $MFT is the first artifact they reach for.

What Is $MFT?

The Master File Table ($MFT) is the core metadata structure of the NTFS filesystem. It is a special system file located at the root of every NTFS volume, and it contains exactly one record (1024 bytes in length) for every file and directory on that volume. The $MFT is to NTFS what an inode table is to ext4 — except that the $MFT stores far richer metadata and, critically, retains records for deleted files until the entry is reallocated to a new file.

Each MFT record is identified by a record number (also called the MFT entry number or inode number) and a sequence number that increments each time the entry is reused. Together, these form the MFT reference (a 48-bit record number + 16-bit sequence number), which uniquely identifies a file across the lifetime of the volume. The sequence number is the key to detecting entry reuse: if an investigator finds an MFT record with a sequence number of 5, the entry has been allocated, freed, and reallocated four previous times.

The $MFT itself is file record 0 in the table. Other reserved system files occupy the first 16 entries: $MFTMirr (entry 1, a partial backup of the first four MFT records), $LogFile (entry 2, the NTFS journal), $Volume (entry 3), $AttrDef (entry 4), the root directory . (entry 5), $Bitmap (entry 6), $Boot (entry 7), $BadClus (entry 8), $Secure (entry 9), $UpCase (entry 10), and $Extend (entry 11). User files and directories begin at entry 16 onward.

Location & Format

File Path & Properties

MFT Record Structure

Every MFT record begins with a fixed header containing the signature FILE (or BAAD if corrupt), the record number, sequence number, hard link count, first attribute offset, and flags indicating whether the entry is in use and whether it represents a directory. After the header, the record contains a sequence of attributes, each identified by a type code. The most forensically important attributes are:

Resident vs. Non-Resident Data

If a file is small enough (typically under ~700 bytes for a 1024-byte MFT record), its entire content is stored resident — directly within the $DATA attribute of the MFT record. The file has no cluster allocation on disk; its data lives entirely inside the MFT. This is forensically significant because resident files survive deletion more reliably than non-resident files: when an MFT entry is marked as free, the resident data remains in the record until the entry is reallocated and overwritten by a new file. Non-resident files store only data run mappings (cluster offset + length pairs) in the MFT record, with the actual content stored in clusters on the volume.

What It Reveals

The $MFT answers the following investigative questions that other artifacts either cannot answer or can only answer partially:

• Did a specific file ever exist on this volume? — Even after deletion, the MFT record persists until the entry is reallocated. The filename, path (via parent MFT reference), and timestamps remain recoverable.
• When was a file created, modified, accessed, and when was its MFT record last changed? — Both $SI and $FN provide full MACE timestamps with 100-nanosecond precision.
• Has timestamp manipulation occurred? — The $SI timestamps can be modified by user-mode tools (SetFileTime API, PowerShell Set-ItemProperty, timestomp). The $FN timestamps are maintained exclusively by the NTFS kernel driver and cannot be altered by user-mode code. A discrepancy where $SI timestamps are older than $FN timestamps is a strong indicator of timestomping.
• What was the file size? — Both the logical file size and the allocated size (on-disk rounded up to cluster boundaries) are recorded in the $FN attribute.
• In which directory was the file located? — The $FN attribute contains the parent directory’s MFT reference. By recursively resolving parent references, the full original path can be reconstructed even after deletion.
• Does the file have alternate data streams? — Additional $DATA attributes with named streams (e.g., :Zone.Identifier) appear as separate attributes within the same MFT record.
• Was the file moved or renamed? — Multiple $FN attributes may exist (one for the 8.3 short name, one for the long name). The $OBJECT_ID attribute tracks the file across renames via Distributed Link Tracking GUIDs.
• How many hard links does the file have? — The hard link count in the MFT header reveals additional directory entries pointing to the same file data.

Forensic Use Cases

1. File Existence Proof After Deletion

A subject deletes a malware dropper from C:\Users\admin\Downloads\payload.exe and empties the Recycle Bin. The file no longer appears in the filesystem. However, the MFT record for that file still exists with its entry marked as “not in use” — the filename, parent directory reference, timestamps, and file size are all intact. MFTECmd parses the record and recovers the full path, creation timestamp (2026-02-14 03:22:17 UTC), and size (847,360 bytes). The file existed. The timestamps prove when it arrived.

2. Timestomping Detection ($SI vs. $FN Mismatch)

An APT operator deploys a backdoor at C:\Windows\System32\svcnet.dll and timestomps it to match the creation date of legitimate system DLLs (2019-12-07). The $SI Created timestamp shows 2019-12-07 04:09:15, matching the surrounding files. But the $FN Created timestamp shows 2026-03-15 22:41:08 — the actual moment the file was written to disk. The six-year discrepancy is conclusive evidence of timestamp manipulation. The investigator can now scope the compromise to March 2026, not 2019.

3. Malware Staging Timeline

By parsing all MFT records in the C:\ProgramData and C:\Users\*\AppData directories, an investigator reconstructs the adversary’s staging sequence: a PowerShell script was created at 22:14, a DLL payload at 22:17, a persistence registry batch file at 22:19, and a cleanup script at 22:23. The four-file staging pattern, completed in nine minutes, reveals a scripted deployment rather than manual interaction.

4. Deleted File Recovery (Resident Data)

A configuration file for an exfiltration tool (rclone.conf, 312 bytes) was stored resident within the MFT record. After deletion, the MFT entry was not reallocated because 30,000 free entries were available. The entire file content — including remote storage credentials and bucket names — is recoverable directly from the MFT record without any file carving.

5. Parent Directory Reconstruction

A deleted executable has a parent MFT reference pointing to entry 48,291. That entry resolves to C:\Users\jdoe\AppData\Local\Temp. The full original path of the deleted file is now known: C:\Users\jdoe\AppData\Local\Temp\svchost.exe — a suspicious location for a file named after a system process. The parent directory chain provides context that transforms an ambiguous filename into a high-confidence indicator.

Acquisition Methods

Live System — Raw Copy Utilities

:: Using KAPE (Kroll Artifact Parser and Extractor)
kape.exe --tsource C: --tdest C:\Evidence\KAPE_Output --target MFT

:: Using RawCopy (bypasses NTFS file locks)
RawCopy.exe /FileNamePath:C:\$MFT /OutputPath:C:\Evidence\

:: Using Velociraptor (remote collection via VQL)
:: Artifact: Windows.KapeFiles.Targets with target "MFT"
:: Or: SELECT * FROM glob(globs="C:/$MFT")

:: Using FTK Imager (GUI — File > Obtain Protected Files)
:: Select C:\$MFT and export to evidence directory

Forensic Image — Direct Extraction

# Mount the forensic image (read-only)
mount -o ro,noexec,nodev,show_sys_files /dev/sdb1 /mnt/evidence

# Copy the $MFT (visible with show_sys_files mount option)
cp /mnt/evidence/\$MFT /analysis/mft/

# Alternative: extract with The Sleuth Kit
icat -o 0 /path/to/image.E01 0 > /analysis/mft/\$MFT

# The MFT is always inode 0 in NTFS
# -o 0 specifies the partition offset (adjust for multi-partition images)

Live System — Volume Shadow Copy

:: Create a shadow copy to access locked $MFT
vssadmin create shadow /for=C:

:: Link the shadow copy to an accessible path
mklink /d C:\ShadowMount \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\

:: Copy $MFT from the shadow
copy C:\ShadowMount\$MFT C:\Evidence\$MFT

:: Cleanup
rmdir C:\ShadowMount
vssadmin delete shadows /shadow={shadow-id} /quiet

Parsing Tools & Analysis

Parsing with MFTECmd

:: Parse $MFT to CSV
MFTECmd.exe -f C:\Evidence\$MFT --csv C:\Analysis\MFT_Output --csvf mft_parsed.csv

:: Output includes columns:
::   EntryNumber, SequenceNumber, InUse, ParentEntryNumber
::   FileName, Extension, FileSize
::   SI_Created, SI_Modified, SI_Accessed, SI_EntryModified
::   FN_Created, FN_Modified, FN_Accessed, FN_EntryModified
::   IsDirectory, HasAds, IsResident

:: Parse with body file output (for timeline analysis with log2timeline)
MFTECmd.exe -f C:\Evidence\$MFT --body C:\Analysis\MFT_Output --bodyf mft_body.txt

Parsing with The Sleuth Kit

# List all files (including deleted) in a directory
fls -r -p -d /path/to/image.E01 > /analysis/mft/deleted_files.txt

# -r = recursive, -p = full path, -d = deleted entries only

# Inspect a specific MFT record by entry number
istat /path/to/image.E01 48291

# Output shows: record header, attribute list, timestamps,
# data runs, filename, and parent directory reference

# Extract file content by inode number
icat /path/to/image.E01 48291 > /analysis/mft/recovered_file.exe

Timestomping Detection Script

# Detect $SI vs $FN timestamp mismatches (timestomping indicators)

import pandas as pd

df = pd.read_csv('/analysis/mft/mft_parsed.csv')

# Convert timestamp columns to datetime
for col in ['SI_Created', 'FN_Created', 'SI_Modified', 'FN_Modified']:
    df[col] = pd.to_datetime(df[col], errors='coerce')

# Flag entries where $SI Created is BEFORE $FN Created
# This should never happen naturally: $FN is set at file creation
stomped = df[df['SI_Created'] < df['FN_Created']].copy()

# Calculate the time delta
stomped['Delta'] = stomped['FN_Created'] - stomped['SI_Created']

# Filter for significant deltas (more than 1 hour)
stomped = stomped[stomped['Delta'] > pd.Timedelta(hours=1)]

print(f"Timestomped entries found: {len(stomped)}")
print(stomped[['FileName', 'SI_Created', 'FN_Created', 'Delta']].to_string())

Sample Output

Timestomped entries found: 3

FileName            SI_Created              FN_Created              Delta
svcnet.dll          2019-12-07 04:09:15     2026-03-15 22:41:08     2290 days 18:31:53
config.ini          2020-01-15 08:00:00     2026-03-15 22:41:12     2252 days 14:41:12
update.exe          2021-06-22 12:30:00     2026-03-15 22:42:01     1727 days 10:12:01

Retention & Persistence

Anti-Forensics Resilience

The $MFT is one of the most resilient artifacts on an NTFS volume. It is a system-level metafile that cannot be directly modified, deleted, or truncated by any standard tool. Even administrative-level access cannot alter the $MFT through the Windows API — modifications require either a raw disk write (blocked on mounted volumes since Windows Vista) or offline manipulation of an unmounted volume.

MITRE ATT&CK Detection Mapping

$MFT analysis provides evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & Case Studies

Corroborating Artifacts

Case Study

References

1. Eric Zimmerman, “MFTECmd — MFT Parser” — https://ericzimmerman.github.io/
2. flatcap, “Linux-NTFS Documentation” — https://flatcap.github.io/linux-ntfs/
3. SANS Institute, “NTFS Forensics — The Master File Table” — https://www.sans.org/blog/
4. 13Cubed, “MFT Analysis for DFIR” — https://www.13cubed.com/blog
5. Microsoft, “NTFS Technical Reference — Master File Table” — https://learn.microsoft.com
6. Brian Carrier, “File System Forensic Analysis” (Addison-Wesley, 2005)
7. David Kovar, “analyzeMFT — MFT Parser” — https://github.com/dkovar/analyzeMFT
8. ForensicArtifacts.com, “Windows NTFS Artifact Definitions” — https://github.com/ForensicArtifacts/artifacts