AN1626: Analytic 1626
Detects attempts to modify file timestamps via API usage (e.g., `SetFileTime`), CLI tools (e.g., `w32tm`, PowerShell), or double-timestomp behavior where $SI and $FN timestamps are mismatched or reverted.
Analyst context for executives and security teams
This analytic matters because file timestamp manipulation can undermine incident timelines, evidence quality, and confidence in what changed when on Windows systems. For leaders, the practical issue is not just detecting a suspicious command or API call; it is whether SOC and IR teams can trust endpoint time evidence during an investigation.
Executive priority
Prioritize this as an evidence-integrity and incident-readiness control. Security leaders should ask whether Windows endpoint telemetry can show timestamp changes, whether responders can compare multiple timestamp sources, and whether audit evidence remains reliable when adversaries or tools attempt to alter file times. This is especially relevant for organizations that depend on forensic timelines for breach scoping, legal review, regulatory reporting, or operational recovery decisions.
Technical view
AN1626 is a Windows detection analytic focused on attempts to modify file timestamps through API usage such as SetFileTime, command-line tooling such as w32tm or PowerShell, and double-timestomp behavior where $SI and $FN timestamps are mismatched or reverted. SOC and detection teams should validate whether endpoint logging, file system metadata collection, process telemetry, and PowerShell/command-line visibility are sufficient to correlate timestamp-changing activity with the affected files and initiating processes. Because no ATT&CK tactic or relationship context is supplied, this should be treated as a supporting analytic for suspicious evidence manipulation rather than a standalone conclusion of malicious activity.
Likely telemetry
- Windows process creation events with command-line arguments
- PowerShell execution telemetry where available
- Endpoint detection telemetry showing file metadata changes
- File system metadata including $SI and $FN timestamp values
- API-level or EDR telemetry for file time modification behavior such as SetFileTime
Detection direction
- Validate visibility into Windows file timestamp changes, not only process execution.
- Correlate timestamp modification indicators with the responsible process, user context, file path, and parent process.
- Look for mismatches or reversions between $SI and $FN timestamps where forensic tooling or endpoint telemetry supports that comparison.
- Tune carefully for legitimate administrative, backup, deployment, synchronization, and forensic activity that may alter timestamps.
- Do not treat a single timestamp anomaly as definitive malicious behavior; use surrounding process, user, and file context to reduce false positives.
Mitigation priorities
- Ensure Windows endpoint telemetry needed for process, command-line, PowerShell, and file metadata investigation is enabled and retained.
- Standardize IR procedures for validating file timelines using multiple evidence sources rather than relying on one timestamp field.
- Restrict and monitor administrative capabilities that can alter system or file time where operationally feasible.
- Document legitimate tools and workflows that modify timestamps so detections can be tuned without suppressing meaningful anomalies.
- Use endpoint hardening, least privilege, and change-control practices to reduce unauthorized file manipulation opportunities.
Analyst notes and limits
The supplied object is a detection analytic, not a technique description. Its value is strongest as an investigation-quality control: it helps defenders identify when file timeline evidence may have been manipulated or made unreliable. Local baselining is important because some administrative and operational tools can legitimately change timestamps.
Official detection logic is not provided, tactics are not specified, and no ATT&CK relationships are supplied. This take is limited to the official description, Windows platform scope, and the external MITRE reference. Environment-specific telemetry, logging configuration, and legitimate administrative behavior must be assessed locally.
Analytic 1626
Detects attempts to modify file timestamps via API usage (e.g., `SetFileTime`), CLI tools (e.g., `w32tm`, PowerShell), or double-timestomp behavior where $SI and $FN timestamps are mismatched or reverted.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | a57d8dc1d968… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1626Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.