How Zero-Click Pegasus Attacks Work: A Technical Deep Dive Into the Exploit Chain
A zero-click exploit abuses a vulnerability in code that processes untrusted input automatically. This article walks through the anatomy of a Pegasus-style exploit chain as reconstructed from published technical analyses, for security engineers who need to understand the technique at the level of memory and control flow.
The Mechanics of a Zero-Click Exploit
A zero-click exploit is, at its core, a program that abuses a vulnerability in code that processes untrusted input automatically. On a modern smartphone, dozens of such parsers run continuously: iMessage decodes GIFs and PDFs, WhatsApp parses call-setup signaling, the push notification daemon processes incoming payloads. Each is a target. The attacker's job is to craft an input that, when parsed, causes the parser to execute attacker-controlled code.
This article walks through the anatomy of a zero-click Pegasus-style exploit chain as reconstructed from published technical analyses, primarily Citizen Lab's FORCEDENTRY report and Google Project Zero's accompanying write-up. It is intended for security engineers and researchers who want to understand the technique at the level of memory and control flow.
Stage One: Delivery
The first stage is getting the payload to the target device without requiring any user action. iMessage is ideal for this because every iPhone with an Apple ID registered for iMessage automatically receives and processes any message sent to that address. The sender does not need to be in the recipient's contacts. The device will parse the message and its attachments before the user sees anything.
In the FORCEDENTRY case, the delivery vehicle was a specially crafted PDF embedded in a GIF attachment within an iMessage. The exploit did not rely on the user tapping or opening anything. The mere act of the device receiving the message triggered the vulnerability.
Stage Two: The Parser Vulnerability
The core vulnerability in FORCEDENTRY was CVE-2021-30860, a logic flaw in Apple's CoreGraphics PDF image parser. This was not a memory-corruption bug in the traditional sense. It was a logic vulnerability in the JBIG2 stream decoder. JBIG2 is a compression format used in PDFs for bi-level images. The parser, when processing a maliciously crafted JBIG2 stream, could be manipulated into building an arbitrary read-write primitive by abusing the way the format represents segments of a page.
The key insight from Project Zero's analysis was that the JBIG2 parser was complex enough to be Turing-complete in its segment layout. The exploit used the JBIG2 segment structure itself as a virtual machine, assembling a primitive that could read and write arbitrary memory. This is a sophisticated technique that demonstrates the level of engineering behind commercial spyware.
Stage Three: Sandbox Escape
Even after achieving code execution within the iMessage process, the attacker is confined to the iMessage sandbox. The sandbox restricts what files and system resources the process can access. To reach the full device, the exploit needs a sandbox escape.
In the FORCEDENTRY chain, this was achieved through a second vulnerability, CVE-2021-30861, in the CoreMedia library. The first stage's code execution was used to trigger this second bug, which allowed the attacker to escape the iMessage sandbox and gain execution in a more privileged context.
Stage Four: Persistence and Privilege Escalation
Once out of the sandbox, the final stage is to establish persistence and gain kernel-level privileges. Pegasus historically used a kernel vulnerability to gain root. With root access, the implant can hide itself from forensic tools, disable security features, and maintain access across reboots.
Pegasus's persistence has been observed to be selective. In some cases, the implant self-destructs if it cannot reach its command-and-control server within a defined window, or if it detects forensic analysis tools. This self-destruct behavior is one reason why Pegasus infections are difficult to forensically recover.
The BlastDoor Mitigation
In iOS 14, Apple introduced BlastDoor, a sandboxed service that inspects and sanitizes incoming iMessage attachments before they reach the main iMessage process. BlastDoor parses untrusted content in an isolated environment, so even if a vulnerability is triggered, the attacker is confined to the BlastDoor sandbox rather than the main system.
BlastDoor significantly raised the cost of iMessage zero-click exploits. The BLASTPASS chain in 2023 demonstrated that the surface was not closed, but the engineering required increased. This is the intended effect of defense-in-depth: not to make exploitation impossible, but to make it expensive enough that only the most capable and well-funded operators can sustain it.
Why Zero-Click Is Hard to Defend Against
The fundamental difficulty is architectural. A smartphone that automatically processes rich content from anyone who knows your phone number is, by design, exposing a parser to untrusted input. Every parser is a potential vulnerability. You cannot simply disable all automatic processing without removing functionality that users expect. The defense is therefore a combination of sandboxing the parsers, reducing the attack surface for high-risk users through Lockdown Mode, and rapidly patching discovered vulnerabilities. None of these is a complete solution.
References
- Citizen Lab, FORCEDENTRY, August 2021.
- Google Project Zero, Ian Beer, FORCEDENTRY discussion, September 2021.
- Apple, BlastDoor and iOS security, iOS 14 release documentation, 2021.
- Citizen Lab, BLASTPASS, September 2023.
