Artifact Analysis: NTFS Master File Table (MFT)

Note

Executive Summary: The Master File Table (MFT) is the central database and the heart of the New Technology File System (NTFS). Stored as a hidden system file named $MFT, it contains at least one record for every single file and directory on a volume. For DFIR analysts, parsing the MFT is the foundational step for building an absolute “Source of Truth” timeline, tracking deleted payloads, and uncovering advanced anti-forensic techniques like Timestomping.

1. Architectural Overview: The Disk Ledger

Without the MFT, the operating system would not know where files are physically located on the hard drive, what their names are, or what permissions they possess. Even the $MFT file itself has an entry (it is always Record 0).

Every file and directory is represented by an MFT Record, which is strictly 1024 bytes in size. This record is composed of a series of Attributes that describe the file.

Tip

Resident vs. Non-Resident Data: If a file is extremely small (typically less than ~700 bytes), NTFS optimizes storage by writing the actual file content directly inside the MFT record’s $DATA attribute. This is called Resident Data. If the file is larger, the $DATA attribute simply holds pointers (cluster runs) to the physical sectors on the disk where the data resides (Non-Resident Data).

2. Critical MFT Attributes for DFIR

While an MFT record contains many attributes, analysts primarily focus on the following to reconstruct threat actor activity.

A. $STANDARD_INFORMATION ($SI)

• Description: Contains core metadata, including file ownership, security IDs, and the primary set of timestamps. These are the timestamps visible when a user views file properties in Windows Explorer.
• The Vulnerability: Because these timestamps can be easily altered by user-mode APIs (like SetFileTime), attackers frequently manipulate them (a technique called Timestomping) to blend their malware in with legitimate, years-old system files.

B. $FILE_NAME ($FN)

• Description: Contains the name of the file, a reference to its parent directory (crucial for rebuilding the folder tree), and crucially, a second, independent set of timestamps.
• The Forensic Advantage: Unlike $SI, the $FN timestamps can only be modified directly by the Windows kernel (typically when a file is created, moved, or renamed). They cannot be easily altered using standard API calls. Therefore, $FN represents the “true” temporal history of the file.

C. $DATA

• Description: Contains the file’s content or pointers to it. As discussed in our Alternate Data Streams (ADS) analysis, a single MFT record can contain multiple named $DATA attributes, which is how attackers hide payloads within legitimate files.

3. MACB Timestamps Explained

Both $SI and $FN attributes record four specific timestamps, universally referred to as MACB:

• M (Modified): The last time the content ($DATA) of the file was altered.
• A (Accessed): The last time the file was opened or read. (Note: Often disabled on modern Windows systems to improve SSD performance, rendering it less reliable).
• C (MFT Changed): The last time the metadata of the file (e.g., permissions, name, moving to a new folder) was altered in the MFT.
• B (Birth / Created): The exact time the file was initially created on the volume.

4. DFIR Investigation Scenarios

Parsing the MFT is the backbone of endpoint “Dead-Disk” forensics.

1. Detecting Timestomping (Anti-Forensics)

Advanced threat actors alter the $SI Birth and Modified timestamps of their dropped payloads (e.g., backdoor.exe) to match legitimate system files like cmd.exe (often dating back to the OS installation in 2022). The Detection: The analyst compares the $SI timestamps against the $FN timestamps. If $FN indicates the file was created in 2026, but $SI claims 2022, it is a mathematical certainty that the file was timestomped.

2. Recovering Deleted Artifacts

When an attacker “deletes” a tool, Windows does not wipe the data. It simply marks the MFT record as “Unused” and unallocates the clusters. The MFT record itself—retaining the original filename, the exact $SI and $FN timestamps, and the parent directory—remains completely intact until the OS needs to reuse that specific 1024-byte block for a new file. Analysts can extract these deleted records to prove a payload existed and was executed (correlating with Prefetch).

5. Tooling and Threat Hunting

Extracting and parsing the $MFT requires raw disk access. DFIR teams rely on automated parsers to convert the binary database into timeline-ready CSV files.

MFTECmd (Eric Zimmerman)

parse_mft.cmd

:: Parse the raw $MFT file and export to a detailed CSV format
MFTECmd.exe -f "C:\Forensics\Export\$MFT" --csv "C:\Forensics\Results" --csvf parsed_mft.csv

Splunk (Hunting Timestomping)

hunt_timestomping.spl

# Assuming MFTECmd CSV output has been ingested into Splunk
# This query detects files where the $SI creation date is older than the $FN creation date
index=mft_parsed
| eval SI_Creation=strptime(Created0x10, "%Y-%m-%d %H:%M:%S")
| eval FN_Creation=strptime(Created0x30, "%Y-%m-%d %H:%M:%S")
# Calculate the discrepancy in seconds (looking for severe manipulation)
| eval TimeDiff = FN_Creation - SI_Creation
| search TimeDiff > 86400  # More than 24 hours difference
| table FileName, ParentPath, Created0x10, Created0x30, TimeDiff
| sort - TimeDiff

---

References & Further Reading

• SANS Institute: Windows Forensic Analysis
• Eric Zimmerman’s Tools: MFTECmd GitHub Repository
• Related Artifact: Alternate Data Streams (ADS)
• Related Artifact: USN Journal ($UsnJrnl) Analysis