In this module

Detecting Timestomping Through MFT Analysis

14 hours · Module 1 · Free

Operational Objective

Timestomping is the most common anti-forensic technique encountered in investigations. The attacker modifies file timestamps to blend malicious files with legitimate ones, to disrupt timeline construction, or to move the apparent creation date outside the investigation window. Every major post-exploitation framework (Cobalt Strike, Metasploit, Sliver) includes timestomping capabilities. PowerShell's native `Set-ItemProperty` can modify timestamps without any additional tools. The technique is trivial to execute and effective against examiners who rely solely on $SI timestamps. But it is also detectable — through the $SI-versus-$FN comparison taught in WF1.3, through nanosecond precision analysis taught in WF1.2, and through USN Journal correlation taught in this subsection. This subsection consolidates the timestomping detection indicators into a structured detection methodology with specific KQL-equivalent queries for MFTECmd output, false positive assessment criteria, and documentation standards for reporting timestomping findings. By the end, you will have a repeatable detection method that identifies timestomped files with quantified confidence.

Deliverable: A structured timestomping detection methodology with three independent detection methods ($SI/$FN comparison, nanosecond precision analysis, USN Journal correlation), false positive assessment criteria for each method, a classification system (confirmed, probable, possible) for timestomping findings, and documentation standards for including timestomping evidence in forensic reports.

Estimated completion: 45 minutes

Figure WF1.9 — Three independent timestomping detection methods with confidence ratings and a classification system. Method 1 ($SI/$FN comparison) is the primary detection. Method 2 (nanosecond precision) is a screening indicator. Method 3 (USN correlation) provides definitive confirmation when the USN Journal is available.

Method 1 — $SI versus $FN timestamp comparison

This is the primary timestomping detection method, introduced in WF1.3 and formalized here as a systematic check. The method compares $SI Created (Created0x10) against $FN Created (Created0x30) in MFTECmd output and flags discrepancies.

Temporal inversion is the strongest indicator: $SI Created is earlier than $FN Created. This is physically impossible under normal NTFS operation — 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 2026 (per $FN) and the $SI timestamp was backdated to June 2025 after creation. Temporal inversion has an extremely low false positive rate — the only legitimate cause is the NTFS tunnel cache (WF1.3), which produces inversions of seconds, not months.

Temporal gap is a moderate indicator: $SI Created and $FN Created differ by more than 5 seconds without a corresponding explanation. Under normal file creation, both timestamps are set within the same API call and differ by at most a few hundred nanoseconds (the time between the kernel setting $FN timestamps and the I/O manager setting $SI timestamps). A gap of seconds or minutes — particularly when $SI Created is later than $FN Created — may indicate that the $SI timestamp was set after creation by an application (not necessarily malicious — archive extraction tools, backup restore, file sync tools do this). A gap where $SI Created is earlier than $FN Created is a temporal inversion and is classified as the strong indicator above.

In Timeline Explorer, this comparison is performed by sorting on Created0x10 and Created0x30 and visually scanning for records where the two columns differ significantly. For large datasets, export to a script (Python or PowerShell) that calculates the difference between the two columns and flags records exceeding a threshold.

Compliance Myth: "Timestomping is rare and only used by advanced threat actors — you don't need to check for it in routine investigations"

Timestomping is built into every major post-exploitation framework. Cobalt Strike's `timestomp` command is one line. Metasploit's `timestomp` module is standard in every pentester's toolkit. PowerShell can modify timestamps natively: `(Get-Item file.exe).CreationTime = "06/15/2025 09:00:00"` — no special tools required. In investigations involving skilled attackers (ransomware groups, APT, insider threat with technical knowledge), timestomping should be assumed and checked for systematically. Even in routine investigations, a five-minute check (compare $SI Created to $FN Created on key evidence files) can prevent incorrect timeline construction. The cost of checking is minutes. The cost of missing timestomping is incorrect findings in a legal proceeding.

Method 2 — nanosecond precision analysis

NTFS timestamps have 100-nanosecond resolution. Files created naturally by Windows have Created timestamps with non-zero fractional seconds — the probability of a naturally occurring timestamp ending in exactly .0000000 is roughly 1 in 10 million. Timestomping tools that set timestamps via SetFileTime() or PowerShell's property setter typically specify timestamps to the second (.0000000) or millisecond (.1230000) — because the human operator specifies "June 15, 2025 09:00:00" without fractional seconds.

The detection method: scan MFTECmd output for $SI timestamps that end in .0000000 (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 of timestomping.

False positives for this method: archive extraction tools (7-Zip, WinRAR) set timestamps on extracted files to match the original's timestamp, often at second precision. Backup restore operations may produce second-precision timestamps. File copies from non-NTFS filesystems (FAT32, which has 2-second precision, or ext4) produce lower-precision timestamps on the NTFS destination. These false positives are distinguishable from timestomping by context — archive-extracted files are in an extraction directory, backup-restored files have corresponding backup logs, and cross-filesystem copies have corresponding USB or network mount evidence.

Method 2 is a screening indicator, not a conclusive finding. Use it to identify candidates for deeper analysis with Methods 1 and 3.

Method 3 — USN Journal correlation

The most definitive timestomping detection method, requiring an intact USN Journal (covered in detail in WF2). The principle: when SetFileTime() modifies $SI timestamps, NTFS records the modification as a USN Journal entry with the reason code BASIC_INFO_CHANGE. The USN entry's timestamp is the real time of the modification — not the fake time that was written to $SI.

The detection workflow: for a file suspected of timestomping (identified by Method 1 or Method 2), search the USN Journal for entries matching the file's MFT reference number with reason code BASIC_INFO_CHANGE. If such an entry exists at a time different from the $SI timestamps, it confirms that the $SI timestamps were modified at the USN entry's time. The USN entry provides the real time of the timestomping operation.

Additionally, the $SI attribute's USN field (offset 0x44 in the $SI content, as described in WF1.2) contains the USN offset that links directly to the most recent USN Journal entry for this record. If the USN Journal entry at that offset shows BASIC_INFO_CHANGE without corresponding data changes, the last modification to the $SI attribute was a timestamp change — strong evidence of timestomping.

Method 3 has the highest confidence but requires the USN Journal to be intact. 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 (WF2) and is a significant anti-forensic indicator.

Decision point

You are examining 15 executables dropped by a ransomware actor in C:\ProgramData\Updates\. Method 1 analysis shows 12 of the 15 files have temporal inversions (SI Created 6-12 months before $FN Created). Method 2 shows all 15 files have zero fractional seconds on $SI Created. The remaining 3 files without temporal inversion have $SI Created within 2 seconds of $FN Created but still show zero fractional seconds.

For the 3 files without temporal inversion: their $SI Created timestamps are close to $FN Created (within 2 seconds) and both show the same date in March 2026 (during the intrusion window). However, the zero fractional seconds on $SI Created — while $FN Created has full nanosecond precision — suggests their $SI timestamps were also set by the timestomping tool, just set to approximately the correct time rather than backdated.

Your classification: (A) Classify only the 12 files with temporal inversions as timestomped. Classify the 3 without inversion as "not timestomped" since the dates are approximately correct. (B) Classify the 12 with temporal inversions as "confirmed timestomped." Classify the 3 without inversion as "probable timestomped" — the zero fractional seconds indicate the timestamps were set by a tool even though the chosen dates were close to the actual creation time. The attacker may have timestomped all 15 but only backdated 12.

The correct classification is B. The zero fractional seconds on all 15 files, combined with the confirmed timestomping on 12, strongly suggests the attacker ran a timestomping command on all 15 files. For 12 files, the chosen date was months in the past. For 3 files, the chosen date happened to be close to the real creation time — possibly the attacker used the current date for some files and a past date for others. The precision anomaly (zero fractional) on the 3 files is sufficient for "probable" classification when combined with the confirmed timestomping pattern on the other 12 files in the same directory.

Systematic detection workflow

Apply the three methods in order for every investigation:

Step 1 — Screen with Method 2. Scan the full MFTECmd output for $SI Created timestamps with zero fractional seconds. This is fast (a simple string filter) and identifies all timestomping candidates plus false positives from archive extraction and backup restore. Flag the candidates.

Step 2 — Confirm with Method 1. For each candidate from Step 1, compare $SI Created against $FN Created. Temporal inversions are confirmed timestomping. Large temporal gaps (more than 5 seconds) without explanation are probable timestomping. Small gaps with zero fractional seconds are possible timestomping.

Step 3 — Corroborate with Method 3 (if USN Journal available). For confirmed and probable findings, search the USN Journal for BASIC_INFO_CHANGE entries matching the file's MFT reference. USN entries at a time different from the $SI timestamps provide definitive confirmation and the real timestamp.

Step 4 — Classify and document. Assign each finding a classification: confirmed (Methods 1+3 positive), probable (Method 1 positive), possible (Method 2 positive only), or unlikely (no indicators). Document the classification, the evidence supporting it, and the real timestamp (if recoverable from $FN or USN Journal).

This workflow takes 15-30 minutes for a focused set of evidence files and should be performed routinely on all files central to your investigative findings. The classification system ensures you report timestomping findings with appropriate confidence rather than overstating or understating the evidence.

Try it: Timestomping detection on lab evidence

Using the lab evidence provided with this module (the INC-NE-2026-1022 ransomware scenario evidence set):

1. Load the MFTECmd output in Timeline Explorer. 2. Filter for files in the attacker's known staging directories (C:\ProgramData\Updates\, C:\Windows\Temp\, or any temporary directories identified in the scenario briefing). 3. Apply Method 2: examine the Created0x10 column for zero fractional seconds. Flag all candidates. 4. Apply Method 1: for each candidate, compare Created0x10 against Created0x30. Identify temporal inversions and temporal gaps. 5. Classify each flagged file: confirmed, probable, possible, or unlikely timestomping. 6. For confirmed/probable findings, determine the real creation time from $FN Created. 7. Write a summary: "N files in [directory] show [confirmed/probable] timestomping. $SI Created timestamps were set to [date range], but $FN Created timestamps show actual creation during [investigation window]. The attacker backdated the timestamps by [N months/days] to blend with [description of surrounding files]."

This exercise practices the complete timestomping detection workflow on realistic evidence.

Reporting timestomping findings

When including timestomping evidence in a forensic report, document five elements:

The detection method. Which of the three methods identified the timestomping and what specific indicator triggered the detection. "The file's $STANDARD_INFORMATION Created timestamp (2025-06-15T09:00:00.0000000) precedes its $FILE_NAME Created timestamp (2026-03-18T02:14:33.7654321) — a temporal inversion that indicates $SI timestamp modification."

The fake timestamp. The $SI timestamp that was set by the attacker. "The $SI Created timestamp shows June 15, 2025."

The real timestamp. The $FN timestamp and/or USN Journal timestamp that reveals the actual time. "The $FN Created timestamp shows March 18, 2026 at 02:14:33 UTC, which falls within the known intrusion window."

The classification. Confirmed, probable, or possible, with the evidence basis. "This finding is classified as confirmed timestomping based on temporal inversion ($SI Created 9 months before $FN Created) corroborated by USN Journal entry showing $SI modification at 02:15:01 on March 18, 2026."

The forensic significance. What the timestomping means for the investigation. "The attacker backdated 12 executables to June 2025 to avoid detection during timeline analysis. The real deployment time (March 18, 02:14–02:17) aligns with the lateral movement window identified from authentication events."

A file shows: $SI Created = 2026-03-18T02:14:33.0000000, $FN Created = 2026-03-18T02:14:33.7654321. There is no temporal inversion (both show the same date). The $SI Created has zero fractional seconds while $FN Created has full nanosecond precision. The difference is 0.7654321 seconds. How do you classify this?

Not timestomped — both timestamps show the same date, and a sub-second difference is within normal NTFS variation.

Possible timestomping. The zero fractional seconds on $SI Created is a precision anomaly (Method 2 positive) — natural NTFS timestamps have non-zero fractional seconds. The timestamps show the same date because the attacker (or a tool) set $SI Created to approximately the correct time but at second precision rather than nanosecond precision. This is not confirmed (no temporal inversion) and not probable without additional context, but it warrants investigation. Check the USN Journal for a BASIC_INFO_CHANGE entry, and check whether other files in the same directory show the same pattern. If this is an isolated file with this anomaly, it may be a false positive from a legitimate operation. If it's part of a pattern across multiple attacker-dropped files, it strengthens the case for timestomping.

Confirmed timestomping — the zero fractional seconds is definitive proof that SetFileTime() was used to modify the timestamp.

This is a normal copy operation artifact — the copy process set $SI Created to second precision while $FN Created retained the full precision of the original kernel timestamp.

Operational Artifact — Timestomping Detection Methodology and Reporting Template

This subsection provides the complete timestomping detection methodology: three independent methods applied in sequence (precision screening → $SI/$FN comparison → USN correlation), a classification system (confirmed/probable/possible/unlikely), and five required documentation elements for reporting findings. Apply this methodology to every file that forms a critical finding in your investigation. The cost is minutes per file; the consequence of missing timestomping is incorrect timelines, incorrect attribution, and findings that collapse under adversarial scrutiny. For court testimony, the ability to state "I applied a structured timestomping detection methodology to all key evidence files" demonstrates thoroughness that is difficult for opposing counsel to challenge.

You've built the foundations of artifact-level forensic analysis.

WF0 gave you the taxonomy, NTFS architecture, and the five-step methodology. WF1 took you inside the MFT at the binary level — every attribute, every timestamp, every edge case. From here, every artifact category gets the same raw-first treatment.

WF2–WF10: every major Windows artifact decoded at binary level — USN Journal, Prefetch, Amcache, Shimcache, ShellBags, LNK, Jump Lists, SRUM, Event Logs, and the Registry hives
INC-NE-2026-0915 (WF13) — Insider data exfiltration capstone. Work the complete investigation from USB history to OneDrive exfiltration evidence
INC-NE-2026-1022 (WF14) — Ransomware capstone. Three-host triage (FIN01 → IT03 → FS01) across the 72-hour attack chain
The lab pack — 25+ realistic evidence files in 10 formats, simulated KAPE triage pre-populated, both capstones deployable to your own VM
Anti-forensic detection methodology — defeat timestomping, log clearing, and Prefetch deletion with cross-artifact correlation

Unlock with Specialist — £25/mo See Full Syllabus

Cancel anytime

← Previous Next →