Every MFT record stores four timestamps in two separate attributes — $STANDARD_INFORMATION and $FILE_NAME. Both record the same four moments:
- Created — when the file was first written to the volume
- Modified — when the contents last changed
- Accessed — when the file was last read
- MFT-modified — when the record itself was last touched
That is eight numbers per record. They are not always in sync.
Why the two sets exist
$STANDARD_INFORMATION (SI) is updated by every routine file operation. $FILE_NAME (FN) was originally added for POSIX compatibility and is updated far less often — typically only on creation, rename, or when the file moves between directories.
In practice this means SI timestamps tick constantly while FN timestamps remain stable.
Timestomping leaves a fingerprint
Tools that alter timestamps usually call the Windows SetFileTime API. That writes to SI. It does not touch FN.
After timestomping, SI shows whatever the attacker chose — often backdated by years — while FN still reflects the real creation time, sometimes by a wide margin.
Two patterns to watch for during triage:
- SI created is older than FN created. Files cannot exist before they are named, so this is impossible naturally.
- SI and FN modified times differ by more than a few seconds for a file that has clearly not been renamed or moved.
Either is a strong indicator that someone has manipulated metadata.
Granularity tells you more
NTFS stores timestamps with 100-nanosecond resolution, but many timestomping tools round to the nearest second. A timestamp ending in .0000000 UTC is suspicious — most natural Windows activity leaves sub-second precision intact.