On March 3, 2026, Google Threat Intelligence Group published its analysis of Coruna, an iOS exploit kit. This kit was a full framework with five complete exploit chains and 23 individual exploits, covering every iOS version from 13.0 to 17.2.1. The delivery was zero-click: a user opened a web page in Safari, and the attack began before anything even appeared on screen, but only if the device matched.
Yes, here is the trick that helped Coruna stay out of sight for years: before it delivers anything, it fingerprints the visitor and decides whether that visitor is worth exploiting, and visitors who fail the check get something harmless instead. That is the same filtering logic that ad cloaking uses to separate moderation systems from real users, running with the goal inverted.
Inside the Coruna Exploit Kit
Coruna works like a construction set, or a modular framework, as GTIG describes it. The set contains separate pieces that share a common set of utilities, and the kit’s own loaders hold them together. Each iOS band gets a matched exploit and bypass: one bypass for iOS 13 through 14.x, another for 15 through 16.2, and three more covering the 16.3 to 17.2.1 range.
What Is Actually Inside the Coruna Kit
Five stages, 23 interchangeable parts. The kit reads the iOS version first, then assembles the one combination that fits it.
Scroll sideways to see all five stages.
Several of the vulnerabilities are named and public. The Hacker News lists the CVE mapping in full, including CVE-2024-23222, a WebKit type confusion bug that had been exploited as a zero-day before Apple patched it in iOS 17.3 on January 22, 2024. Others go back further, to CVE-2021-30952 and a pair of 2020 kernel issues.
The final payloads are packed in a format built specifically for this kit. Each one is encrypted under its own key, compressed, wrapped in a custom container, and tagged with metadata stating which chips and iOS builds it supports. One detail matters for anyone watching traffic: these files arrive from addresses ending in .min.js, exactly like the ordinary scripts every site loads, so nothing about the request looks out of place.
How the Kit Decides Who Gets Exploited
Coruna does not fire at everyone who loads the page. First, it runs a JavaScript fingerprinting module and answers three questions: is this a real device, which iPhone model is it, and which iOS version is running.
Only after that, the framework loads the exploit pair that matches, and there are three reasons for such a flow:
- Reason 1: Plain engineering. Every exploit is written for a narrow band of iOS builds. If a chain fires blindly the wrong one, nothing happens, or Safari crashes. Besides ruining the overall flow, it makes the attack easier to detect, as a victim will notice and might report the browser crash.
- Reason 2: The hardware matters, too. The two sandbox escapes are split by hardware generation, one for A12 and older, one for A13 through A16, and every packed payload carries a note saying which chips it runs on. Reading the model wrong wastes the visit as surely as reading the version wrong does.
- Reason 3: Self-preservation. The kit fails when the device is in Lockdown Mode or when the session is in private browsing, because such a visitor is more likely to be a researcher, a sandbox, or a scanner. Delivering a working chain to any of them might cost the whole campaign, because the chain gets taken apart and patched.
From a Few Targets to Anyone Who Lands
GTIG first captured a Coruna chain in February 2025, in a narrowly targeted attack on a handful of devices. By that summer, the same framework turned up on compromised websites, used by a group GTIG tracks as UNC6353 against a limited set of targets. By December 2025 the kit was in the hands of UNC6691, a financially motivated group, and the targeting discipline was gone. SecurityWeek’s write-up describes the shift plainly: fake exchange sites, hidden iframes, exploit delivery to any iOS visitor regardless of location.
The end payload matched the new motive. GTIG describes an implant that injects into a root-level system daemon, targets 18 wallet and financial applications, decodes QR codes found in images, and searches Apple Memos for recovery seed phrases. A tool built for a few selected devices had become a theft pipeline with a wide funnel.
Quick fact: Coruna did not appear from nowhere. Two of its exploits target the same vulnerabilities used as zero-days in Operation Triangulation, the 2023 campaign Kaspersky uncovered while monitoring its own corporate Wi-Fi network and which relied on an undocumented hardware feature in Apple chips. Three weeks later, Kaspersky compared the code itself and concluded that Coruna’s kernel exploit for those two bugs is an updated build of the Triangulation one, and that the kit is an updated version of the same framework.
Set against the dates the vulnerabilities were open, the handover sequence below is the part that generalizes past this one kit.
From a Few Chosen Targets to Anyone Who Lands
Ten months, three sets of hands. This is the usual path an expensive attack tool takes.
Scroll sideways to see all four steps.
What Apple Patched, and What It Left Exposed
Most of the bugs the kit relied on were fixed in 2020 – 2024, on the normal update track. A phone on a current version of iOS was never in range of the chains in the report – the kit doesn’t work on versions higher than 17.2.1.
Then, on March 11, 2026, Apple did something less routine. It shipped iOS and iPadOS 15.8.7 for hardware that cannot run anything newer, backporting three of the fixes — CVE-2023-41974 in the kernel, CVE-2024-23222 and CVE-2023-43000 in WebKit — to iOS 15.8.7, with a fourth, CVE-2023-43010, shipped the same day in iOS 16.7.15 for a newer set of devices. The device list reads like an archaeology report: iPhone 6s, iPhone 7, the first iPhone SE, iPad Air 2, iPad mini 4, and the seventh-generation iPod touch.
However, a patch only helps a phone that actually installs it, but many never do. If someone has been on iOS 16.2 for three years, nothing has changed for them. Besides, Apple sent four fixes across two legacy branches not the whole set, and, finally, a phone that was already broken into stays broken into.
The Same Signals, Different Jobs: Why Coruna Case Matters for Advertisers
Coruna did not invent this. Reading a visitor’s device to work out who they are is an old technique called fingerprinting, and serving different content depending on the answer is what advertising calls cloaking. Both are long-standing practices, and the second one is what ADEX deals with in campaign traffic every day.
Note: Fingerprinting on its own is neutral. Anti-fraud systems and ordinary analytics run the same checks, so finding them on a page proves nothing. What matters is what the page does with the answer, and a cloaked page shows two visitors two different pages.
What the ADEX Team Saw on the Advertising Side
Around 50 accounts were identified as the source of campaigns with the same pattern, and the findings were passed to the client for review and action on those accounts.
The advertisers behind them usually traced back to Asian origin, and the campaigns were not limited to one region: affected GEOs included Europe, India, and other markets. Here are a few of the landing pages behind these campaigns. They have no theme in common, which is exactly why they read as unrelated advertisers at first glance:
Here is what researchers recorded on page load:
- The landing page loads with a hidden iframe. Nothing on the visible page gives it away.
The iframe checks the device. In this case, the check was a simple one: the OS version.
A delivery orchestrator loads next. It filters out bots and crawlers, then picks the malicious script written for that specific version of iOS.
4. The device’s IP is checked and passed on, and the script matching that iOS version is delivered.
The two JavaScript files from that chain, the orchestrator itself and the script it delivers, are both public on VirusTotal.
The delivery orchestrator as seen on VirusTotal. This is the script that decides who gets what: it filters out crawlers and picks the build matching the visitor’s iOS version:
The script that is actually delivered once the orchestrator decides the visitor qualifies:
What stands out is that the advertisers did not try to hide the violation behind a single landing page or a single category: the landing pages in these campaigns looked nothing alike. For example, one page could copy a Social offer, the next was a serious-looking finance page, while the formats and verticals kept changing, too.
As a result, these campaigns appear in review as several unrelated advertisers, but in most cases they belong to a single operator. The reason is a difference in cost: the cloaking setup, the redirect chain, and the hidden scripts take weeks to build, while a landing page can be produced in a day. Therefore, the setup is reused, with a new theme placed on top each time, and a page that never looks the same twice gives moderation no pattern to learn.
The more useful outcome came afterwards: the analysis of these campaigns gave us a set of metrics that flags the same pattern during moderation, before a campaign goes live and reaches any traffic.
What This Changes for Traffic Quality Teams
Nothing here demands a new detection product, but it argues for a few adjustments in how existing checks are run:
- Scan more than once, and from more than one profile. A single visit from a consistent crawler profile is exactly the input the filtering layer is built to recognize. Varying fingerprints and revisiting after approval is what catches the switch.
- Treat a clean result from an unusual client as low-confidence. If your scanner runs from a data-center range with a hardened configuration, a clean result is weak evidence. Record it as inconclusive rather than passed.
- Cluster by delivery, not by creative. Redirect chain shape, iframe behavior, script hashes, and hosting patterns survive a creative refresh, but vertical labels do not.
- Watch for iframe injection on approved destinations. The Coruna campaigns did not need the landing page to look malicious. A hidden iframe on an otherwise ordinary page carried the whole delivery.
- Keep legacy device traffic in view. Old iOS builds in your traffic matter beyond monetization. That segment stays exploitable longest after a disclosure, as the March backport to devices released between 2014 and 2019 shows.
FAQ
Is the Coruna exploit kit still a threat on current iPhones?
Not through the documented chains. The chains cover iOS 13.0 through 17.2.1, and the underlying vulnerabilities were patched on the mainline update track in 2023 and 2024. The remaining exposure sits with devices that never received those updates, which is why Apple backported four of the fixes to iOS 15.8.7 in March 2026.
How was Coruna delivered to victims?
Through web pages, with no user interaction beyond opening the page. GTIG describes hidden iframes on compromised sites and on attacker-built fake exchange sites, loading a JavaScript framework that fingerprinted the visitor before any exploit was sent.
Why does an exploit kit care whether a device is in Lockdown Mode?
Because a hardened or unusual device is more likely to belong to a researcher, a sandbox, or a scanner, and delivering a working chain to one of those means losing it. Bailing out preserves the exploit. The same reasoning explains the private browsing check.
What does an iOS exploit kit have to do with ad fraud?
The visitor-classification layer is shared. Deciding which visitor is real and which is an automated reviewer is the same problem cloaked campaigns solve, using the same signals. The techniques transfer across use cases even when the operators do not.
Can a buyer or a publisher detect this in their own traffic?
Partially, by delivery behavior: unexpected iframes on approved destinations, redirect chains that change after approval, and pages that respond differently to two visitors with different device profiles. Confirming what an exploit chain actually did on an end-user device is not something a buyer or publisher can do from campaign data.
Wrapping Up
The strongest argument in the Coruna disclosure reaches well past iOS. A filtering layer built to protect an exploit and a filtering layer built to hide a scam landing page are the same piece of engineering, reused by operators with different goals, and that layer is where both are easiest to catch.
So the first question for a review process is whether the malicious page ever shows itself at all, and recognizing it comes second. If your scanner presents one profile, visits once, and reports clean, you have learned what the delivery layer wanted you to learn. Change the profile, come back later, and compare what two different visitors were shown. The difference between those two responses is the finding.