Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1628: Analytic 1628

Detects timestamp changes using `touch`, `SetFile`, or direct metadata tampering (e.g., xattr manipulation) from Terminal, scripts, or low-level APIs.

EnterpriseAN1628AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because macOS timestamp changes can reduce the reliability of file timelines that executives, SOC teams, and incident responders depend on during investigations. The supplied ATT&CK object focuses on detecting timestamp modification through tools such as `touch` and `SetFile`, or direct metadata tampering such as extended attribute manipulation. For leaders, the decision value is whether macOS endpoint telemetry is strong enough to preserve trustworthy evidence when investigating suspicious activity or proving incident scope.

Executive priority

Prioritize this as an evidence-integrity and investigation-readiness control for macOS environments. If attackers or unauthorized users can alter file timestamps without detection, incident timelines, containment decisions, legal/compliance evidence, and root-cause analysis may be weakened. Security leaders should ask whether managed detection, IR processes, and endpoint logging can identify suspicious timestamp changes and distinguish legitimate administrative or developer activity from behavior that undermines forensic confidence.

Technical view

SOC and detection engineering teams should validate visibility into macOS file metadata changes associated with Terminal usage, scripts, `touch`, `SetFile`, extended attribute activity, and low-level API-driven changes where telemetry allows. Because no official detection logic is provided, teams should build local detection criteria around process execution, command-line context, parent process lineage, target file paths, user context, and file metadata change events. IR teams should treat detected timestamp manipulation as a signal to scrutinize nearby activity and avoid relying solely on filesystem times for timeline reconstruction.

Likely telemetry

  • macOS endpoint process execution telemetry
  • Command-line arguments for Terminal, shell, script, `touch`, and `SetFile` activity
  • Parent-child process lineage for Terminal-launched or script-launched actions
  • File metadata change events, where available
  • Extended attribute or xattr-related telemetry, where available

Detection direction

  • Validate whether macOS telemetry captures both command-based timestamp changes and metadata tampering that may not appear as simple `touch` usage.
  • Tune detections around suspicious context, such as unusual users, sensitive paths, recently created files with older timestamps, or timestamp changes near other suspicious process activity.
  • Account for false positives from build systems, packaging workflows, software deployment, backup/restore operations, developer tooling, and administrative maintenance.
  • Correlate timestamp changes with parent process lineage and user context rather than alerting on every use of timestamp utilities.
  • Identify blind spots where low-level API use or extended attribute manipulation is not captured by existing endpoint telemetry.

Mitigation priorities

  • First, confirm macOS endpoint logging and EDR configuration collect process, command-line, and file metadata evidence needed for investigation.
  • Next, define approved administrative, deployment, development, and backup use cases that commonly change timestamps so detections can be tuned without suppressing suspicious activity.
  • Ensure incident response playbooks account for possible timestamp manipulation and rely on multiple evidence sources, not filesystem timestamps alone.
  • Preserve endpoint forensic data during investigations so altered metadata can be compared with process, user, and file activity records.
  • Use detection validation exercises to confirm that `touch`, `SetFile`, and xattr-related metadata changes are visible in the organization’s telemetry.
Analyst notes and limits

The ATT&CK object is a detection analytic for macOS timestamp changes. It provides a short description but no official detection logic, tactics, labels, aliases, or relationship context. The strongest defensive value is in validating telemetry coverage and forensic reliability rather than treating this object as a complete detection rule.

This take is limited to the supplied STIX fields and external reference. No relationship context, active threat use, attribution, severity, or validated detection logic was supplied. Local environment testing is required to determine whether macOS telemetry, EDR configuration, and SOC rules actually detect this behavior.

Official MITRE ATT&CK definition

Analytic 1628

Detects timestamp changes using `touch`, `SetFile`, or direct metadata tampering (e.g., xattr manipulation) from Terminal, scripts, or low-level APIs.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
f0f6e7e0ecd35a9e...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle f0f6e7e0ecd3…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1628
    Open source URL
Source and licensing

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.