Two Creation Times, Two Years Apart
On a Windows 10 workstation seized from a departing employee you find C:\Users\jdoe\Desktop\FY19_Q4_forecast.xlsx. Its $STANDARD_INFORMATION attribute shows created and modified 2021-02-03 11:02:10 UTC. The $FILE_NAME attribute for the same MFT record shows created 2023-04-11 09:14:22 UTC. The $UsnJrnl contains a FileCreate record for that file name at 2023-04-11 09:14:22 and a BasicInfoChange record at 2023-04-11 09:16:03. The MFT record number is 146,332. The suspect says the file is 'an old forecast from 2019, never touched'. The workstation clock is NTP-synced within two seconds.
1. Explain the mechanisms that can produce this discrepancy, and what each implies.
Read the worked answer
The two timestamp sets are written by different code paths.
- $STANDARD_INFORMATION lives in the MFT record and is updated through the Windows API. Any user-mode process with write access can set it with
SetFileTime- this is what timestomping tools call. - $FILE_NAME timestamps are maintained by the kernel and are not normally writable from user mode. They are set on creation and refreshed when the file is renamed or moved between directories.
A $SI creation time more than two years older than $FN creation is the classic backdating signature: the file really came into being on 2023-04-11 and someone then wrote an older creation time into $SI.
The USN journal corroborates rather than merely repeats. The FileCreate at 09:14:22 is the file's actual appearance. The BasicInfoChange at 09:16:03 - roughly two minutes later, with no corresponding content write - is what changing timestamps via the API generates. That sequencing is far harder to explain innocently than the attribute mismatch alone.
Innocent explanations must still be tested: copy tools that preserve timestamps, archive extractors, backup/restore agents, and file-sync clients can all set $SI creation time legitimately. Note also that a rename updates $FN - so a rename, not a creation, is a competing explanation that the USN record has to rule out.
2. What else on the workstation would you examine to corroborate or defeat the timestomping inference?
Read the worked answer
Build a timeline that does not depend on the disputed file's own metadata.
- Neighbouring MFT records. Record 146,332 is high. Compare with records allocated in 2021 and 2023 elsewhere on the volume: if record numbers near 146,332 consistently carry April 2023 timestamps, the record's allocation belongs to 2023.
- $LogFile and $I30 index timestamps on the parent Desktop folder - the directory index entry carries its own copy of $FILE_NAME times and the directory's own update times.
- Execution and access artefacts: Amcache and AppCompatCache/ShimCache (did Excel or a sync client run that day?), Prefetch (first and last run, and volume of run count), Office MRU keys and RecentDocs, and any LNK pointing at the file.
- Zone.Identifier ADS on the file, which would carry the download source and time if it arrived from the internet.
- Content forensics: the workbook's internal properties and any embedded dates, and whether the data inside is plausibly 2019, 2021, or 2023 vintage.
- Tool artefacts: if a timestomping utility was used, look for its execution traces (Prefetch, Amcache, USN records for the utility itself, PowerShell operational logs).
A finding is much stronger when the USN sequence, record allocation pattern, and an execution artefact all independently place the file's creation in April 2023.
3. Counsel for the suspect argues the file 'was restored from backup by IT'. How do you test that, and how do you word the finding?
Read the worked answer
Test it against what a restore would actually leave behind.
- Ask for the backup product, job logs, and restore records, and check whether a restore job ran on 2023-04-11 around 09:14 and whether this path was in scope.
- A restore through a backup agent typically writes the file with the agent's own process context and often produces a different forensic fingerprint: the file may appear via a different mechanism than a plain FileCreate, timestamps may come from the archive metadata in one operation rather than two, and there would be no BasicInfoChange two minutes after creation.
- Check whether other files restored in the same job show the same pattern. A restore affects many files; timestomping affects the ones someone cared about.
- Establish who was logged in and whether the workstation was even reachable by the backup infrastructure at that moment.
Wording: state the observation, then the inference, then the limits.
The file was created on the volume at 2023-04-11 09:14:22 UTC. Its $SI creation time was subsequently altered to 2021-02-03 11:02:10, as evidenced by the $FN/$SI discrepancy and the BasicInfoChange record at 09:16:03. No backup or restore activity was identified that would account for this pattern.
Avoid 'the suspect faked the file date'; say what the artefacts show and note who had access to the account. Offer the alternative hypotheses you tested and why you rejected them.