Extracting and Parsing the MFT

Extraction methods

The MFT is a file — specifically, it is the file represented by MFT entry 0, stored at a location defined in the NTFS boot sector. Unlike regular files, the MFT cannot be copied through normal file operations while Windows is running because NTFS holds an exclusive lock on it. Extracting the MFT 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 command kape.exe --tsource C: --tdest D:\Evidence\%m --target $MFT collects the MFT from the C: volume. KAPE handles the raw read, hashing, and evidence logging automatically. The output is a file named $MFT in the target destination directory.

FTK Imager can extract the MFT from a live system or a forensic image. On a live system: File → Obtain Protected Files. From a forensic image: mount or open the image, navigate to the root of the NTFS volume, and 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, the cluster number of the $MFT file). To find the byte offset: multiply the starting cluster by the cluster size (also defined in the boot sector). Then read from that offset for the file's total size (defined in the MFT entry 0's $DATA attribute).

For forensic images (E01, raw/dd), mount the image read-only with Arsenal Image Mounter and then use KAPE or FTK Imager to extract the MFT from the mounted volume. The image's write-protection ensures the extraction doesn't modify the evidence.

Verifying the extraction

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

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.

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. This gives you the total number of MFT entries including reserved entries (0–23) and all user file entries.

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, the MFT is damaged at that location.

Known entry verification. Entry 0 should be the $MFT file itself. Entry 5 should be the root directory. 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 offset was wrong — the file may start from an incorrect position.

Parsing with MFTECmd

MFTECmd is Eric Zimmerman's MFT parser — the standard tool for converting raw MFT data into analysis-ready CSV output. The basic command:

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

This produces a CSV file with one row per MFT entry (more accurately, one row per $FILE_NAME attribute — entries with multiple $FN attributes produce multiple rows). The key output columns include:

EntryNumber — the MFT entry number (0-indexed). SequenceNumber — the current sequence number for the entry. InUse — whether the entry is currently allocated (True) or freed (False). ParentEntryNumber and ParentSequenceNumber — the parent directory reference from $FN. ParentPath — the resolved path to the parent directory. FileName — the filename from $FN. FnFlags — the $FN namespace (Win32, DOS, Win32+DOS, POSIX).

Created0x10 — $SI Created timestamp. LastModified0x10 — $SI Modified timestamp. LastRecordChange0x10 — $SI Entry Modified timestamp. LastAccess0x10 — $SI Accessed timestamp.

Created0x30 — $FN Created timestamp. LastModified0x30 — $FN Modified timestamp. LastRecordChange0x30 — $FN Entry Modified timestamp. LastAccess0x30 — $FN Accessed timestamp.

The "0x10" columns are $STANDARD_INFORMATION timestamps (the ones attackers modify when timestomping). The "0x30" columns are $FILE_NAME timestamps (the ones set by the NTFS kernel that attackers rarely modify). Both sets are essential for timestomping detection — always ensure your MFTECmd output includes both.

Additional useful flags: --de includes detailed information about deleted entries and slack data. --body generates a bodyfile for timeline creation with tools like mactime. --bdl C: sets the drive letter prefix for paths in bodyfile output.

Loading output in Timeline Explorer

Timeline Explorer is Eric Zimmerman's CSV analysis tool designed for forensic data. Load the MFTECmd output CSV: File → Open → select the CSV. Timeline Explorer handles large files (400,000+ rows) and provides filtering, sorting, conditional formatting, and column management.

Essential first actions when loading MFT output:

Sort by InUse to separate active and deleted entries. Deleted entries (InUse = False) are your recovery candidates. Active entries (InUse = True) represent the current filesystem state.

Add conditional formatting for timestamp comparisons. Highlight rows where Created0x10 (SI Created) differs significantly from Created0x30 (FN Created) — these are timestomping candidates. Timeline Explorer supports conditional formatting rules that can flag these discrepancies visually.

Filter by ParentPath to focus on directories of interest. In the insider threat scenario, filter for the suspect's profile directory, the staging directories, and the USB volume paths. In the ransomware scenario, filter for temp directories, ProgramData, and the directories where the ransomware was deployed.

Save your column layout. Timeline Explorer allows you to save column configurations. Create a layout that includes both $SI and $FN timestamps, the entry number, sequence number, InUse status, filename, parent path, file size, and flags. Save this layout for reuse across investigations.

When MFTECmd output differs from raw data

MFTECmd is highly accurate — across hundreds of thousands of MFT records, the parser correctly interprets the vast majority of entries. But edge cases exist, and recognizing them is the purpose of the raw-first methodology taught in this course.

Path resolution errors. When a parent directory's MFT entry has been reallocated (sequence number mismatch), MFTECmd may resolve the path to the current directory at that entry rather than the original directory. The resolved path is wrong, but there's no indication in the CSV that the resolution failed. Verify by checking that the ParentSequenceNumber in the output matches the current sequence number of the parent entry.

Timestamp precision. MFTECmd outputs timestamps in ISO 8601 format with full nanosecond precision. In rare cases, CSV viewers or Excel may truncate the fractional seconds when loading the CSV, losing the precision needed for timestomping detection. Always use Timeline Explorer (which preserves full precision) rather than Excel for timestamp analysis.

Resident data omission. MFTECmd's default CSV output does not include the content of resident $DATA attributes. The data exists in the raw MFT but is not exported as part of the CSV. To recover resident file content, use MFTECmd's --de mode or extract it manually from the raw MFT at the calculated offset.

ADS handling. MFTECmd reports Alternate Data Streams as separate rows with the same entry number. The ADS name appears in the output, but the ADS content (like Zone.Identifier data) may not be fully extracted in all output modes. For ADS content extraction, manual analysis of the raw MFT record may be necessary.