In this section
Detecting Timestomping Through MFT Analysis
Scenario
Fifteen executables in C:\ProgramData\Updates\. Twelve have $SI Created 6-12 months before $FN Created (temporal inversion). All fifteen have zero fractional seconds on $SI Created. The remaining three have $SI Created within 2 seconds of $FN Created but still show zero precision. Did the attacker timestomp all fifteen but only backdate twelve? The precision anomaly on all fifteen says yes.
Method 1: $SI versus $FN comparison
The primary detection method. Compare $SI Created (Created0x10) against $FN Created (Created0x30) in MFTECmd output.
Temporal inversion ($SI Created earlier than $FN Created) is the strongest indicator. This is physically impossible under normal NTFS operation because both timestamps are set from the same clock at creation. If $SI Created shows June 2025 and $FN Created shows March 2026, the file was created in March (per $FN) and $SI was backdated. Temporal inversion has an extremely low false positive rate. The only legitimate cause is the NTFS tunnel cache (Section 1.3), which produces inversions of seconds, not months.
Temporal gap (more than 5 seconds difference without explanation) is a moderate indicator. Under normal creation, both timestamps are set within the same API call and differ by at most a few hundred nanoseconds. A gap of seconds or minutes, particularly when $SI Created is later than $FN Created, may indicate an application set the $SI timestamp after creation (archive extraction, backup restore, file sync). A gap where $SI is earlier than $FN is a temporal inversion and classified as the strong indicator above.
In Timeline Explorer, perform this comparison by displaying Created0x10 and Created0x30 side by side, then sorting by the difference. For visual scanning, look for records where the two columns show different dates (months apart is obvious timestomping) or the same date but different times (subtler, requires closer inspection).
For large datasets with hundreds of thousands of entries, manual scanning is impractical. Export to a Python script that calculates the absolute difference between Created0x10 and Created0x30 for each record and flags entries exceeding a threshold (5 seconds is a reasonable starting point). The script should also flag entries where Created0x10 has zero fractional seconds (.0000000) while Created0x30 has non-zero fractional seconds, even when the dates are close. This catches the case where an attacker timestomped to approximately the correct date but the zero-precision artifact reveals the manipulation.
Magnet AXIOM 4.4 and later versions include an "NTFS Timestamp Mismatch" artifact that automates this comparison. The artifact flags entries where $SI Created is earlier than $FN Created (temporal inversion) and entries where the millisecond values are exactly zero. This automated detection reduces the manual burden but should be validated against MFTECmd output for critical findings.
Anti-Pattern
Skipping timestomping checks because "it's rare"
Timestomping is built into every major post-exploitation framework. Cobalt Strike's timestomp command is one line. PowerShell can do it natively: (Get-Item file).CreationTime = "06/15/2025". A five-minute check (compare $SI Created to $FN Created on key evidence files) prevents incorrect timelines in legal proceedings. The cost of checking is minutes. The cost of missing timestomping is incorrect findings.
Method 2: nanosecond precision analysis
NTFS timestamps have 100-nanosecond resolution. The probability of a naturally occurring timestamp ending in .0000000 is roughly 1 in 10 million. Timestomping tools that use SetFileTime() or PowerShell specify timestamps to the second (.0000000) or millisecond (.1230000) because the operator types "June 15, 2025 09:00:00" without fractional seconds.
The detection method: scan MFTECmd output for $SI timestamps with zero fractional seconds while surrounding files in the same directory have full nanosecond precision. A cluster of files with zero-fractional $SI Created timestamps in a directory where other files have natural precision is a moderate indicator.
False positives exist and you need to distinguish them from actual timestomping. Archive extraction tools (7-Zip, WinRAR, Windows built-in ZIP handler) set timestamps on extracted files to match the original at second precision — because the archive format stores timestamps at second resolution. These files appear in extraction directories, and the archive itself (which has its own MFT entry with natural-precision timestamps) provides context.
Backup restore operations may produce second-precision or millisecond-precision timestamps depending on the backup software. The corresponding backup logs document when the restore occurred. Cross-filesystem copies from FAT32 (which has 2-second timestamp resolution) produce even-second timestamps on the NTFS destination. The corresponding USB device history (USBSTOR registry, SetupAPI logs) confirms a FAT32 device was connected. Files restored from cloud storage (OneDrive, SharePoint) may also have modified precision depending on how the cloud service handles timestamps.
The contextual test: does the zero-precision file exist in a location consistent with archive extraction, backup restore, or cross-filesystem copy? If yes, it's likely a false positive. If the zero-precision file is an executable in ProgramData or a staging directory with no corresponding archive or backup, the finding warrants Method 1 and Method 3 analysis. Method 2 is a screening indicator, not a conclusive finding.
Method 3: USN Journal correlation
The most definitive method, requiring an intact USN Journal (covered in WF2). The principle: when SetFileTime() modifies $SI timestamps, NTFS records the modification as a USN Journal entry with reason code BASIC_INFO_CHANGE. The USN entry's timestamp is the real time, not the fake time written to $SI.
The detection workflow: for a file suspected of timestomping (from Method 1 or 2), search the USN Journal for entries matching the file's MFT reference with BASIC_INFO_CHANGE. If such an entry exists at a time different from the $SI timestamps, it confirms timestomping and provides the real time of the modification. The $SI attribute's USN field at offset +0x44 points directly to the most recent USN Journal entry, providing a shortcut to the relevant record.
Method 3 has the highest confidence but requires the USN Journal to be intact. The USN Journal ($UsnJrnl) is stored in the $Extend directory and can grow to several gigabytes before NTFS truncates it automatically. On a system with moderate file activity, the journal typically retains several weeks of entries. If the timestomping occurred within the journal's retention window, the evidence is available.
Sophisticated attackers who perform timestomping may also truncate the USN Journal (fsutil usn deletejournal /d C:) to destroy this evidence. USN Journal deletion is itself detectable through MFT analysis: the $UsnJrnl file's own MFT record shows the truncation in its $SI Entry Modified timestamp, and the $LogFile transaction log records the journal deletion operation. USN Journal deletion without a legitimate administrative reason is a significant anti-forensic indicator. When you find both timestomped files and a truncated USN Journal, the combination strongly indicates intentional evidence manipulation — document both findings together in your report.
The NTFS "triforce" methodology (documented by multiple DFIR practitioners) combines MFT analysis, $LogFile transaction records, and USN Journal entries to create a three-source verification of file operations. When all three sources agree, the finding is highly defensible. When one source has been tampered with (timestomped $SI, truncated USN Journal), the remaining sources reveal the tampering.
Systematic detection workflow
Investigation Principle
Report timestomping findings with classification and evidence. "CONFIRMED: loader.exe $SI Created (2025-06-15) predates $FN Created (2026-03-18) by 9 months (temporal inversion). $SI precision is zero fractional seconds. USN Journal entry at offset 0x0BC3A7 shows BASIC_INFO_CHANGE at 2026-03-18 02:14:55." This is a defensible finding. "The file appears to be timestomped" is not.