Extracting, Parsing, and Timeline Construction

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.

The copy indicator

The single most useful timestamp pattern in MFT forensics: when $SI Modified is earlier than $SI Created. Under normal file creation, all four $SI timestamps are set to the current time. When a file is copied, Windows creates a new MFT entry with a new $SI Created timestamp (the copy time) but preserves the source file's $SI Modified timestamp, so the user sees the "original" last-modified date in Explorer.

This creates a temporal inversion: Modified is earlier than Created, which cannot happen naturally. Filtering MFTECmd output for records where Created0x10 > LastModified0x10 identifies every copied file on the volume.

FileName                      Created0x10 ($SI)           LastModified0x10 ($SI)      Pattern
Manufacturing_Specs.xlsx      2026-03-12 16:48:22.345     2025-11-04 09:15:33.127     COPY (Mod < Created)
Design_Rev4_Final.dwg         2026-03-12 16:48:23.891     2025-08-22 14:33:07.456     COPY (Mod < Created)
Q3_Financial_Summary.pdf      2026-03-12 16:48:25.234     2026-01-15 11:22:44.789     COPY (Mod < Created)
notes_to_self.txt             2026-03-12 16:48:27.567     2026-03-12 16:48:27.567     Normal (Created = Modified)

The first three files have $SI Modified timestamps months before $SI Created. They were copied to this location on March 12 from sources last edited in November, August, and January. The fourth file was created in place (Created = Modified). In the insider threat scenario, filtering for Created0x10 > LastModified0x10 identifies every file copied to the workstation during the investigation window.

The copy indicator has limits you need to understand to avoid false conclusions. If the source file was created and never modified (Modified = Created on the source), the copy does not produce an inversion on the destination — both Created and Modified on the destination equal the copy time, indistinguishable from a newly created file. Also, some applications modify the Created timestamp after copy: certain backup tools, file managers like TeraCopy, and robocopy with the /COPY:DAT flag can set timestamps on the destination to match the source, which can either create or eliminate the copy indicator depending on the tool's behavior.

Same-volume moves do not produce a copy indicator because the MFT entry doesn't change — only the parent directory reference is updated. Cross-volume moves produce a copy indicator because they are internally a copy-then-delete operation. The copy indicator also does not appear on files extracted from archives (ZIP, 7z, RAR) when the archive tool preserves the original Modified timestamp, because the extraction creates a new file with Created = extraction time and Modified = original timestamp. This is a legitimate use of the same API that timestomping exploits. But for the majority of documents and data files, the copy indicator is reliable.

Building the timeline

An MFT-based filesystem timeline extracts timestamp events from MFTECmd output and orders them chronologically. The practical approach is not to timeline all eight timestamps for all records. Instead, focus on the timestamps that answer the investigation question.

For data exfiltration: Focus on $SI Created in the suspect's directories, USB mount points, and cloud sync folders. The Created timestamp on the destination shows when each file was copied. Filter to the investigation window and sort chronologically to reconstruct the copying sequence.

For malware deployment: Focus on $SI Created for executables, scripts, and DLLs in temp directories, ProgramData, and non-standard locations. Cross-reference with $FN Created to detect timestomping. The $FN timestamps provide the real deployment timeline when $SI has been manipulated.

For file modification: Focus on $SI Modified to identify when files were last edited. Correlate with Prefetch (which application ran at that time) and logon events (which user was authenticated).

For deletion analysis: Filter for InUse = False (freed entries). The $SI Entry Modified timestamp on a deleted record often reflects the deletion time because the deletion operation modifies the MFT record's metadata (clearing the in-use flag). However, this is not guaranteed — if the entry was subsequently partially overwritten by a reallocated file that was itself deleted, the Entry Modified timestamp may reflect the later reallocation. Correlate with USN Journal entries for precise deletion timestamps and with $I30 slack entries for directory-level confirmation.

For access dispute analysis: Focus on $SI Accessed timestamps on the disputed files. Remember the limitations: on Windows 10/11 with lazy access updates (the default), Accessed has hour-level granularity. Check the NtfsDisableLastAccessUpdate registry value to determine which behavior was in effect. On servers running Windows Server 2019+, the default may differ from workstations. Also check the directory's own $SI Accessed and Entry Modified timestamps — a directory whose metadata was updated during the disputed timeframe supports (but does not prove) that its contents were accessed.

Nanosecond precision for event sequencing

FILETIME's 100-nanosecond resolution enables sub-second event ordering. In MFTECmd output, timestamps display with seven decimal places: 2026-03-18T02:14:33.1234567. Each digit represents 100-nanosecond precision. Two files with Created timestamps of .1234567 and .1234890 were created 32.3 microseconds apart.

This precision is useful for reconstructing automated operations. A copy operation processing 50 files in 3 seconds produces Created timestamps with unique nanosecond values that reveal the exact copy order. A ransomware encrypting files produces monotonically increasing Modified timestamps showing the encryption progression: which directory was encrypted first, which was last, and the speed (files per second). An automated exfiltration tool produces a sequence of Created timestamps on the destination that reveals the copying order and throughput.

For timestomping detection, precision is diagnostic. Files with .0000000 fractional seconds surrounded by files with full nanosecond precision indicate programmatic timestamp setting rather than genuine file operations. The probability of a naturally occurring timestamp ending in exactly .0000000 is roughly 1 in 10 million.

Bodyfile and super timelines

MFTECmd's --body flag generates bodyfile format compatible with mactime and plaso/log2timeline. The bodyfile contains one entry per timestamp event per file (up to 8 events per MFT entry). Combined with bodyfiles from other artifact sources (Event Logs, Prefetch, registry hives), the super timeline correlates MFT events with authentication, execution, and application activity across a unified chronological view.

The bodyfile format encodes each timestamp event as a separate line: MD5 hash (typically 0 for MFT bodyfile), filename with full path, inode number (MFT entry), permissions, UID, GID, file size, and four timestamp fields (Accessed, Modified, Changed, Created) in Unix epoch format. Each file can produce up to eight lines (four $SI events + four $FN events), though in practice some events share the same timestamp and are collapsed.

The bodyfile is not meant to be read directly — it's an interchange format. Feed it to mactime (from The Sleuth Kit) for a chronological text timeline, or to plaso/log2timeline for a comprehensive super timeline that merges MFT events with Event Logs, Prefetch, registry, browser history, and dozens of other artifact sources. The super timeline is the unified investigation view that correlates filesystem activity with user authentication, application execution, and network activity. Super timeline construction is covered in detail in later modules.

When using --body, always set --bdl to the correct drive letter (e.g., --bdl C:) so the MFT file paths integrate correctly with paths from other artifact sources in the merged timeline. Without the drive letter prefix, MFT paths start with "./" while Event Log paths show "C:\" — making cross-artifact correlation harder.