In NTFS, what does a file whose $STANDARD_INFORMATION times predate its $FILE_NAME times suggest?
answer
- NTFS stores four times in two places
- one set is API-settable, one is not
- check the sub-second digits
- the entry-modified time resists the stomp
- a copy diverges innocently too
basics
~20 sBackdating. $STANDARD_INFORMATION times are settable through a documented Windows API; $FILE_NAME times are written by the NTFS driver on create, rename and move. $SI older than $FN points to timestomping, though a legitimate rename or restore can also diverge.
solid answer
~50 sEvery NTFS file carries two sets of four timestamps: `$STANDARD_INFORMATION` ($SI), which is what Explorer and most tools display and which any process with write access can set through `SetFileTime`, and `$FILE_NAME` ($FN), which the NTFS driver maintains during creation, rename and move and which no documented API sets directly. So the cheap way to backdate a dropped file touches $SI only, and the mismatch is the tell. Two tells usually travel with it: the $SI MFT-entry-modified time is not settable by that API, so it still shows the moment of the stomp, and several tools zero the sub-second digits where genuine system files carry 100-nanosecond noise. But state the conclusion in the right direction: divergence shows the displayed times cannot be trusted to date the file. It does not prove the file is malicious, and a copy, a rename or a restore from backup produces divergence innocently.
code
text · 12 linesFile: C:\Windows\System32\netsvcx.dll (MFT record 214553)
$STANDARD_INFORMATION
Created 2009-07-14 01:14:22.0000000
Modified 2009-07-14 01:14:22.0000000
Accessed 2009-07-14 01:14:22.0000000
MFT entry changed 2026-03-02 22:41:07.6431298
$FILE_NAME
Created 2026-03-02 22:41:07.6217645
Modified 2026-03-02 22:41:07.6217645
...go deeper
Know that NTFS keeps two timestamp sets, that $STANDARD_INFORMATION is the one tools display and the one an API can set, and that $FILE_NAME is written by the filesystem. Be able to say what a mismatch suggests without overclaiming.
Explain the mechanics: which API sets which fields, why the MFT-entry-modified time survives a stomp, and why sub-second precision matters. Be ready to name the innocent producers of divergence — copies, renames, restores, installers.
Show how you turn the divergence into a defensible statement: corroborate the true arrival time from evidence outside the file's metadata, and phrase the finding as what the artefact supports rather than as an accusation.
Own the standard your team applies before an anti-forensics claim goes into a report at all: how many independent artefacts, who argues the innocent case, and how the claim is worded so it survives challenge from someone hostile to it.
## Two timestamp sets, one file Every file on an NTFS volume has a record in the Master File Table (MFT), and that record carries its timestamps in at least two different attributes. `$STANDARD_INFORMATION` ($SI) holds four times — Modified, Accessed, Created and MFT-entry-modified, commonly abbreviated MACB. These are the values Windows Explorer shows, the values a directory listing prints, and the values nearly every tool reads. `$FILE_NAME` ($FN) holds a second set of the same four times, alongside the file's name and a reference to its parent directory. Nothing in ordinary use displays them. The forensic significance lies in who writes each set. The $SI Created, Modified and Accessed times are settable by any process with write access to the file through a documented Windows API (`SetFileTime`) — which is why backup and archiving tools can restore original times, and why an intruder can set them to anything at all. The $FN times are maintained by the NTFS driver itself during file creation, rename and move; there is no documented API that writes them directly. The cheap, widely tooled way to backdate a dropped file therefore touches $SI and leaves $FN alone. ## The divergence, and what it is worth A file whose $SI Created time reads 2009 while its $FN Created time reads three weeks ago is internally inconsistent: the volume's own name record says the entry was written three weeks ago. That inconsistency is the finding. It is evidence that the displayed times are not the times the file appeared. It is not evidence that the file is malicious, not proof of who set the times, and not by itself a reliable time of arrival. Two further tells usually accompany it: - **The $SI MFT-entry-modified time.** `SetFileTime` does not set it; NTFS updates it whenever the record changes — including the change that stomped the other three. A file with three times in 2009 and a fourth reading a moment inside the suspected intrusion window is loudly stomped. - **Sub-second precision.** NTFS timestamps have 100-nanosecond resolution. Several well-known timestomping tools write whole seconds, leaving a run of zeroes where every neighbouring system binary carries noise. A handful of files in a system directory that all share exactly `.0000000` is anomalous on its own. ## Ordinary explanations you must clear first This is where the finding is most often overstated, and where an interviewer will push: - **A copy.** Copying a file to a new volume or folder gives the destination a fresh $SI Created time while preserving Modified from the source. The result — Created later than Modified — looks wrong and is entirely normal. Candidates report it as tampering constantly. - **A rename or move.** The $FN times are rewritten by the operating system on rename and move, so a file that was legitimately renamed can show $FN times later than $SI times with nobody having stomped anything. - **Installers and archive extraction.** Tools that deliberately restore original timestamps set $SI on purpose; an unpacked archive or an old installer routinely leaves files whose $SI times predate the machine itself. - **A restore.** A file recovered from backup onto a rebuilt host carries its old $SI times under a brand-new $FN — which is exactly what an ageing server that has been restored once or twice looks like. None of those produce the whole pattern at once: backdated $SI times, an $SI entry-modified time inside the incident window, zeroed sub-seconds, an executable in a system directory, at a moment that lines up with other activity. One divergent field is a question. A coherent pattern across independent fields is a finding. ## What to do with it Treat the divergence as a reason to date the file from something an intruder cannot edit as easily as file metadata: other on-disk records of file activity, records held on other hosts, and any copy that already left the machine. Then write the claim in the direction the evidence supports. "The displayed creation time is inconsistent with the volume's own name record, so it cannot be used to date this file" is defensible on this evidence alone. "The intruder backdated this file on 2 March" needs the corroborating artefacts, and an interviewer will ask which ones you have.
- A file's Created time is later than its Modified time. Is that timestomping?Almost never. Copying a file gives the destination a new Created time while preserving the source's Modified time, so Created-after-Modified is the normal signature of a copy. Reporting it as tampering is the classic overreach. It becomes interesting only when the file is somewhere a copy should not have landed, or when the $FILE_NAME times contradict the $STANDARD_INFORMATION times as well.
- The backdated file's times all end in whole seconds. What does that add?NTFS records timestamps at 100-nanosecond resolution, so genuine files carry sub-second noise. Several timestomping tools write whole seconds only, leaving zeroes in that field. It is corroboration rather than proof: it points at a specific class of tooling, and a group of files in one directory sharing that pattern is far stronger than a single file doing so.
- What does $SI/$FN divergence not tell you?It does not tell you the file is malicious, who altered the times, or when the file truly arrived. It tells you the displayed times are unreliable for dating this file. The real arrival time has to come from evidence outside the file's own metadata, and the report should say which evidence you used.
It is like a parcel with a hand-written date on the label and a machine-printed date on the postage. Anyone can write on the label; the franking was applied by the post office.
saying these in an interview costs you the question
- Treats the Created date Explorer shows as authoritative
- Says any $SI and $FN divergence proves deliberate timestomping
- Believes timestomping tools alter both timestamp sets equally
- Reads a backdated timestamp as proof the file is malicious
- Calls a Created time later than Modified time tampering