Can Your App Survive Coruna and DarkSword iOS Exploits?

Everyone is a target, no one is too small

Advanced hacking methods once reserved for targeting heads of state are now being deployed against ordinary users. The primary objective has shifted from quiet surveillance to mass-scale theft: harvesting user credentials, sensitive data, and cryptographic keys.

A single visit to a compromised e-commerce site can now bypass the trusted security of iOS and inject malicious code directly into your app, steal app’s files and extract users’ passwords. If you assume the operating system is a "walled garden" that protects your app’s memory, the new exploits are a wake-up call.

In this article, we explore how developers can build resilience against exploit kits like Coruna and DarkSword.

The ‘Coruna’ exploit intercepts functions in your app

On March 3, 2026, the Google Threat Intelligence Group (GTIG) exposed Coruna, a 23-exploit kit targeting iOS versions up to 17.2.1.

The infection triggers silently when a user visits a malicious website. From there, the malware escalates privileges by disarming security controls like the Sandbox and PAC (Pointer Authentication Codes).

While it primarily targets crypto wallets, Coruna can compromise any app by "hooking" sensitive functions to intercept passwords, tokens and seed phrases in real-time.

Two weeks after Coruna, Google reported DarkSword, which infects iOS versions 18.4 through 18.7 via malicious websites. Like Coruna, it escapes the WebKit sandbox to gain root privileges. To steal user data, it hooks system daemons to extract Keychain items and scans directories such as:

• /private/var/mobile/Containers/Shared/AppGroup: Used for data sharing between apps and extensions.
• /private/var/mobile/Containers/Data/Application: The primary sandbox where an app’s private files and databases reside.

While an exploit can access various system locations, in this article we will focus on these specific paths because it’s where your application's data lives.

Coruna targeted apps didn’t detect hooking

We tested 17 crypto wallet apps targeted by Coruna to understand the current state of their defensive response when facing a compromised environment. We set up a test device with the Roothide v2.4.5.21 jailbreak and SSLKillSwitch to see if these apps could detect common hooking and code injection techniques. This setup hooks sensitive SSL functions to bypass certificate verification and allow Man In The Middle (MITM) attacks.

The results were unanimous: Every app we tested failed to identify that sensitive functions had been hooked. Appendix A contains more detailed information about the experiment.

While detecting code injection and hooks is essential for defending against exploit kit tampering, it is only one piece of the puzzle. Below you can find a roadmap for building resistance to modern threats.

Detect hooks & trigger backend response

Hooking a function leaves a trace. Depending on the technique used, there are several ways to detect these modifications. While attackers will attempt to hook your anti-hooking checks to disarm them, a multi-layered detection strategy creates a significant barrier.

By reporting these detection events to your server, you gain an early warning of preparation for an attack campaign. This intelligence allows you to trigger automated responses. Examples include revoking session tokens or flagging high-risk transactions while the attacker is still mapping your app's logic. Identifying which specific functions are being targeted helps you prioritize hardening efforts where your data is most exposed.

Always encrypt user data

Data stored unencrypted on disk is a "low-hanging fruit" for attackers. Once a platform's security is breached, an exploit can typically access any file within an app container. Accessing files-at-rest is significantly easier than modifying code at runtime; the former often only requires a sandbox escape, whereas the latter requires bypassing advanced mitigations like PAC (Pointer Authentication Code) or PPL (Page Protection Layer).

Leverage the system Keychain

Instead of storing sensitive data in flat files, use the system Keychain. An attacker cannot simply "read" the Keychain file; they must hook system daemons to dump items, which significantly raises the bar for an exploit.

Enhance this further by requiring biometric authentication. This ensures that items are only decrypted by the TEE (Trusted Execution Environment) after a successful user verification

Move from passwords and tokens to device binding

While the Keychain provides secure storage, it cannot protect data the moment it is loaded into the application's memory. An attacker can hook the system functions used to fetch these items, intercepting a bearer token or password as it is released from the Keychain. Once exfiltrated, this data allows the attacker to perform a session hijacking attack from any location, indefinitely.

To eliminate this risk, replace static tokens with asymmetric cryptography. Instead of fetching a secret, you generate a private key directly within the Trusted Execution Environment (TEE). Because the TEE handles the signing process internally, the private key is never loaded into the application's RAM or passed through vulnerable function arguments.

This architecture ensures the key never leaves the hardware. An attacker cannot steal the key; they are instead forced to maintain a "live" presence on the breached device to request signatures in real-time

This strategy forces the attacker into a volatile position. Most modern mobile exploits lack persistence (the ability to survive a reboot). When a device restarts, the RAM is wiped and the OS loads a fresh, verified copy from read-only storage. By using hardware-bound TEE keys, you ensure that as soon as the attacker loses their runtime hook, they lose access to your account entirely.

You can read more about this strategy at our Device Binding article.

Don’t rely only on system functions for sensitive operations

Most apps use the same built-in iOS functions to handle passwords, encryption, and web requests. For an attacker, this is a massive advantage.

• One key opens many doors: An attacker only needs to learn how to "hook" one standard system function (like the one that reads the Keychain) to steal data from thousands of different apps. They don't need to study your specific app to break it.
• Predictability: Standard functions are public and well-documented. An attacker knows exactly what data goes in and what comes out. This makes it easy for them to write a script that "sniffs" your sensitive information as it passes through these functions
• Pre-encryption: Whenever you must pass a secret to a public API or a standard storage system, consider encrypting it first. By performing encryption within your own app’s logic before it reaches a system function, you ensure that even a successful "hook" only yields encrypted data that remains unusable to the attacker.

Verify SSL certificates yourself

By default, mobile operating systems handle SSL verification using a built-in list of trusted Root Certificates. However, this creates a single point of failure. If an attacker gains control of the device, they can install a malicious certificate into the system’s trust store, allowing them to intercept and decrypt your encrypted traffic (a Man-In-The-Middle attack).

Hardcode trusted certificates: Instead of trusting the entire system store, configure your app to only trust specific, pre-defined certificates or public keys belonging to your server

Obfuscate your app

The more complex your code is to analyze, the more difficult it becomes for an attacker to map your logic. By significantly increasing the effort required for reverse-engineering, you create a barrier that forces most hackers to abandon the attempt in favor of simpler targets.

Rotate versions frequently

By relocating sensitive functions and randomizing detection placement in every release, you ensure that malicious hooks designed for one version of your app will fail against the next. This constant structural change forces attackers to restart their reverse-engineering process from scratch with every update, drastically shortening their window of opportunity.

Introduce multilayered hardening

One check is never enough. You should combine different methods like anti-tampering and integrity checks so that even if an attacker peels back one layer, they immediately run into another obstacle. This gives you more opportunities to detect the attack early and alert your backend.

Summary

The Coruna exploit marks a chilling shift where high-end nation-state-level attacks are now being deployed against ordinary users. While crypto wallets were the primary target this time, there is no reason banking or e-commerce apps won't be next.

The most important takeaway for developers is the need to stay proactive. By combining robust architecture with obfuscation, you ensure that targeting your app becomes significantly more expensive. This strategy forces attackers to expend fresh effort to re-analyze and adapt their tools to each new version you release. Ultimately, this "moving target" approach transforms security into a proactive race, making your application an exhausting and unprofitable target for cybercriminals.

Appendix A

Footnote: ¹ Apple does not disclose exact download figures; Google Play data is used as a market benchmark.