Detect timestomping on Linux by monitoring for direct metadata changes to file access, modification, or status times that do not match normal application behaviour. Compare file timestamps with process execution, package installation, and audit records to find inconsistencies. Investigate sudden backdating of binaries, scripts, or configuration files, especially when it hides recent attacker activity or persistence.
What timestomping looks like on Linux in practice
Timestomping on Linux is a file integrity and anti-forensics problem: an attacker changes timestamps to make a file look older, less suspicious, or aligned with legitimate activity. The key question is not whether a timestamp changed, but whether the change fits the surrounding event history for that file, that process, and that host.
Good detection starts with baseline expectations. Ordinary software updates, builds, backups, package managers, editors, and deployment tools all create timestamp noise, but they usually do so in patterns you can explain. Suspicious timestomping is often isolated, selective, and aimed at binaries, scripts, cron entries, startup items, or configuration files that matter for persistence or execution.
On Linux, the most useful comparison is between the file’s metadata and the event trail around it. If a file claims to be old but process execution logs, shell history, package install records, or audit records show it was touched recently, that mismatch is a strong investigative lead. The reverse is also useful: a newly created file with artificially old timestamps can indicate staging, substitution, or hiding of attacker tooling.
Which Linux telemetry is most useful for detection?
Timestamp analysis works best when you combine multiple sources instead of trusting the file metadata alone. Linux Detection and Response Guide is a useful reference point for aligning audit logs, journald, eBPF telemetry, and incident response data so you can validate whether the file timeline is credible.
Audit records are especially valuable because they can show file writes, attribute changes, and the processes involved. Package manager logs help separate normal maintenance from suspicious modification. Process accounting, cron logs, login records, and service startup history can show whether a timestamped object was plausibly active when the filesystem says it was not. A good detector treats the file timestamp as one signal, not the source of truth.
For higher-fidelity detection, monitor the paths that matter most: system binaries, scripts in execution paths, service files, scheduled-task locations, and configuration directories that affect login, privilege, or persistence. Timestamp tampering on those paths is more meaningful than on temporary files or user scratch space, because those objects are more likely to support long-lived compromise.
How do you tell benign metadata changes from attacker activity?
Legitimate tools do change timestamps, so the distinguishing factor is usually consistency. A maintenance job that modifies a package file should line up with package metadata, change windows, and a known process. A suspicious change often lacks that support, happens outside normal change control, or affects only the metadata while the surrounding content and system history do not match.
Use a simple investigative rule: if a file’s access, modification, or status times appear deliberately backdated, ask what event should have produced that timeline and whether the host evidence confirms it. If the answer is no, treat the file as potentially manipulated and investigate the parent process, the execution chain, and any nearby persistence mechanism.
Attackers often timestomp after writing a payload or implant so that it blends into older system state. That makes timestamp anomalies especially useful when paired with evidence of recent execution, recent privilege use, or recent configuration drift. The goal is to identify when the filesystem story and the host activity story disagree.
Risk and Threat Considerations
Timestomping is valuable to attackers because it reduces the visibility of recent file creation, replacement, or modification. If defenders rely on timestamps without corroborating telemetry, malicious files can look preexisting and delay response, especially when the activity is tied to persistence or post-compromise staging.
Failure mechanism: An attacker writes or alters a file, then changes its time attributes to make the object appear older or operationally ordinary, which can break timeline-based triage and hide the true order of execution.
Impact: Investigators may miss the first foothold, underestimate dwell time, or fail to connect a suspicious file to a recent process, package change, or persistence event.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1070.006 — Timestomp | Directly covers file time attribute manipulation used to hide activity. |
| Recommendation — Detect timestamp changes that do not align with surrounding execution and file events. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Logging and audit records are central to validating suspicious file time changes. |
| Recommendation — Retain and review host audit logs that can corroborate file modifications and attribute changes. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Timestomping is discovered through anomaly monitoring across host and file activity. |
| Recommendation — Correlate file metadata with host events to spot anomalous timestamp manipulation. | ||
Practitioner Guidance
What to verify: Correlate file times with process creation, package installation, service changes, and audit records before treating a timestamp as trustworthy. If the timestamp story does not line up with host activity, escalate the file for manual review rather than normalising it as housekeeping.
What good looks like: Your monitoring can explain why a file changed, who or what changed it, and whether the change matches approved administration or software delivery. The most useful detections are the ones that surface a timeline mismatch early enough to inspect surrounding persistence paths and recent execution history.
Practitioner takeaway: On Linux, timestomping detection is strongest when timestamp anomalies are treated as evidence of inconsistency, not proof on their own, and are always confirmed against independent host telemetry.