AN1136: Analytic 1136
Abuse of extended attributes (xattrs) to hide payloads in com.apple.* or custom keys. Defender perspective: monitor suspicious use of xattr command with -w (write) and -p (print) flags, especially when followed by execution of interpreters like bash, Python, or osascript. Behavior chain includes: (1) suspicious file modification with new com.apple.* attributes, (2) attribute content inconsistent with expected metadata tags (e.g., high entropy), (3) subsequent process execution correlated with extraction of the attribute.
Analyst context for executives and security teams
This analytic matters because it focuses on a macOS hiding technique: storing suspicious payload content in extended file attributes rather than in the visible file body. For executives and security leaders, the risk is not the attribute feature itself, but the blind spot it can create if endpoint monitoring, SOC triage, and incident response playbooks only inspect normal files and process execution. The decision value is to confirm whether macOS telemetry can show unusual extended attribute writes/reads and connect them to later interpreter execution.
Executive priority
Prioritize this as a macOS endpoint visibility and incident readiness issue. Leaders should ask whether managed detection, EDR, and IR processes collect enough file metadata and process context to investigate suspicious xattr activity, especially where macOS systems are used by privileged users, developers, administrators, or business-critical teams. This also has audit and compliance value: being able to show collection and review of endpoint behavior beyond standard file hashes strengthens evidence that macOS endpoints are monitored for stealthy persistence or payload staging patterns.
Technical view
For SOC and detection teams, validate monitoring for suspicious use of the macOS xattr command, especially write and print activity, and correlate it with later execution by interpreters such as bash, Python, or osascript as described in the ATT&CK analytic. Useful triage should examine whether new com.apple.* or custom extended attributes appear on files, whether attribute contents look inconsistent with expected metadata such as high entropy or payload-like data, and whether a process later extracts or uses that attribute content. Because no standalone official detection logic is provided, teams should treat this as a detection design requirement rather than an out-of-the-box rule.
Likely telemetry
- macOS process creation telemetry, including command-line arguments for xattr usage
- File modification or file metadata telemetry that records creation or changes to extended attributes
- Endpoint security or EDR events showing parent-child process relationships after xattr access
- Process execution telemetry for interpreters such as bash, Python, and osascript
- File path, user, timestamp, and host context to correlate attribute writes/reads with subsequent execution
Detection direction
- Confirm whether current macOS logging or EDR tooling records xattr command usage with flags and arguments; many environments collect process starts but not detailed file metadata changes.
- Build correlation around suspicious sequences: extended attribute write/read activity followed by interpreter execution from the same user, host, path, or parent process context.
- Tune carefully because extended attributes are legitimate on macOS; prioritize unusual custom keys, unexpected com.apple.* modifications, high-entropy attribute contents, and activity in user-writable or unusual locations.
- Review false positives from software installers, developer tooling, backup/sync agents, and macOS-native metadata operations before escalating to high severity.
- Use this analytic to test IR visibility: analysts should be able to answer what attribute changed, who changed it, what process accessed it, and what executed afterward.
Mitigation priorities
- First, ensure macOS endpoint telemetry captures process command lines and sufficient file metadata to observe extended attribute changes.
- Next, restrict or monitor high-risk interpreter execution where appropriate for the environment, particularly from unusual parent processes or user-writable locations.
- Harden endpoint response procedures so investigators inspect extended attributes during macOS malware or suspicious script investigations, not just visible file contents.
- Apply least privilege and endpoint control policies to reduce unnecessary script and interpreter use on systems that do not require it.
- Use detection engineering validation or purple-team-style testing in a controlled environment to confirm the SOC can observe and triage the behavior chain described by the analytic.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for macOS extended attribute abuse. It provides a behavior chain and defender perspective but does not include a formal detection query, tactics, mitigations, software relationships, groups, or procedures. The strongest use is as a visibility and correlation checklist for macOS endpoint monitoring and IR readiness.
Assessment is limited to the supplied official STIX fields, external reference, and lack of relationships. No active exploitation, attribution, business impact, or guaranteed detection coverage should be inferred. Local telemetry capabilities, EDR configuration, logging retention, and legitimate macOS software behavior must be validated in the customer environment.
Analytic 1136
Abuse of extended attributes (xattrs) to hide payloads in com.apple.* or custom keys. Defender perspective: monitor suspicious use of xattr command with -w (write) and -p (print) flags, especially when followed by execution of interpreters like bash, Python, or osascript. Behavior chain includes: (1) suspicious file modification with new com.apple.* attributes, (2) attribute content inconsistent with expected metadata tags (e.g., high entropy), (3) subsequent process execution correlated with extraction of the attribute.
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 | 85d4dfdc237c… |
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 AN1136Open 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.