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]
| ID | Name | Description |
|---|---|---|
| S0276 | Keydnap |
Keydnap uses a resource fork to present a macOS JPEG or text file icon rather than the executable's icon assigned by the operating system.[6] |
| S0402 | OSX/Shlayer |
OSX/Shlayer has used a resource fork to hide a compressed binary file of itself from the terminal, Finder, and potentially evade traditional scanners.[5][4] |
| ID | Mitigation | Description |
|---|---|---|
| M1013 | Application Developer Guidance |
Configure applications to use the application bundle structure which leverages the |
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0584 | Detection Strategy for Resource Forking on macOS | AN1609 |
Unexpected creation or modification of files with |