Hackers Leveraging x86-64 Binaries on Apple Silicon to Deploy macOS Malware

Advanced threat actors increasingly leverage x86-64 binaries and Apple’s Rosetta 2 translation technology to bypass execution policies and deploy malware on Apple Silicon devices.

The technique exploits architectural differences between Intel and ARM64 processors while leaving behind forensic artifacts that investigators can use to reconstruct attacks.

Attackers Leveraging x86-64 Binaries on Apple Silicon

Apple’s Rosetta 2, introduced in macOS Big Sur (11.0) in 2020, translates x86-64 instructions to ARM64 through just-in-time (JIT) and ahead-of-time (AOT) compilation. 

When users launch an x86-64 binary on Apple Silicon, the system generates an AOT file stored at /var/db/oah/<UUID>/<Binary_UUID>/<binary_name>.aot. 

These cached translations create timestamped records of execution even if attackers delete original payloads.

Mandiant’s research reveals that state-sponsored groups, including those linked to the Democratic People’s Republic of Korea (DPRK), deliberately compile malware for x86-64 architectures to exploit Rosetta 2’s relaxed code signing requirements. 

Unlike ARM64 binaries, which require valid Apple-issued signatures or stringent notarization checks, x86-64 executables translated via Rosetta 2 face fewer restrictions, allowing attackers to deploy self-signed payloads.

Universal Binaries and Execution Chain Obfuscation

Attackers weaponize universal binaries containing both x86-64 and ARM64 code to maximize compatibility.

When launched via Rosetta 2, these executables default to their x86-64 slices, creating AOT artifacts even on modern Apple Silicon devices. 

In one DPRK-led cryptocurrency heist, Mandiant observed the POOLRAT backdoor executing system utilities like sudo, chmod, and cat through Rosetta 2, generating forensic trails in Unified Logs and FSEvents:

The attackers then deleted the original malware binary but overlooked AOT files protected by System Integrity Protection (SIP), which restricts access to /var/db/oah to the _oahd system account. 

These cached translations preserved critical evidence, including developer environment strings from unrecovered payloads.

Intrusion Detection Methodology

Mendiant’s methodology combines three artifact sources to detect intrusions:

• AOT File Metadata: Creation timestamps correlate with malware execution windows. Each AOT’s parent directory uses a SHA-256 hash derived from the original binary’s path, Mach-O header, and file system metadata.
• FSEvents: File system logs record directory creation and .in_progress file renaming operations, even after malware deletion.
• Unified Logs: With custom profiles, investigators can reveal otherwise redacted binary paths in oahd process logs.

Notably, AOT files retain symbols and partial code structure, enabling analysts to identify malicious functionality. 

However, they omit static data like embedded configurations or network indicators, limiting full reconstruction without the original binary.

Mitigations

To counter these threats, Mandiant recommends:

• Enabling SIP: Prevents tampering with Rosetta 2’s cache directory.
• Monitoring FSEvents: Alert on rapid .in_progress → .aot file transitions in /var/db/oah.
• Custom Unified Log Profiles: Unmask private fields in oahd logs using configuration profiles.
• AOT File Audits: Periodically compare SHA-256 hashes of cached AOT files against known-good Rosetta 2 translations to detect poisoning attempts.

As Apple phases out Intel support, the security community anticipates stricter ARM64 code signing requirements enforcement. 

However, Mandiant warns that x86-64 binaries will remain a viable attack vector for years due to lingering legacy software dependencies. 

Organizations must prioritize forensic artifact collection, particularly Rosetta 2’s AOT files, to identify and remediate macOS intrusions in an era of increasingly sophisticated cross-architecture attacks.

Collect Threat Intelligence on the Latest Malware and Phishing Attacks with ANY.RUN TI Lookup -> Try for free