Extracting and Parsing the MFT

Extraction methods

The MFT is a file — specifically, MFT entry 0, stored at the cluster offset defined in the NTFS boot sector. Unlike regular files, NTFS holds an exclusive lock on the MFT while Windows is running. Extracting it requires a tool that can read locked files or access the raw disk.

KAPE (Kroll Artifact Parser and Extractor) is the standard collection tool for DFIR triage. KAPE's $MFT target extracts the Master File Table using a raw disk read that bypasses the NTFS lock. The output is a file named $MFT in the target destination directory, with automatic hash generation and logging. KAPE can also collect the MFT alongside other critical artifacts ($LogFile, $UsnJrnl, registry hives, Prefetch) in a single collection pass using compound targets like !SANS_Triage.

FTK Imager can extract the MFT from a live system (File → Obtain Protected Files) or from a forensic image (mount or open the image, navigate to the volume root, export the $MFT file). FTK Imager generates a hash during export.

Raw disk access tools (dd on Linux, Arsenal Image Mounter for mounting images) can extract the MFT by reading the appropriate sectors. The MFT's starting cluster is defined in the NTFS boot sector at offset 0x30 (8 bytes, little-endian). Multiply the starting cluster by the cluster size (also in the boot sector) to get the byte offset. Then read from that offset for the file's total size, which you find in MFT entry 0's own $DATA attribute. This manual approach is rarely needed but is useful when automated tools fail to extract from damaged volumes.

For forensic images (E01, raw/dd), mount the image read-only with Arsenal Image Mounter, then use KAPE or FTK Imager to extract the MFT from the mounted volume. The image's write-protection ensures extraction doesn't modify the evidence. When working with live systems, extract to a removable drive — never to the evidence volume itself, as writing the output would modify the destination volume's MFT and USN Journal.

# KAPE extraction — standard method
.\kape.exe --tsource C: --tdest D:\Evidence\%m --target $MFT --vhdx MFT_Extract

Found file: C:\$MFT (387 MB)
SHA256: a4f2b1c3...8d91e427 (logged to KAPE\log\yyyy-MM-dd_collection.log)
Completed in 00:00:42

FTK Imager extracts via File → Obtain Protected Files on a live system, or by mounting a forensic image and exporting $MFT. Raw disk access (dd on Linux, Arsenal Image Mounter) reads from the MFT's starting cluster defined in the NTFS boot sector at offset 0x30.

Verifying the extraction

Before parsing, verify the extracted MFT is complete and uncorrupted.

Hash verification. Compare the SHA256 hash of the extracted file against the hash in the collection log (KAPE generates this automatically in its log file). If the hashes don't match, the file was modified after collection — re-extract from the source. Document the hash in your case notes immediately after extraction.

Size verification. The MFT file size must be an exact multiple of 1,024 (the MFT record size). If the file size is not a multiple of 1,024, the extraction was truncated or padded. Calculate the expected entry count: file size ÷ 1,024. A 400MB MFT contains approximately 400,000 entries. This gives you the total number of MFT entries including the reserved entries (0-23) and all user file entries (24+).

Signature spot-check. Open the raw MFT in HxD and navigate to offset 0x000 (entry 0). The first four bytes should be 46 49 4C 45 ("FILE"). Navigate to offset 0x400 (entry 1) — same signature. Navigate to the last entry (file_size - 1,024) — same signature. If any entry lacks the "FILE" signature or shows "BAAD", the MFT is damaged at that location. A "BAAD" signature means NTFS detected a fixup error during the last access to that record.

Known entry verification. Entry 0 should be the $MFT file itself. Entry 5 should be the root directory ("C:\"). Entry 2 should be $LogFile. Verify by reading the $FILE_NAME attribute in each entry and confirming the expected system filename. If these known entries contain unexpected data, the extraction started from the wrong offset on disk — the file may begin from an incorrect position and every entry number calculation will be wrong.

Parsing with MFTECmd

.\MFTECmd.exe -f D:\Evidence\C\$MFT --csv D:\Analysis --csvf mft_output.csv

MFTECmd version 1.4.0.0  Author: Eric Zimmerman
Processed D:\Evidence\C\$MFT in 14.2 seconds
File size: 405,798,912 bytes
Records: 412,847 (free: 28,441)                     ◄ 28K deleted file records available
Output: D:\Analysis\mft_output.csv (1.2 GB)

The output CSV has one row per $FILE_NAME attribute. Entries with multiple $FN attributes (Win32 + DOS short name) produce multiple rows. Key columns:

EntryNumber and SequenceNumber identify the record. InUse shows whether the entry is allocated (True) or freed (False). ParentEntryNumber, ParentSequenceNumber, and ParentPath provide the resolved directory path from $FN. FileName is the filename, and FnFlags indicates the namespace (Win32, DOS, Win32+DOS, POSIX).

The timestamp columns come in paired sets. Created0x10, LastModified0x10, LastRecordChange0x10, LastAccess0x10 are the $STANDARD_INFORMATION timestamps — the ones visible in Windows Explorer, modifiable through the Windows API, and the primary target for timestomping. Created0x30, LastModified0x30, LastRecordChange0x30, LastAccess0x30 are the $FILE_NAME timestamps — set by the NTFS kernel driver, not modifiable through standard APIs, and the forensic baseline for detecting timestamp manipulation.

Both sets are essential for timestomping detection. Always ensure your MFTECmd output includes all eight columns. The critical comparison is Created0x10 against Created0x30: if $SI Created is earlier than $FN Created, that temporal inversion cannot occur naturally and indicates timestomping.

Additional output columns worth monitoring: IsAds flags Alternate Data Stream entries. HasAds flags files that have ADS attached. ReparseTarget shows the target path for junction points and symbolic links. SecurityId is the security descriptor ID for ACL lookups. MFTECmd's --de flag adds detailed information about the data runs (cluster locations) and $I30 slack entries, which are essential for deleted file recovery and directory analysis.

Additional flags: --de includes detailed deleted entry and slack information. --body generates bodyfile format compatible with mactime and plaso for super timeline construction. --bdl C: sets the drive letter prefix in bodyfile paths so the MFT entries integrate properly with other artifact sources in the unified timeline.

Loading output in Timeline Explorer

Open the CSV in Timeline Explorer. A 1.2GB file may take 30-60 seconds to load. After loading, the immediate workflow:

Filter the ParentPath column to the target directories (the suspect's profile, the staging locations, temp directories). Filter the timestamp columns to the investigation timeframe. Sort by Created0x10 descending to see the most recently created files first. This narrows hundreds of thousands of entries to the records that matter for your investigation.

For timestomping screening, display Created0x10 and Created0x30 side by side. Records where Created0x10 differs from Created0x30 by more than a few seconds are timestomping candidates. Records where Created0x10 ends in .0000000 (zero fractional seconds) while Created0x30 has full nanosecond precision are programmatic timestamp setting candidates. Both patterns warrant deeper analysis with the three-method detection workflow from Section 1.9.