xattr'd and Dangerous: Living Off the Fork on macOS

Hxr1

10 Jul 2025 • 2 min read

Abusing macOS resource forks to stash and stage shellcode without touching file contents, changing hashes, or triggering EDR, pure metadata-based stealth.

This post dives deep into how macOS extended attributes, specifically the com.apple.ResourceFork which can be abused to hide and stage shellcode payloads without modifying file contents or triggering traditional EDR detection. It includes technical background, step-by-step PoC, and offensive use cases.

What Are Extended Attributes?

Modern filesystems do more than just store file contents. On macOS (and other BSD-based systems), each file can also carry extended attributes (xattrs): named metadata fields stored in the filesystem alongside the file.

These attributes are not part of the file's visible content, yet they are persistent, copyable, and accessible via standard syscalls (getxattr, setxattr) or tools (xattr, ls -l@).

Structure of xattrs

Each xattr is a key-value pair, where the key is a string (like com.apple.quarantine) and the value is arbitrary binary data.

Examples include:

com.apple.quarantine: Tracks downloaded files
com.apple.FinderInfo: Stores Finder display metadata
com.apple.ResourceFork: A legacy attribute for storing UI resources

These attributes are almost never scanned by AV or EDR solutions, and yet they can store arbitrary shellcode.

The Resource Fork: A Legacy Feature, A New Attack Surface

com.apple.ResourceFork is a legacy mechanism from Classic Mac OS used to store GUI elements, icons, strings, etc. It still exists as an extended attribute on HFS+ and APFS systems.

This fork allows arbitrary binary blobs to be stored invisibly in any file on the system. These values:

Are not visible in text editors
Do not affect file hashes
Are not scanned by AV/EDRs by default
Can be read and written using xattr

This makes com.apple.ResourceFork a stealthy channel for payload staging.

PoC

Step 1: Create a clean carrier file

$ echo "this is a normal file" > file.txt
$ sha256sum file.txt

Output

82d5419e8a3ec77a24e8ac8ac46480e76a712dd43d03aa6a5607a615a48b3b96  file.txt

Step 2: Embed Base64-encoded shellcode into the resource fork

 $ xattr -w com.apple.ResourceFork "SDHAUEi7L2Jpbi9iYXNoU0iJ51BXSInmsDsPBQ==" file.txt

Step 3: Validate that the file hash hasn't changed

$ sha256sum file.txt
82d5419e8a3ec77a24e8ac8ac46480e76a712dd43d03aa6a5607a615a48b3b96  file.txt

This shows the file contents untouched. Hash unchanged.

Step 4: Recover the payload from the xattr

$ xattr -p com.apple.ResourceFork file.txt
SDHAUEi7L2Jpbi9iYXNoU0iJ51BXSInmsDsPBQ==

Why AV and EDR Don't Catch This

Vector	Detection?
File content scan	❌ No
File hash monitoring	❌ No
Quarantine check	❌ No
Behavior monitoring	❌ No
`getxattr()` syscall alerting	❌ No (unless custom ESF agent)

Unless an EDR has a policy or kernel extension that explicitly monitors extended attribute access, this technique is essentially invisible.

Offensive Use Cases

Use Case	Description
Signed .app payload	Hide payload in `Info.plist` or `icon.icns` without breaking code signing
Second-stage C2 staging	Shellcode fetched from xattr instead of disk or HTTP
Persistence triggers	Store loader config or triggers in `.DS_Store` or `Notes.txt`
Insider threat / exfiltration	Hide command-and-control triggers in business docs or PDFs

Defensive Considerations

Defenders can:

Monitor xattr -w, setxattr() on high-value files
Scan extended attributes for high-entropy Base64 or binary patterns
Audit with ls -l@ or xattr -l across sensitive folders

But today, no major macOS EDR detects or blocks this behavior.

Final Thoughts

macOS extended attributes are an underutilized attack surface. By hiding shellcode in com.apple.ResourceFork, red teamers gain a stealthy, native staging mechanism that:

Doesn't change file contents
Doesn't alter hashes
Doesn't trigger traditional IOCs
Requires no custom tooling

It's not a vulnerability. It's not even a bug. It's just weaponized metadata.

xattr'd and dangerous, indeed.