AN0542: Analytic 0542
Detection of XProtect or AV quarantining a known tool, followed by modification (file size, hash, string) and subsequent re-execution by the same or related user.
Analyst context for executives and security teams
This analytic matters because it points to a macOS scenario where a known tool is quarantined by XProtect or another AV control, then changed and run again by the same or related user. For leaders, the key issue is not just the first quarantine event; it is whether the organization can prove it detects follow-on attempts to modify and re-execute the same tool after a security control has already intervened.
Executive priority
Treat this as a control-validation and incident-triage question for macOS environments. Security leaders should ask whether endpoint controls, SOC workflows, and IR procedures connect quarantine events to later file changes and execution activity. The business value is faster containment decisions, better evidence for audit or compliance review, and reduced risk that a blocked tool is simply altered and tried again without escalation.
Technical view
For SOC and detection teams, validate whether macOS telemetry can correlate three events: XProtect or AV quarantine of a known tool, subsequent modification of that file or related artifact indicated by file size, hash, or string changes, and later re-execution by the same or related user. Because no ATT&CK tactic, technique relationship, or official detection logic is supplied, implementation should be tested against local endpoint logging, AV/XProtect event visibility, file integrity evidence, and process execution records.
Likely telemetry
- macOS XProtect or AV quarantine events
- Endpoint security alerts for known tools
- File metadata changes, including size and hash changes
- File content or string-change evidence where available
- Process execution events on macOS
Detection direction
- Validate correlation across quarantine, file modification, and re-execution rather than alerting only on the initial AV event.
- Confirm whether telemetry preserves the original and modified file hash, path, user, timestamp, and execution context.
- Tune for same-user and related-user activity, while defining what 'related user' means in the local identity and endpoint model.
- Review false positives from legitimate software updates, security testing, developer activity, or AV remediation workflows that may modify and rerun files.
- Identify blind spots where AV quarantine logs are not forwarded, file changes are not captured, or process execution telemetry is incomplete on macOS.
Mitigation priorities
- Ensure macOS endpoint protection and XProtect-related events are centrally collected and retained.
- Prioritize response playbooks that escalate when a quarantined tool is modified and executed again.
- Use endpoint controls and least-privilege practices to limit unauthorized modification and execution of quarantined or suspicious files.
- Validate that IR teams can isolate the host, preserve file evidence, and review user activity when this pattern appears.
- Document detection and response coverage as compliance or audit evidence for macOS endpoint monitoring.
Analyst notes and limits
This is a detection analytic object, not a technique or procedure example. The strongest use is as a validation pattern for macOS endpoint monitoring: can the team connect a quarantine event to later file modification and re-execution? No relationship context was supplied, so this take does not infer associated tactics, techniques, threat actors, campaigns, or impact.
The supplied ATT&CK fields do not include official detection logic, tactics, relationships, aliases, or procedure examples. Coverage depends on local macOS endpoint telemetry, AV/XProtect logging, file-change visibility, and process execution collection. This summary does not claim active exploitation or guaranteed detection.
Analytic 0542
Detection of XProtect or AV quarantining a known tool, followed by modification (file size, hash, string) and subsequent re-execution by the same or related user.
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 | 9594924d6992… |
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 AN0542Open 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.