Apple’s Rosetta 2 Exploited for Bypassing macOS Security Protections

Hackers have been exploiting a significant security loophole in Apple’s Rosetta 2—the translation technology that allows Intel-based apps to run on Apple Silicon.

According to Google’s Mandiant researchers, North Korean hacking groups are deliberately using x86-64 (Intel) malware instead of native ARM64 (Apple Silicon) versions because it bypasses stricter security measures enforced on ARM64 apps. This technique enables attackers to execute unsigned or self-signed malware with fewer restrictions on macOS.

Intel-based malware on Apple Silicon

Apple introduced Rosetta 2 with macOS Big Sur in 2020 to ease the transition from Intel processors to Apple Silicon. When an Intel-based binary is launched on an Apple Silicon Mac, Rosetta 2 translates it into an Ahead-of-Time (AOT) cached file that the system can execute. This process ensures older applications continue to work, but it also creates a security blind spot.

MacOS enforces stricter security checks on ARM64 binaries—including code-signing requirements and execution policies. However, x86-64 binaries running under Rosetta 2 do not face the same restrictions, making them an attractive alternative for hackers. Key advantages include:

• Weaker execution policies – ARM64 apps require strict notarization and code-signing, while x86-64 apps can execute more freely.
• Evasion of security tools – Many macOS security solutions focus on native ARM64 threats, overlooking Intel-based malware running through Rosetta 2.
• Persistence and stealth – Attackers can delete malware after execution, but Rosetta 2’s cached AOT files remain, leaving behind forensic evidence.

Exploiting Rosetta 2 for crypto heists

Mandiant identified a x86-64 variant of the POOLRAT macOS backdoor in an attack on cryptocurrency organizations. The attackers executed universal system commands (ping, chmod, sudo, id) through Rosetta 2, bypassing stricter ARM64 security checks. Even after deleting their malware, forensic investigators were able to recover traces of the attack from Rosetta 2’s cache.

In another case, a Python 2 script was used as an initial infection method. Since Python 2 has no ARM64 version on macOS, it executed under Rosetta 2, ensuring that the x86-64 version of the attacker’s malware ran unchallenged.

The Rosetta 2 cache, located in /var/db/oah//, stores translated versions of x86-64 binaries. While Apple’s System Integrity Protection (SIP) prevents users from directly modifying these files, attackers don’t need to alter them—they simply leverage Rosetta 2’s weaker security policies to execute x86-64 malware without resistance.

Furthermore, if SIP is disabled, attackers could exploit AOT file poisoning, modifying Rosetta 2’s cached binaries to include malicious payloads. Although Mandiant has not observed this technique in the wild, it remains a potential risk.

Security recommendations

To mitigate the risks posed by Rosetta 2 exploitation, macOS users and security teams should:

• Restrict execution of x86-64 binaries – Where possible, enforce policies that prioritize native ARM64 applications.
• Monitor for Rosetta 2 artifacts – Regularly review /var/db/oah/ for unusual cache files, as they may indicate past malware execution.
• Analyze Unified Logs and FSEvents – These macOS logging mechanisms can reveal historical evidence of x86-64 binary execution, even if attackers delete their malware.
• Ensure System Integrity Protection (SIP) remains enabled – Disabling SIP exposes the system to AOT file poisoning attacks.
• Use security solutions that detect x86-64 malware – Many macOS security tools focus on ARM64 threats, leaving Intel-based malware undetected.