Detect timestomping on Windows by alerting on unusual changes to file creation, modification, or access times, especially for executables, scripts, and persistence artefacts. Correlate timestamp changes with process creation, file writes, and archive extraction to find inconsistencies. Compare suspicious files with neighbouring artefacts and baselines, because attackers often backdate files to conceal execution or deployment.
What timestomping changes in Windows evidence
Timestomping matters because it breaks the usual relationship between a file’s timestamps and the activity that created it. On Windows, defenders usually look for files whose creation, modification, or access times do not line up with surrounding artefacts, the parent process, or the expected deployment sequence. The strongest signal is not a strange timestamp by itself, but a timestamp that conflicts with other evidence.
That means the first task is to treat timestamps as one clue among several. A backdated executable, script, or persistence file becomes more suspicious when its timestamps do not match process creation, file writes, service installation, scheduled task creation, or archive extraction. Consistency across artefacts is what gives the timestamp meaning.
For a broader view of the artefacts that help establish those inconsistencies, use the Windows Forensic Artefacts Guide to connect file timestamps with execution evidence, NTFS data, registry traces, and log sources.
How to spot timestamp manipulation in practice
Start by comparing the suspect file with neighbouring files in the same directory, same host, or same deployment batch. If everything else in the folder was written during a narrow window but one file claims an older creation time, that mismatch deserves review. The same applies when a file’s last-write time predates the parent directory’s own history or predates the software version it appears to belong to.
Correlation is more useful than raw timestamp inspection. Look for a process that wrote the file, then check whether the process execution time, file creation time, and related artefacts line up. If a file appears long-established but you can only find a recent process write, archive extraction, or download event, the timeline may have been altered. This is especially useful for binaries, scripts, DLLs, and files used for persistence.
Because timestomping is a known adversary technique, mapping the behaviour to detection logic can help you operationalise it. A MITRE ATT&CK Guide for Defenders helps you align file-time anomalies with the relevant technique, detection data sources, and hunting workflow.
What makes a timestomped file stand out
The most common giveaway is inconsistency across artefacts, not a single impossible timestamp. A file may look old, but its hash, signer state, path, Zone.Identifier data, or surrounding directory activity suggests it was introduced recently. The file may also sit alongside artefacts that show the same operator pattern, such as freshly created persistence entries, recent archive extraction, or a burst of file writes followed by immediate execution.
Another useful clue is mismatch with the file type and role. Executables and scripts that claim to be old but appear in a recently modified user profile, temp path, staging directory, or startup location are worth closer inspection. Persistence artefacts are especially important because attackers often backdate them to make malicious deployment look routine and to confuse incident timelines.
Defenders who want to turn these cues into a repeatable detection pattern should look for suspicious combinations rather than isolated changes. Compare timestamps against parent process lineage, write activity, file origin, and known-good baselines. When those sources disagree, the file may have been deliberately altered to hide execution or deployment history.
Risk and Threat Considerations
Timestomping is useful to attackers because it degrades timeline confidence. If defenders trust file metadata too quickly, they may miss recent intrusion activity, mis-rank the most relevant files, or underestimate how long a malicious artefact has been present. That is why timestamp anomalies should be investigated as a potential concealment tactic, not dismissed as harmless metadata drift.
Failure mechanism: An attacker writes or drops a file, then alters its timestamps to fit an older, benign-looking timeline. The manipulation succeeds when defenders rely on file metadata without correlating it to process creation, file write activity, and other host artefacts.
Impact: The altered timeline can delay detection, obscure initial execution, and make persistence artefacts appear legitimate. It can also weaken incident scoping because the apparent file age no longer reflects the real compromise window.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1070.006 — Timestomp | Directly covers timestamp alteration used to hide file activity. |
| Recommendation — Map file-time anomalies to Timestomp and hunt for mismatched write, execute, and directory timelines. | ||
| NIST CSF 2.0 | DE.AE-03 — Anomalous activity is detected and analyzed | Timestamp inconsistencies are an anomalous host signal needing analysis. |
| Recommendation — Correlate suspicious timestamp changes with host activity and escalate unexplained inconsistencies. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Timestamp manipulation is best found by analyzing logs and file activity together. |
| SI-4 — System Monitoring | Detecting timestomping depends on monitoring file and process behaviour on endpoints. | |
| Recommendation — Review correlated log and file-system evidence to validate or reject suspicious file times. Monitor endpoint file-time changes and alert on suspicious timestamp, write, and execution patterns. | ||
Practitioner Guidance
What to verify: Treat any suspicious timestamp as untrusted until you can support it with at least one independent source of evidence, such as process creation logs, file system activity, archive extraction, or a neighbouring artefact baseline. If those sources disagree, investigate the mismatch before you accept the file’s apparent age.
Decision rule: If the file is executable, script-like, or persistence-related and its timestamps do not align with surrounding host activity, prioritise timeline reconstruction over isolated metadata review. If the file also appears in a location or sequence that is inconsistent with normal software deployment, elevate it for deeper triage.
Practitioner takeaway: The reliable signal is not “an old timestamp”, it is “a timestamp that cannot be reconciled with the rest of the host timeline.” Correlation is what turns timestomping from a metadata anomaly into a defensible detection.
Related resources from NHI Mgmt Group
- How do you detect Encrypting File System RPC abuse such as PetitPotam on Windows?
- How do you detect suspicious file downloads with curl or wget on Windows?
- How should security teams detect ransomware activity from file creation and shadow copy deletion on Windows endpoints?
- What are the signs that file monitoring on Windows servers is failing to detect suspicious activity?