Resource forks are an old macOS way to attach structured data to a file: icons, menu definitions, dialog boxes, even code. MITRE tracks their abuse as T1564.009, Resource Forking, under the stealth tactic. It applies to macOS only.
Apple has deprecated resource forks in favor of the application bundle structure, which is part of why a fork on a modern file deserves a second look.
How attackers use it
MITRE describes two ideas. First, an adversary can hide malicious data in a resource fork that would otherwise sit directly in the file, so tools that only read the main content miss it. Second, content in the fork can be executed at a specified offset after it is moved to an executable location and invoked. The fork content may also be obfuscated or encrypted until the moment it runs.
How to detect it
You can see a fork by listing a file's extended attributes. MITRE names ls -l@ and xattr -l for this.
The detection guidance is to watch for files with com.apple.ResourceFork extended attributes that hold unusually large or non-standard data. The signal is strongest when the fork shows up in a place where forks are uncommon and is then paired with process execution or network activity.
How to reduce the risk
MITRE lists one mitigation, aimed at developers: configure applications to use the application bundle structure, with non-localized resources at the top level and localized ones in the /Resources folder. If your own software follows the bundle layout, any resource fork on your files becomes an anomaly instead of background noise.
Quick check
Which commands reveal a resource fork on a macOS file?
ls -l@ and xattr -l both display extended attributes, and a resource fork appears as com.apple.ResourceFork.
Why is a large resource fork on a modern file suspicious?
Resource forks are deprecated in favor of the bundle structure, so a fork carrying large or odd data in an uncommon place is out of pattern.
