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 system clock at the moment of file 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.2), which produces inversions of seconds, not months. A temporal inversion of days or longer is definitive evidence of timestamp manipulation. When you find a temporal inversion, the magnitude tells you about the attacker's intent: a 9-month backdating to match system files indicates an attacker trying to blend malicious executables with legitimate operating system files.
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.
Reporting timestomping findings
When including timestomping evidence in a forensic report, document five elements for each finding.
The detection method. Which of the three methods identified the timestomping and what specific indicator triggered the detection. "The file's $SI Created timestamp (2025-06-15T09:00:00.0000000) precedes its $FN Created timestamp (2026-03-18T02:14:33.7654321) by 9 months and 3 days — a temporal inversion detected via Method 1."
The real timeline. What the forensic evidence establishes as the actual file creation time. "The $FN Created timestamp of 2026-03-18T02:14:33.7654321 is the kernel-set creation time. The USN Journal entry at 2026-03-18T02:15:01.2345678 with reason code BASIC_INFO_CHANGE records the moment the $SI timestamp was modified. The file was created at 02:14:33 and timestomped at 02:15:01."
The fake timeline. What the attacker intended the examiner to see. "The $SI Created timestamp was set to 2025-06-15T09:00:00.0000000, matching the creation dates of legitimate system files in the same directory. The zero nanosecond precision confirms the timestamp was set programmatically, not by a genuine file creation event."
The classification. Your confidence assessment using the four-tier system. "Classification: CONFIRMED. All three detection methods produced positive indicators. The temporal inversion (Method 1, 9-month discrepancy) is conclusive. The zero-nanosecond precision (Method 2) is corroborative. The USN BASIC_INFO_CHANGE entry (Method 3) provides the real time of the manipulation."
The scope. Whether the timestomping affects a single file or a group. "Of the 15 executables in C:\ProgramData\Updates\, 12 show temporal inversions with identical fake $SI Created dates (2025-06-15). The remaining 3 show zero-nanosecond precision without inversion. All 15 are classified as timestomped. The consistent fake date across 12 files indicates a scripted timestomping operation, consistent with a post-deployment cleanup step."
This five-element documentation structure gives your finding the specificity and defensibility required for court testimony and insurance claims. A finding documented with all five elements is difficult to challenge because each element independently supports the conclusion. A finding documented as "the file was timestomped" provides no verifiable detail and can be challenged on any dimension.
For each timestomped file, also document the real timeline alongside the fake timeline in your investigation's master timeline. The real timeline (from $FN Created and USN Journal) shows when the file was actually deployed. The fake timeline (from $SI Created) shows what the attacker wanted you to see. Presenting both in the report demonstrates the methodology, quantifies the deception, and provides the court with the accurate chronology it needs.
Applying the methodology to every investigation
Timestomping detection should be a standard step in every investigation, not a specialized technique reserved for APT cases. The four-step workflow (screen, confirm, verify, classify) adds approximately 15 minutes to a standard investigation when applied to the key evidence files. For the insider threat scenario (INC-NE-2026-0915), apply the workflow to every file Chen copied to the staging directory. For the ransomware scenario (INC-NE-2026-1022), apply it to every executable deployed during the intrusion window. For the access dispute (INC-NE-2026-1130), apply it to the disputed files if their timestamps are central to the timeline.
The cost of checking is minutes. The cost of missing timestomping is an incorrect timeline in a legal proceeding. An examiner who reports "the file was created on June 15, 2025" based on a timestomped $SI value, without checking $FN or the USN Journal, has produced a factually incorrect finding. If that finding is challenged in cross-examination with a defense expert who performed the $SI/$FN comparison, the examiner's credibility — and the entire report's credibility — is compromised.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.