In NTFS, what does a file whose $STANDARD_INFORMATION times predate its $FILE_NAME times suggest?

## 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.