Detecting Timestomping with the NTFS $LogFile

TL;DR. Timestomping tools usually rewrite $STANDARD_INFORMATION ($SI) through SetFileTime or NtSetInformationFile. The classic check — $SI created earlier than $FILE_NAME ($FN) created — only shows a mismatch. $LogFile shows the rewrite: an UpdateResidentValue on $SI with the old times in the undo bytes and the new ones in the redo bytes. Four tells are worth flagging: created time rewritten, a value moving backwards, whole-second values, $SI created before $FN created. All four have innocent explanations; confirm with the USN journal, execution artifacts and the surrounding records.

Timestomping (MITRE ATT&CK T1070.006) is cheap for the attacker and expensive for the analyst: a backdated binary drops out of every "files created during the incident" filter. $LogFile is one of the few artifacts that records the change as a change.

How timestamps get rewritten

NTFS keeps two sets of four timestamps per file (created, modified, MFT changed, accessed):

Most tools only touch $SI. Some go further and manipulate $FN indirectly, for example by setting $SI and then moving the file so that NTFS copies values into the new $FN; Palmbach and Breitinger analyse seven third-party tools and a PowerShell approach in Artifacts for Detecting Timestamp Manipulation in NTFS on Windows and Their Reliability (DFRWS EU 2020).

Timestamps are FILETIME values: 100-nanosecond intervals since 1601-01-01 UTC. That precision is why whole-second values stand out.

Why the $MFT alone is not enough

The $MFT shows the current state. From it you get the $SI/$FN comparison and sub-second checks, nothing more. You do not learn:

• what the value was before;
• whether it changed once or several times;
• whether $FN was also manipulated (then both sets agree and the classic check passes).

Cho's 2013 paper (Computers & Security 34) builds a detection method on exactly this: past timestamp values recovered from $LogFile, combined with the expected timestamp patterns of common file operations.

What the rewrite looks like in the log

A SetFileTime call on an existing file typically results in an UpdateResidentValue record whose target is the $SI attribute of that file's FILE record:

The attribute offset matters. Updates can be partial — dfir.ru notes an update to $SI can start at the M timestamp (How the $LogFile works?) — so a parser must map the bytes to the right slots. Normal activity (writing to a file) also produces these records: new modified / changed / accessed values, created untouched. The job is to separate those from rewrites.

Four tells, and what else causes them

The in-browser $LogFile parser flags a $SI change as possible timestomping when at least one of these holds, and lists which:

One more innocent source of old creation times: file system tunnelling. When a file is deleted or renamed and a file with the same name is created in the same folder shortly afterwards (15 seconds by default), Windows gives the new file the old file's creation time. Editors that save by writing a temporary file and renaming it trigger this routinely.

A combination is more telling than any single tell. A file in a user-writable folder whose creation time jumps from today to a round-second date years ago, with no archive extraction around it, deserves attention. A thousand files with backwards modified times created within one second of a 7z.exe Prefetch file are probably an extraction.

Worked example (synthetic sample)

The parser's sample log (synthetic, fictional host FIN-WKS-07) contains this sequence for MFT entry 322:

1. Create \Users\svc_backup\Downloads\tools\m64.exe — $FN created 2026-09-14 10:06:52.3551871.
2. Rename / move to \ProgramData\Intel\m64.exe — $FN changed 10:09:40.5560318.
3. $SI change — before: created 10:06:52.3551871, MFT changed 10:09:40.5560318; after: all four times 2019-03-19 07:14:22.0000000.

All four tells fire: created rewritten, values moved backwards, whole seconds, $SI created (2019) earlier than $FN created (2026). Note what the parser does with the event time: because the new values moved backwards, it does not use them as the time of the change. The event borrows the time of its neighbour (the move at 10:09:40) and is marked ≈. The true time of the rewrite would come from the USN journal's BASIC_INFO_CHANGE record.

The same pattern in the $MFT alone would show $SI = 2019 and $FN = 2026 — enough to suspect, not enough to show the original value or the order of events (moved first, backdated second).

Confirming a finding

1. Find the raw record. Open the event's log records, check it is an UpdateResidentValue on the right entry's $SI, and read the undo and redo bytes yourself.
2. Check the USN journal. A BASIC_INFO_CHANGE record for the same file reference dates the change (USN journal parser).
3. Look for the tool. Prefetch (Prefetch parser), Amcache (Amcache parser), PowerShell and Sysmon logs (EVTX parser) can show a timestomping utility or a SetFileTime-capable script running.
4. Check the neighbours. A lone rewrite on an executable in ProgramData is different from a batch of rewrites during an extraction.
5. Cross-check with a second parser if the finding goes in a report: the in-browser parser is validated on synthetic logs only so far. $LogFile parsers compared lists alternatives; NTFS Log Tracker includes its own timestamp-manipulation patterns.

Limits

• Retention. If the rewrite happened hours ago on a busy system volume, the record is probably gone (how far back the $LogFile goes).
• Missing context. If the file's creation fell outside the log, "before" values come only from the undo bytes, which may cover only part of $SI.
• $FN manipulation. When the attacker also moved the file to propagate times into $FN, the $SI/$FN tell disappears; the rewrite and the rename records remain the evidence.
• Heuristics, not verdicts. Every tell above has legitimate causes. Report the observation (old value, new value, record LSNs) and the corroboration, not the flag.

Frequently asked questions

Why is $LogFile useful for timestomping detection?

Because the change itself is logged. An UpdateResidentValue on $STANDARD_INFORMATION carries the new timestamps in its redo bytes and the previous ones in its undo bytes, so you can see the value before and after the rewrite instead of inferring it from a mismatch.

Is $SI created earlier than $FN created proof of timestomping?

No. It is a strong hint, but copies, archive extraction, installers and backup restores can also set $STANDARD_INFORMATION times into the past. Look for the rewrite in $LogFile, a matching BASIC_INFO_CHANGE in the USN journal, and execution evidence of a time-changing tool.

Further reading

• D. Palmbach, F. Breitinger, Artifacts for Detecting Timestamp Manipulation in NTFS on Windows and Their Reliability, FSI: Digital Investigation, 2020.
• G.-S. Cho, A computer forensic method for detecting timestamp forgery in NTFS, Computers & Security, 2013.
• MITRE ATT&CK, Indicator Removal: Timestomp (T1070.006).

Related articles

• NTFS $LogFile redo/undo operations explained
• A $LogFile investigation walkthrough (fictional case)
• $LogFile vs $UsnJrnl vs $MFT