Coruna iOS Kit: Recycling the 2023 Triangulation Kernel Exploit
Just caught the latest report from Kaspersky regarding the Coruna iOS exploit kit, and it’s a classic case of threat actors recycling successful code. It turns out the kernel exploit driving Coruna is essentially an updated version of the same exploit used in the Operation Triangulation campaign back in 2023.
When Coruna first popped up on our radar, the obfuscation made it hard to attribute, but deeper analysis confirmed the shared code lineage. This is significant because Triangulation was a powerhouse—it utilized a complex zero-day chain (often involving CVE-2023-32434 and similar hardware-level memory mapped I/O vulnerabilities) to achieve arbitrary code execution at the kernel level.
For those managing mobile fleets, this isn't just "another" iOS bug. It implies that exploit developers are maintaining and updating older, high-value exploits rather than burning new zero-days for every campaign. This lowers the barrier to entry for mass attacks.
If you are leveraging mobile threat defense (MTD) solutions, you should be hunting for anomalies typically associated with these chains, such as unusual process spawning or unexpected data exfiltration blobs over SSL. If you are forwarding proxy logs, you might look for specific User-Agent anomalies often seen in these C2 comms.
Here is a basic KQL query to hunt for suspicious high-volume connections from iOS devices that might align with C2 beaconing:
DeviceNetworkEvents
| where ActionType == "ConnectionAllowed"
| where OSPlatform == "iOS"
| where RemotePort in (443, 80)
| summarize SentBytes = sum(SentBytes), RecvBytes = sum(ReceivedBytes) by DeviceId, RemoteUrl
| where SentBytes > 5000000 or RecvBytes > 5000000
| order by SentBytes desc
Given that these exploit kits often leverage "zero-click" iMessage vectors, how are you guys handling the risk of iMessage in strictly regulated environments? Are you blocking it outright, or just relying on MDM/MTD telemetry?
We've actually started blocking iMessage at the network level for our high-value targets after the Triangulation fallout. It’s a heavy-handed approach and users hate it, but the risk of a zero-click kernel exploit is too high. We rely on Zimperium for MTD, but detection usually happens after the initial compromise. If you are dealing with threat actors sophisticated enough to reuse Triangulation code, you have to assume they have bypassed standard EDR/MDM signatures already.
It's interesting to see the code reuse. From an exploit dev perspective, if you have a reliable kernel read/write primitive, there's no need to burn a new CVE on a mass campaign. Porting the exploit to newer iOS versions is cheaper than developing a whole new chain. That said, this reinforces the need for rapid patching. Even if a device is 'old', if it's susceptible to the 2023 Triangulation variant, it's vulnerable to Coruna. Don't assume your BYOD fleet is safe just because they aren't on the latest beta.
That KQL query is a good start, but don't forget to correlate it with battery usage reports if you have an MDM like Jamf or Intune. These kernel exploits usually trigger aggressive thermal throttling or battery drain due to the lack of proper power management in the early stages of the exploit chain. If you see a device with anomalous network traffic and a battery drain spike, prioritize that device for forensics immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access