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

T1564.009: Resource Forking

Adversaries may abuse resource forks to hide malicious code or executables to evade detection and bypass security applications. A resource fork provides applications a structured way to store resources such as thumbnail images, menu definitions, icons, dialog boxes, and code.[1] Usage of a resource fork is identifiable when displaying a file’s extended attributes, using ls -l@ or xattr -l commands. Resource forks have been deprecated and replaced with the application bundle structure. Non-localized resources are placed at the top level directory of an application bundle, while localized resources are placed in the /Resources folder.[2][3]

Adversaries can use resource forks to hide malicious data that may otherwise be stored directly in files. Adversaries can execute content with an attached resource fork, at a specified offset, that is moved to an executable location then invoked. Resource fork content may also be obfuscated/encrypted until execution.[4][5]

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

Analyst context for executives and security teams

Analyst confidence High

Resource Forking is a macOS-specific hiding technique where adversaries may place malicious data, code, or executable content in a file’s resource fork or extended attributes instead of the visible main file content. For leaders, the practical issue is not the fork itself; it is whether macOS security monitoring, file inspection, and incident response processes can see hidden file metadata that ordinary file review may miss.

Executive priority

Treat this as a macOS visibility and assurance question. Organizations with material macOS fleets should ask whether endpoint controls, SOC triage, malware review, and IR collection include extended attributes/resource fork inspection. This matters for resilience and audit confidence because the ATT&CK object has no official detection text, yet it is linked to a specific detection strategy and to known macOS malware/software entries, making local validation important before assuming coverage.

Technical view

This is a sub-technique of Hide Artifacts under the stealth tactic and applies to macOS. Defenders should validate whether file collection and endpoint telemetry expose extended attributes and resource fork usage, especially where content is moved to an executable location and invoked. Because MITRE does not provide official detection logic here, SOC teams should use the related Detection Strategy for Resource Forking on macOS as a starting point and test whether tooling preserves and analyzes resource fork metadata rather than only the data fork or application bundle contents.

Likely telemetry

  • macOS file metadata showing extended attributes/resource forks
  • Endpoint file creation, modification, move, and execution events on macOS
  • Security tool scan, quarantine, and file-inspection logs that indicate whether extended attributes are inspected
  • IR collection artifacts that preserve extended attributes rather than flattening files
  • Application bundle and Resources directory inspection data where relevant

Detection direction

  • Confirm that macOS EDR, file integrity, and forensic collection tooling can enumerate and retain extended attributes/resource fork content.
  • Tune for unusual or suspicious resource fork presence on executable-related files while accounting for legitimate legacy or application resource behavior.
  • Correlate resource fork metadata with subsequent file movement to executable locations and process invocation activity.
  • Do not rely only on filename, visible file size, or standard file content inspection; those may miss data stored outside the primary data fork.
  • Use the relationship to DET0584 as a cue to evaluate a macOS-specific detection strategy, but verify coverage in the local environment because no official ATT&CK detection text is supplied.

Mitigation priorities

  • Prioritize secure application developer guidance for macOS software handling and packaging, consistent with the mapped M1013 mitigation.
  • Reduce reliance on deprecated resource fork behavior where internal applications or workflows still use it, and document legitimate exceptions.
  • Ensure security engineering and IR procedures require preservation and review of extended attributes during macOS investigations.
  • Validate that endpoint and malware scanning controls inspect resource fork content or clearly document gaps requiring compensating monitoring.
Analyst notes and limits

The object is limited to macOS and is categorized under stealth through Hide Artifacts. ATT&CK links this behavior to Keydnap and OSX/Shlayer software entries, which supports treating it as a realistic macOS tradecraft concern without making any claim about current activity or customer exposure.

Official ATT&CK detection content is not provided for this technique, and the supplied mitigation relationship is broad application developer guidance rather than a resource-fork-specific control. Local telemetry testing is required to determine whether existing tools actually collect, preserve, and analyze resource fork and extended attribute data.

Official MITRE ATT&CK definition

Resource Forking

Adversaries may abuse resource forks to hide malicious code or executables to evade detection and bypass security applications. A resource fork provides applications a structured way to store resources such as thumbnail images, menu definitions, icons, dialog boxes, and code.[1] Usage of a resource fork is identifiable when displaying a file’s extended attributes, using ls -l@ or xattr -l commands. Resource forks have been deprecated and replaced with the application bundle structure. Non-localized resources are placed at the top level directory of an application bundle, while localized resources are placed in the /Resources folder.[2][3]

Adversaries can use resource forks to hide malicious data that may otherwise be stored directly in files. Adversaries can execute content with an attached resource fork, at a specified offset, that is moved to an executable location then invoked. Resource fork content may also be obfuscated/encrypted until execution.[4][5]

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.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S0276: Keydnap

This piece of malware steals the content of the user's keychain while maintaining a permanent backdoor [1].

macOS
Relationship explorer

All related ATT&CK context

uses · Malware S0276: Keydnap Enterprise detects · Detection Strategy DET0584: Detection Strategy for Resource Forking on macOS Enterprise subtechnique of · Technique T1564: Hide Artifacts Enterprise uses · Malware S0402: OSX/Shlayer Enterprise mitigates · Mitigation M1013: Application Developer Guidance Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1013: Application Developer Guidance

Application Developer Guidance focuses on providing developers with the knowledge, tools, and best practices needed to write secure code, reduce vulnerabilities, and implement secure design principles. By integrating security throughout the software development lifecycle (SDLC), this mitigation aims to prevent the introduction of exploitable weaknesses in applications, systems, and APIs. This mitigation can be implemented through the following measures: Preventing SQL Injection (Secure Coding Practice):

- Implementation: Train developers to use parameterized queries or prepared statements instead of directly embedding user input into SQL queries. - Use Case: A web application accepts user input to search a database. By sanitizing and validating user inputs, developers can prevent attackers from injecting malicious SQL commands.

Cross-Site Scripting (XSS) Mitigation:

- Implementation: Require developers to implement output encoding for all user-generated content displayed on a web page. - Use Case: An e-commerce site allows users to leave product reviews. Properly encoding and escaping user inputs prevents malicious scripts from being executed in other users’ browsers.

Secure API Design:

- Implementation: Train developers to authenticate all API endpoints and avoid exposing sensitive information in API responses. - Use Case: A mobile banking application uses APIs for account management. By enforcing token-based authentication for every API call, developers reduce the risk of unauthorized access.

Static Code Analysis in the Build Pipeline:

- Implementation: Incorporate tools into CI/CD pipelines to automatically scan for vulnerabilities during the build process. - Use Case: A fintech company integrates static analysis tools to detect hardcoded credentials in their source code before deployment.

Threat Modeling in the Design Phase:

- Implementation: Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to assess threats during application design. - Use Case: Before launching a customer portal, a SaaS company identifies potential abuse cases, such as session hijacking, and designs mitigations like secure session management.

**Tools for Implementation**:

- Static Code Analysis Tools: Use tools that can scan for known vulnerabilities in source code. - Dynamic Application Security Testing (DAST): Use tools like Burp Suite or OWASP ZAP to simulate runtime attacks and identify vulnerabilities. - Secure Frameworks: Recommend secure-by-default frameworks (e.g., Django for Python, Spring Security for Java) that enforce security best practices.

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
dc18214de00e3bb6...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle dc18214de00e…
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]
    macOS Hierarchical File System Overview

    Tenon. (n.d.). Retrieved October 12, 2021.

    Open source URL
  2. [2]
    Resource and Data Forks

    Flylib. (n.d.). Identifying Resource and Data Forks. Retrieved October 12, 2021.

    Open source URL
  3. [3]
    ELC Extended Attributes

    Howard Oakley. (2020, October 24). There's more to files than data: Extended Attributes. Retrieved October 12, 2021.

    Open source URL
  4. [4]
    sentinellabs resource named fork 2020

    Phil Stokes. (2020, November 5). Resourceful macOS Malware Hides in Named Fork. Retrieved October 12, 2021.

    Open source URL
  5. [5]
    tau bundlore erika noerenberg 2020

    Erika Noerenberg. (2020, June 29). TAU Threat Analysis: Bundlore (macOS) mm-install-macos. Retrieved October 12, 2021.

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