Coruna's 5-Chain Arsenal: Assessing the Impact of Google's iOS Findings
Hey everyone,
Google Threat Intelligence Group (GTIG) just released a write-up on a new and surprisingly powerful exploit kit called Coruna (also tracked as CryptoWaters). The scale of this is pretty terrifying—23 distinct exploits organized into five complete exploit chains.
The kit specifically targets iOS versions 13.0 through 17.2.1. While Google notes it's ineffective against the very latest iOS release, it represents a significant capability for operators targeting outdated devices. We often talk about "patch Tuesday," but this highlights the danger of the long tail of mobile devices that never get updated.
From a defensive standpoint, if you aren't strictly enforcing version compliance, now is the time. If you are ingesting MDM logs into a SIEM like Sentinel or Splunk, you should be hunting for devices falling into that vulnerable range.
Here is a basic KQL query to start flagging these potentially vulnerable endpoints:
DeviceInfo
| where OSPlatform == "iOS"
| where OSVersion >= "13.0" and OSVersion <= "17.2.1"
| project DeviceName, OSVersion, LastSeen
| order by OSVersion asc
Given that 23 exploits were bundled into a single kit, do you think this represents a shift toward commoditized iOS exploitation, or is this still indicative of high-resource, state-sponsored targeting? How are you handling legacy iOS versions in your environments?
The commoditization aspect is what worries me most. We usually see these kinds of multi-chain exploits (like the ones used in Operation Triangulation) attributed to high-level threat actors. If Coruna is being sold or traded more freely, we're going to see a spike in mercenary spyware usage against lower-value targets.
On the detection side, strictly blocking versions < 17.2.1 is the only real control we have, since the chains likely bypass standard sandboxing. Has anyone seen specific IoCs for the initial delivery vector? I'm assuming malicious profiles or phishing sites.
It's a nightmare for MSPs managing legacy hardware. A lot of our clients are still running older iPads and iPhones because their line-of-business apps aren't compatible with newer iOS versions. They refuse to upgrade the hardware, so they stay vulnerable.
I've started pushing configuration profiles that disable Safari's JIT engine on older devices as a temporary mitigation, though it breaks functionality on some sites. It's a trade-off, but better than getting owned by a kernel exploit.
The persistence mechanisms in these kits are often more revealing than the entry point. If you have MDM logs, look for anomalies in standard daemon processes like locationd, which are frequently hijacked for persistence.
Here's a KQL query to hunt for suspicious child processes:
DeviceProcessEvents
| where InitiatingProcessFileName in ("locationd", "mediaserverd")
| where ProcessFileName !in ("lsd", "logd", "kernel_task")
This usually catches the payload staging stage even if the initial exploit goes unnoticed.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access