MFT Timeline Construction

The copy indicator — $SI Modified before $SI Created

The single most useful timestamp pattern in MFT forensics is the copy indicator: when a file's $SI Modified timestamp is earlier than its $SI Created timestamp. Under normal file creation, all four $SI timestamps are set to the current time — Created and Modified are identical. When a file is subsequently edited, Modified updates to the edit time (later than Created). Modified is always equal to or later than Created for files created in place.

When a file is copied, Windows creates a new MFT entry on the destination with a new $SI Created timestamp (the time of the copy operation). But Windows preserves the source file's $SI Modified timestamp on the destination — so the user sees the "original" last-modified date in Explorer, not the copy date. This creates a temporal inversion: $SI Modified is earlier than $SI Created, which cannot happen naturally.

In the insider threat scenario (INC-NE-2026-0915), the departing engineer copied files from a network share to a local staging directory before transferring to USB. Every copied file has the copy indicator: $SI Modified reflects when the file was last edited on the network share (potentially months or years ago), and $SI Created reflects when the copy was made (during the investigation window). By filtering MFTECmd output for records where Created0x10 > LastModified0x10, the examiner identifies every file that was copied to the workstation — the complete list of exfiltration candidates.

The copy indicator has limits. If the source file was created and never modified (Modified = Created on the source), the copy does not produce a temporal inversion on the destination — both Created and Modified on the destination are the copy time, identical to a newly created file. Also, some applications modify the Created timestamp after copy (certain backup tools, file managers), which can mask the copy indicator. But for the majority of document and data files, the copy indicator is reliable and forensically powerful.

Building the timeline

An MFT-based filesystem timeline is constructed by extracting timestamp events from MFTECmd output and ordering them chronologically. Each MFT entry produces up to eight timestamp events (four $SI, four $FN), and each event represents a specific type of activity on the file.

The practical approach is not to timeline all eight timestamps for all files — that would produce millions of events on a typical volume. Instead, focus on the timestamps that answer the investigation question:

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

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

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

For deletion investigations: Use the MFTECmd output filtered for InUse = False (deleted entries). The $SI Entry Modified timestamp on a deleted record often reflects the deletion time (because the deletion operation updates the MFT record's metadata). Correlate with USN Journal entries (WF2) for exact deletion timestamps.

Nanosecond precision for event sequencing

FILETIME's 100-nanosecond resolution becomes forensically important when multiple events occur within the same second. A file copy operation that processes 50 files might complete in 3 seconds — the Created timestamps on the destination files span a 3-second window, and the nanosecond precision allows the examiner to determine the exact copy order.

In MFTECmd output, timestamps are displayed 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 — the first file was created before the second.

This precision is useful for reconstructing rapid automated operations. A ransomware encrypting files produces a sequence of $SI Modified timestamps (one per encrypted file) that shows the encryption progression — which directory was encrypted first, which was encrypted last, and the encryption speed (files per second). An automated exfiltration tool copying files produces a sequence of $SI Created timestamps on the destination that shows the copy order and speed.

The precision also matters for timestomping detection. As discussed in WF1.2, timestomping tools that set timestamps via SetFileTime() typically produce zero fractional seconds or round to milliseconds. A file with Created0x10 ending in .0000000 surrounded by files with full nanosecond precision is a candidate for timestamp manipulation.

Bodyfile output for super timelines

MFTECmd can produce bodyfile format output — a pipe-delimited text format compatible with the Sleuth Kit's mactime tool and with Plaso for super timeline creation. The bodyfile format outputs one line per timestamp event, with fields for: MD5 (blank for MFT-only output), filename, inode (MFT entry number), mode, UID, GID, size, accessed time, modified time, changed time (entry modified), and created time.

The command to generate bodyfile output:

MFTECmd.exe -f "$MFT" --body "D:\Analysis" --bodyf "mft_body.txt" --bdl C:

The --bdl C: flag sets the drive letter prefix so that paths in the bodyfile show C:\Users\... instead of \Users\.... The bodyfile can then be processed with mactime to produce a sorted timeline, or ingested into Plaso alongside other artifact sources for a comprehensive super timeline (covered in WF9).

For MFT-only analysis (before incorporating other artifact sources), the bodyfile-to-mactime workflow produces a chronological listing of all file creation, modification, access, and metadata change events across the entire volume — a complete filesystem activity history. This is the starting point for identifying time windows of interest, after which you focus on specific files and directories for detailed analysis.

Timeline limitations and corroboration

An MFT-only timeline has inherent limitations. The MFT records file creation, modification, and metadata changes — but it does not record which user performed the operation, which application was used, or what the intent was. The MFT does not record file reads that don't update the Accessed timestamp (which is most reads on Windows 10/11 with disabled last access updates). The MFT does not record failed operations (a user who tried to copy a file but was denied by permissions).

These gaps are filled by other artifact sources: USN Journal (WF2) provides a more complete record of file operations including renames and deletions with timestamps independent of the MFT. Prefetch (WF3) shows which applications were running during the timeline window. ShellBags and LNK files (WF4) show user interaction with files and folders. Event Logs (WF6) show authentication, process creation, and system events. The MFT timeline is the skeleton — other artifacts add the flesh.

For the MFT-only timeline to be forensically defensible, document its limitations explicitly in your report. State what the MFT timeline shows (file creation, modification, copy, deletion events) and what it does not show (user attribution, application used, read-only access). When your conclusions require information beyond what the MFT provides, cite the corroborating artifact source explicitly. "The MFT shows the file was created at 02:14:33. The Prefetch data shows the ransomware executable ran at 02:14:30. The Event Log shows the service was created at 02:14:28. These three independent sources corroborate that the ransomware deployment sequence began at approximately 02:14:28."