pegasus

Most engineers still think of spyware as something you can avoid by not clicking suspicious links. Pegasus rewrote that rule entirely - a zero-click, zero-interaction implant that exploited the very core of modern mobile operating systems to turn any iPhone or Android device into a surveillance tool. For years, the NSO Group's flagship product remained a ghost in the machine, leaving no obvious forensic footprint. But from a software engineering perspective, Pegasus isn't magic - it's a collection of meticulously engineered exploit chains, kernel-level memory corruption bugs, and a distributed command-and-control platform that rivals the sophistication of state-sponsored espionage tooling. Understanding its inner workings reveals uncomfortable truths about platform security models - code signing. And the limits of static analysis.

Our team at Denver Mobile App Developer has spent countless hours dissecting the technical playbooks behind surveillanceware like Pegasus - not to replicate them. But to build defenses. In production environments, we've seen how the same vulnerability classes exploited by Pegasus (use-after-free, integer overflows in image decoders, logic errors in IPC mechanisms) still slip into everyday enterprise apps. This article takes a hard look at Pegasus through an engineering lens: the attack vectors, the forensic traces, the detection tooling like Mobile Verification Toolkit (MVT). And the evolving architecture countermeasures from Apple and Google. We'll connect each observation back to practical secure development practices. Because unless you understand the adversary's weapon, you can't harden your own systems against copycat exploits.

I'll dissect the technology piece by piece, leaning on documented CVEs, Amnesty International's forensic methodology. And firsthand experience with iOS security internals. No hand-waving - just bits, bytes, and binary protocols.

The Zero-Click Attack Vector: Engineering a Stealth Delivery System

Traditional malware relies on social engineering - an email attachment, a compromised website, a phishing link. Pegasus, however, achieved something far more dangerous: remote, zero-click compromise via commonly used messaging and calling apps. The most infamous case involved iMessage, where the target didn't need to tap anything. An attacker simply sent a maliciously crafted message - in early iterations, a fake GIF - and the device was compromised before any notification appeared. This wasn't a flaw in the user's behavior; it was a flaw in how the operating system processed untrusted data before authentication or user interaction.

From an engineering standpoint, the zero-click attack surface is terrifying because it bypasses every user-facing security control. In iOS, the attack exploited the way iMessage's data detectors handled content embedded in messages. The processing pipeline included automatic rendering of images, PDF previews. And GIF animations - all inside a privileged `imagent` process. Pegasus took advantage of a sequence of bugs, later collectively tracked as CVE-2021-30860 (FORCEDENTRY), to achieve arbitrary code execution. By abusing a CoreGraphics integer overflow and a JBIG2 decoder compression logic error, the payload slipped past memory protections and gained native execution. The target simply received an iMessage; the rest happened silently.

For mobile developers, this highlights a critical design principle: any data parsing that occurs automatically - even for previews - must be sandboxed with minimal privilege. Apple later introduced BlastDoor, a sandbox service specifically to isolate untrusted input processing in iMessage. Yet the fact that it took a multi-billion-dollar spyware industry to force this architectural change shows how often platform vendors treat convenience features as primary design goals without considering the blast radius. In our own app threat modeling sessions, we now systematically ask: "Does this feature process any external content before the user's explicit interaction? " If yes, we implement strong filters and consider a separate, jailed process,

How Pegasus Exploits Mobile Operating System Kernels

Getting code execution inside a messenger process is just the first stage. Modern operating systems segment processes with strict access controls - an attacker still needs to escape the sandbox and gain kernel-level privileges to implant persistent spyware. Pegasus achieved this through a series of privilege escalation exploits, chaining vulnerabilities in the kernel and in system services. Once inside `imagent`, the payload used a kernel information leak to defeat address space layout randomization (ASLR), then exploited a logic bug in the IOKit or XNU kernel to map writeable pages into kernel memory, finally installing a custom kernel extension that provided root access and stealth capabilities.

The technical elegance (from an adversarial perspective) is chilling. The exploits were deployed dynamically - the spyware infrastructure probed the target device's OS version and then delivered a tailored chain of vulnerabilities known to work on that exact build. This required a massive catalog of zero-day exploits maintained by NSO, updated as Apple and Google patched older bugs. The chain would first fingerprint the device, report back to C2. And only then receive the appropriate escalation payload. This dynamic adaptation is what made Pegasus so elusive; every infection was customized, making signature-based detection nearly impossible.

As an engineer, I can't help but study the modularity of the exploit chain. It resembles a microservices architecture for exploitation - each component (initial compromise, sandbox escape, kernel exploitation, persistence) is decoupled and can be swapped out depending on the target. This modularity allowed NSO to keep the overall tool functioning even when individual CVE entries were patched. For defenders, the lesson is that relying on patch management alone is insufficient; behavioral detection that monitors for anomalous kernel memory writes or suspicious Mach message patterns is essential. In our mobile security assessments, we've started instrumenting apps with runtime integrity checks that compare process memory maps against known-good baselines, a technique inspired directly by studying Pegasus's kernel manipulation vectors.

Analyzing the Chain: From iMessage to ForcedEntry

The specific exploit chain that put Pegasus into global headlines was dubbed FORCEDENTRY. It targeted the way iOS rendered PDF files Using the CoreGraphics library's JBIG2 image decoder. Researchers at Google's Project Zero later published a detailed analysis showing that the bug lay in a compression algorithm's handling of segment header arithmetic, allowing an overly large buffer to be allocated, leading to out-of-bounds writes. The PDF was constructed so that a fake "content" stream referenced offsets that pointed into memory containing attacker-controlled data, eventually hijacking the decoder's function pointer.

What's remarkable from an engineering standpoint is how this exploit avoided typical crash defenses. It didn't corrupt memory enough to trigger a panic; instead, it surgically overwrote a single pointer in a way that the system believed was a legitimate decoder callback. The payload then performed a stack pivot into attacker-controlled memory and chained into a ROP/JOP sequence to call `mprotect` and make the injected code executable. The entire payload existed within the PDF file - no external files dropped, no network call required at that stage. The zero-click nature meant that the PDF was automatically rendered when iMessage attempted to generate a thumbnail or quick preview.

Forensic analysis later found that Pegasus removed the iMessage that delivered the exploit shortly after compromise, often by abusing the now-available root access to delete the chat record directly from the SQLite database. This self-cleaning behavior is common in advanced spyware and a reminder that logging from within the compromised process is unreliable. To catch such exploitation attempts, you need external monitoring - either via a separate secure enclave or by analyzing periodic backups with tools like MVT. Apple's later introduction of Lockdown Mode explicitly disables automatic preview rendering for most attachment types, directly breaking the FORCEDENTRY attack surface.

The Role of Code Signing and Platform Trust Subversion

Modern iOS and Android enforce strict code signing. All executable pages must be signed by a trusted certificate. So how did Pegasus run arbitrary native code? It didn't defeat code signing directly; instead, it leveraged the fact that once you have kernel-level access, you can bypass mandatory code signing (AMFI on iOS) by manipulating kernel variables or loading a patched kernel extension. In many variants, Pegasus loaded a dynamic library (. dylib) into a system process that already had legitimate Apple code signatures and used `dlopen`-style injection via the mach-o loader. Since the system process had valid signing, the presence of foreign code in its address space didn't trigger a signing check at runtime for the whole process - the kernel's code signing integrity was checked at process creation, not for every page after that.

Furthermore, Pegasus employed a technique called "process injection" into services like `mediaserverd` or `identityservicesd`, both of which have wide entitlements. By hijacking an already-signed process, the spyware inherited capabilities like access to the microphone, camera, and contacts - all without triggering a new code signature verification. This subversion of the platform's trust model is a hard lesson: code signing alone doesn't protect against runtime compromise of a trusted binary. Defenders must complement code signing with runtime code integrity checks, such as Apple's AMFI checks for modified pages. But even those can be disabled by a kernel-resident rootkit.

In our work securing high-profile enterprise apps, we've integrated anti-tampering that periodically verifies the integrity of the app's own code sections using checksums that are compared remotely. While not bulletproof against kernel-level attacks, it raises the bar against userland injection techniques derived from Pegasus's playbook. We also recommend to our clients that they avoid linking unnecessary frameworks that increase the attack surface of their process; every linked dylib is a potential vector for code injection,

Command-and-Control Infrastructure: A Cloud-Native Spy Network

Pegasus isn't just an implant; it's an entire platform. The spyware communicates with a sophisticated command-and-control (C2) infrastructure hosted across cloud providers, using anonymized domain registrations, fast-flux DNS. And custom obfuscated protocols. Once the device is compromised, the implant establishes a persistent connection to the C2 via HTTPS or a custom binary protocol tunneled over common services like Google's Firebase Cloud Messaging (FCM) or Apple Push Notification Service (APNS). This choice is genius: traffic to push notification services is rarely blocked by firewalls and looks like normal app activity.

The C2 infrastructure also implements role-based access control for NSO's clients - government agencies. An operator logs into a web portal, selects a target phone number, and initiates the infection. The portal then communicates with a deployment server that selects the appropriate exploit chain based on the target's OS version, detected via methods that don't require interaction (leaking information from push tokens or SIP headers). This engineering mirrors a modern CI/CD pipeline: exploits are built, tested. And deployed automatically. The entire system is designed for scalability, allowing multiple campaigns to run concurrently.

For cloud security engineers, the Pegasus C2 topology is a case study in stealth. The operators used AWS, DigitalOcean. And other cloud providers, spinning up and tearing down infrastructure rapidly. Some domains even mimicked legitimate news websites to blend HTTPS certificate transparency logs with normal-looking entries. Detecting such C2 requires network-level anomaly detection that goes beyond simple domain reputation, correlating beacon timing and push notification patterns. In our own infrastructure monitoring, we've implemented ML models that flag client devices sending unusual volumes of outbound push acknowledgments at odd intervals, a direct adaptation of detection techniques derived from analyzing Pegasus's network behavior.

Data Exfiltration: Tunneling Through Encrypted Channels

Once Pegasus gains kernel-level access, its data collection capabilities are extensive: it can access end-to-end encrypted messages before encryption, log keystrokes, record ambient audio, capture camera feeds. And exfiltrate files. The implant uses a custom data exfiltration module that compresses, chunks, and encrypts stolen data before transmitting it to the C2 over the same stealth channel used for commands. Frequently, it leverages platform background tasks like `NSURLSession` with discretionary mode, ensuring that data goes out only when the device is on Wi-Fi and charging, reducing the chance of battery drain or data usage anomalies that might alert the user.

What's technically interesting is how the spyware avoids local storage of large exfiltrated files. It streams data directly to the C2, never leaving a complete copy on disk. Forensic analysts often find only residual database entries in the compromised app's container or small log files that point to a missing directory. On iOS. Since filesystem encryption is tied to the user's passcode, Pegasus can read any file that the OS would normally decrypt on-the-fly for any process running as root. It then re-encrypts with its own keys before exfiltration, so even if network traffic is captured, it appears as opaque TLS 1. 3 traffic with perfect forward secrecy.

From a mobile app security perspective, this underscores the importance of encrypting sensitive data with an additional application-layer key that isn't derived solely from the device's keychain. If a root compromise occurs, any data stored using filesystem encryption is immediately accessible. We advocate for per-record encryption where keys are fetched from a secure backend only during an authenticated session and never stored locally beyond the session. This won't stop an active Pegasus session from capturing live data entry. But it protects historical data at rest from bulk exfiltration by a root-level implant.

Detecting Pegasus with Open-Source Forensics Tooling

While Pegasus is designed to leave minimal traces, forensic researchers have pieced