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

T1564.014: Extended Attributes

Adversaries may abuse extended attributes (xattrs) on macOS and Linux to hide their malicious data in order to evade detection. Extended attributes are key-value pairs of file and directory metadata used by both macOS and Linux. They are not visible through standard tools like `Finder`, `ls`, or `cat` and require utilities such as `xattr` (macOS) or `getfattr` (Linux) for inspection. Operating systems and applications use xattrs for tagging, integrity checks, and access control. On Linux, xattrs are organized into namespaces such as `user.` (user permissions), `trusted.` (root permissions), `security.`, and `system.`, each with specific permissions. On macOS, xattrs are flat strings without namespace prefixes, commonly prefixed with `com.apple.*` (e.g., `com.apple.quarantine`, `com.apple.metadata:_kMDItemUserTags`) and used by system features like Gatekeeper and Spotlight.[1]

An adversary may leverage xattrs by embedding a second-stage payload into the extended attribute of a legitimate file. On macOS, a payload can be embedded into a custom attribute using the `xattr` command. A separate loader can retrieve the attribute with `xattr -p`, decode the content, and execute it using a scripting interpreter. On Linux, an adversary may use `setfattr` to write a payload into the `user.` namespace of a legitimate file. A loader script can later extract the payload with `getfattr --only-values`, decode it, and execute it using bash or another interpreter. In both cases, because the primary file content remains unchanged, security tools and integrity checks that do not inspect extended attributes will observe the original file hash, allowing the malicious payload to evade detection.[2]

EnterpriseT1564.014Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Extended Attributes abuse matters because malicious content can be stored in file metadata on Linux and macOS while the visible file content and normal file hash remain unchanged. For leaders, the risk is not simply “hidden data”; it is a coverage gap where endpoint controls, integrity monitoring, and investigations may appear clean if they do not inspect extended attributes.

Executive priority

Prioritize this as a stealth and assurance issue for Linux and macOS estates. Security leaders should ask whether endpoint monitoring, file integrity checks, incident response playbooks, and compliance evidence include extended attribute inspection, not just standard file contents and hashes. This is especially relevant where business-critical systems rely on Linux/macOS endpoints or servers and where audit claims depend on file integrity monitoring.

Technical view

This is a sub-technique of Hide Artifacts for Linux and macOS. ATT&CK describes adversaries placing payload data in extended attributes and using separate loader behavior to retrieve, decode, and execute it. SOC and IR teams should validate whether tooling can enumerate and inspect xattrs, correlate suspicious xattr reads/writes with process execution, and distinguish expected operating system/application attributes from unusual custom attributes or abnormal attribute content. The related mitigation is Behavior Prevention on Endpoint, so coverage should be tested against behavior patterns, not only known file signatures.

Likely telemetry

  • Endpoint process creation telemetry involving extended attribute utilities such as macOS xattr and Linux getfattr/setfattr where collected
  • File metadata telemetry that includes extended attribute names, namespaces, sizes, and modification activity
  • File integrity monitoring that can compare extended attributes in addition to file content hashes
  • Script interpreter and shell execution telemetry correlated with prior extended attribute access
  • Endpoint detection events for suspicious process, file, API call, or behavioral patterns on Linux and macOS

Detection direction

  • Validate DET0406 or equivalent detection logic in the local environment rather than assuming standard file monitoring covers this technique.
  • Tune for unusual or high-risk xattr activity: unexpected custom attributes, large attribute values, changes to legitimate files with unchanged content hashes, or xattr access followed by interpreter execution.
  • Account for legitimate use of xattrs by macOS features such as Gatekeeper and Spotlight and by Linux namespaces including user., trusted., security., and system.; detections need allowlisting or context to reduce false positives.
  • Review whether EDR, FIM, and forensic collection preserve xattrs. A common blind spot is collecting the file but not the metadata where the hidden content may reside.
  • Correlate xattr activity with the parent Hide Artifacts behavior: evidence may be weak in isolation but stronger when paired with stealthy execution, unusual scripts, or suspicious endpoint behavior.

Mitigation priorities

  • Implement behavior prevention on endpoints where available, focusing on suspicious process behavior and file/metadata access patterns rather than signatures alone.
  • Extend file integrity and investigation procedures to include extended attributes on Linux and macOS systems.
  • Restrict and monitor unnecessary scripting or interpreter execution paths where they interact with unusual file metadata access.
  • Define baselines for expected xattrs on managed systems so security teams can identify abnormal attributes without overwhelming analysts with legitimate OS/application metadata.
  • Include xattr inspection in IR checklists for Linux and macOS hosts when file hashes appear clean but execution behavior is suspicious.
Analyst notes and limits

The official ATT&CK object provides a clear description and platform scope but no official detection text. The relationship to DET0406 indicates a detection strategy exists, and M1040 supports behavior-prevention-oriented mitigation. Local validation is essential because normal xattr usage is common on macOS and can also be legitimate on Linux.

This take is limited to the supplied ATT&CK fields, references, and relationships. It does not assert active exploitation, attribution, impact, or existing customer exposure. Detection feasibility depends on whether local endpoint, filesystem, and forensic tooling collect extended attributes and related process context.

Official MITRE ATT&CK definition

Extended Attributes

Adversaries may abuse extended attributes (xattrs) on macOS and Linux to hide their malicious data in order to evade detection. Extended attributes are key-value pairs of file and directory metadata used by both macOS and Linux. They are not visible through standard tools like `Finder`, `ls`, or `cat` and require utilities such as `xattr` (macOS) or `getfattr` (Linux) for inspection. Operating systems and applications use xattrs for tagging, integrity checks, and access control. On Linux, xattrs are organized into namespaces such as `user.` (user permissions), `trusted.` (root permissions), `security.`, and `system.`, each with specific permissions. On macOS, xattrs are flat strings without namespace prefixes, commonly prefixed with `com.apple.*` (e.g., `com.apple.quarantine`, `com.apple.metadata:_kMDItemUserTags`) and used by system features like Gatekeeper and Spotlight.[1]

An adversary may leverage xattrs by embedding a second-stage payload into the extended attribute of a legitimate file. On macOS, a payload can be embedded into a custom attribute using the `xattr` command. A separate loader can retrieve the attribute with `xattr -p`, decode the content, and execute it using a scripting interpreter. On Linux, an adversary may use `setfattr` to write a payload into the `user.` namespace of a legitimate file. A loader script can later extract the payload with `getfattr --only-values`, decode it, and execute it using bash or another interpreter. In both cases, because the primary file content remains unchanged, security tools and integrity checks that do not inspect extended attributes will observe the original file hash, allowing the malicious payload to evade detection.[2]

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.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1564 Hide Artifacts This object subtechnique of Hide Artifacts.
Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0406: Detection Strategy for Extended Attributes Abuse Enterprise subtechnique of · Technique T1564: Hide Artifacts Enterprise mitigates · Mitigation M1040: Behavior Prevention on Endpoint Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1040: Behavior Prevention on Endpoint

Behavior Prevention on Endpoint refers to the use of technologies and strategies to detect and block potentially malicious activities by analyzing the behavior of processes, files, API calls, and other endpoint events. Rather than relying solely on known signatures, this approach leverages heuristics, machine learning, and real-time monitoring to identify anomalous patterns indicative of an attack. This mitigation can be implemented through the following measures:

Suspicious Process Behavior:

- Implementation: Use Endpoint Detection and Response (EDR) tools to monitor and block processes exhibiting unusual behavior, such as privilege escalation attempts. - Use Case: An attacker uses a known vulnerability to spawn a privileged process from a user-level application. The endpoint tool detects the abnormal parent-child process relationship and blocks the action.

Unauthorized File Access:

- Implementation: Leverage Data Loss Prevention (DLP) or endpoint tools to block processes attempting to access sensitive files without proper authorization. - Use Case: A process tries to read or modify a sensitive file located in a restricted directory, such as /etc/shadow on Linux or the SAM registry hive on Windows. The endpoint tool identifies this anomalous behavior and prevents it.

Abnormal API Calls:

- Implementation: Implement runtime analysis tools to monitor API calls and block those associated with malicious activities. - Use Case: A process dynamically injects itself into another process to hijack its execution. The endpoint detects the abnormal use of APIs like `OpenProcess` and `WriteProcessMemory` and terminates the offending process.

Exploit Prevention:

- Implementation: Use behavioral exploit prevention tools to detect and block exploits attempting to gain unauthorized access. - Use Case: A buffer overflow exploit is launched against a vulnerable application. The endpoint detects the anomalous memory write operation and halts the process.

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
2.0
Created
Modified
Raw hash
77fbb1f5bba1d20b...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 77fbb1f5bba1…
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.

Open mirrored raw JSON Open MITRE-hosted copy
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]
    Establishing persistence using extended attributes on Linux

    Irem Kuyucu. (2024, August 6). Establishing persistence using extended attributes on Linux. Retrieved March 27, 2025.

    Open source URL
  2. [2]
    Low GroupIB xattrs nov 2024

    Sharmine Low. (2024, November 13). Stealthy Attributes of Lazarus APT Group: Evading Detection with Extended Attributes. Retrieved March 27, 2025.

    Open source URL
  3. [3]
    mitre-attack T1564.014
    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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use