In this section
MFT Timeline Construction
Scenario
You find 2,847 files with $SI Modified timestamps within a 4-minute window (02:14 to 02:18 on March 18). The timestamps have full nanosecond precision and increase monotonically with consistent ~85ms intervals. This is not human activity. This is an automated process (ransomware encryption or bulk copy tool) processing files sequentially. The nanosecond precision tells you the exact order files were processed and the speed of the operation.
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.
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.
Anti-Pattern
Dismissing timestamp anomalies because "Windows timestamps are unreliable"
Clock manipulation is theoretically possible but forensically detectable. Clock changes are logged (Event ID 4616). They create temporal anomalies across all artifacts, not just MFT timestamps. Domain-joined machines synchronize via NTP. Single-artifact analysis is vulnerable to clock manipulation. Multi-artifact correlation (MFT + Event Logs + Prefetch + USN Journal + authentication) is resilient.
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.
Investigation Principle
An MFT timeline alone answers "what happened to files and when." It does not answer "who did it" or "how." Correlating MFT timestamps with logon events (who was authenticated), Prefetch (what application ran), ShellBags (what folders were browsed), and SRUM (how much data was transferred) transforms a filesystem timeline into an investigation narrative.