Inside Coruna - Web Script IOS Exploit

The kit that changed hands three times in one year

In early 2025, a customer of an unnamed commercial surveillance vendor was observed using a previously unknown JavaScript exploit framework against iOS devices. By July 2025, a suspected Russian espionage group had picked up the same framework and was silently injecting it into Ukrainian industrial and retail websites as a hidden iframe. By December 2025, a financially motivated Chinese threat actor deployed it across a network of fake cryptocurrency and gambling sites with no geographic restrictions, targeting any iPhone user who clicked the wrong link. Think of it this way: the same powerful tool shifted from espionage to financial crime within months, adapting to different objectives and targets. For example, a Ukrainian energy company’s website was compromised to deliver espionage payloads, while later, a fake crypto exchange site tricked users worldwide into infection.

Google's Threat Intelligence Group (GTIG) publicly named this framework Coruna (also tracked as CryptoWaters) on March 4, 2026. It contains five complete iOS exploit chains and 23 individual exploits spanning iOS versions 13 through 17.2.1. iVerify called it "the first observed mass exploitation against iOS devices" and noted structural similarities to tools developed by U.S. government-affiliated threat actors. Here's why that matters: such structural similarities suggest the reuse or adaptation of sophisticated government-grade techniques in criminal hands, raising the stakes for defenders. In practice, this means attackers are no longer limited to basic exploits—they now wield advanced methods once reserved for nation-state operations.

We obtained live samples from active delivery domains and analysed every layer of the JavaScript. What follows is a detailed account of what this kit does, from the first line of obfuscated code to the encrypted Mach-O binary dropped on the victim's device, together with a full infrastructure analysis of the domains and IPs involved. This deep dive reveals not just the technical mechanics but also the operational footprint behind Coruna. For instance, we traced how the exploit’s JavaScript payload morphs dynamically during execution, evading detection while maintaining stability across iOS versions.

The delivery problem: why your website is the attack surface

Before diving into the exploit mechanics, it's worth clarifying what "delivery" means here, because many organisations haven't fully considered this aspect. Delivery is the method by which the exploit reaches the victim's device, often through a seemingly innocuous web page.

Coruna is delivered as a self-contained HTML file, typically named group.html or analytics.html, embedded as a hidden <iframe> within a web page. The iframe has zero dimensions, making it completely invisible. It requires no user interaction beyond the page loading. The exploit runs entirely in the browser, in JavaScript, and completes within seconds. Here's what that means in practice: a user could simply visit a compromised or malicious website, and without clicking anything, their device could be exploited silently. Imagine browsing your favorite news site and getting infected without any warning or interaction.

In the campaigns we analysed, the delivery pages were hosted on attacker-controlled domains: fake crypto platforms, gambling sites, bingo lures. But the kit does not care where it is hosted. It is a self-contained payload that can be injected anywhere a JavaScript tag can be placed. That means the realistic delivery vectors extend far beyond attacker-owned infrastructure.

Ad networks. A single malicious creative served through a programmatic ad network reaches every publisher running that network's tag. The publisher's server never touches the payload. The publisher's WAF never sees it. The publisher's security team has no visibility into what the ad tag loaded in the user's browser. If Coruna had been distributed through a mid-tier ad network, it would have reached millions of Safari users across thousands of legitimate, reputable websites simultaneously. None of those publishers would have known. For example, imagine an ad network serving a malicious banner on a popular news site, and every visitor could have been exposed without the site's knowledge.

Compromised third-party scripts. The average e-commerce or media site loads 30 to 50 third-party JavaScript tags: analytics, chat widgets, A/B testing tools, affiliate trackers, consent managers. Each of those scripts is a potential injection point. A supply chain compromise of any one of them, like the Magecart campaigns or the polyfill[.]io incident, could have turned every site using that script into a Coruna delivery node. Again, the origin server would show nothing unusual. The payload executes in the user's browser and reports back to a C2 domain the publisher has never heard of. Think of it this way: even a trusted script provider can become a Trojan horse if compromised. For instance, if a popular analytics provider's script was hijacked, thousands of websites could unwittingly deliver Coruna.

Cached CDN assets. Several of the delivery URLs we identified were served from shared CDN infrastructure (tubeluck[.]com, 668ddf[.]cc). An attacker with write access to a CDN origin bucket or the ability to poison a CDN cache achieves the same result. For instance, if an attacker manages to upload a malicious file to a CDN bucket used by multiple sites, they can silently deliver exploits to all those sites' visitors. This scenario played out in past attacks where attackers poisoned widely used CDN caches to spread malware rapidly.

The point is not that these specific vectors were used. The point is that nothing about the Coruna payload requires the attacker to own the delivery site. The payload is a JavaScript file. It goes wherever JavaScript goes. And JavaScript goes everywhere.

How it reaches the browser: delivery infrastructure

The campaigns we analysed used more than 50 delivery domains, organised into recognisable lure themes.

Many of these sites explicitly instruct users to visit from a mobile device for a "better experience," a social engineering nudge to ensure the target opens the page in Safari on iOS rather than a desktop browser. This tactic increases the likelihood that the exploit will run successfully, since it targets specific iOS versions. For example, a fake bingo site might display a popup saying, "For the best experience, please open this page on your iPhone," coaxing victims into the right environment.

---

Infrastructure analysis: DNS, rDNS, WHOIS, and hosting

We conducted full DNS resolution, reverse DNS lookups, WHOIS/RDAP registration queries, and IP pivots across all delivery and C2 domains. The results reveal a deliberate infrastructure strategy: abuse of major cloud CDNs to hide the real origin, a small number of dedicated IPs for the most sensitive lure sites, and registration patterns that cluster tightly around late 2025 and early 2026. This coordination suggests a well-planned campaign rather than random opportunistic activity.

Hosting breakdown

The delivery infrastructure breaks into four distinct hosting tiers.

Tier 1: Cloudflare proxy. The bulk of the gambling and gaming delivery domains, including 7p[.]game, b27[.]icu, h4k[.]icu, spin7[.]icu, 7ff[.]online, 26a[.]online, tubeluck[.]com, ai-scorepredict[.]com, and dbgopaxl[.]com, all resolve to Cloudflare anycast IPs. Cloudflare provides DDoS protection, TLS termination, and effective origin IP concealment. The real backend servers are not visible from DNS. This setup allows attackers to mask their true infrastructure behind a reputable service, complicating takedown efforts. Think of it this way: Cloudflare acts like a shield, making it hard to trace the attackers’ real servers.

Tier 2: AWS CloudFront. A second large cluster uses AWS CloudFront as a CDN layer. Domains including 4u[.]game, seven7[.]vip, seven7[.]to, 4kgame[.]us, 7uspin[.]us, n49[.]top, 98a[.]online, cy8[.]top, 7fun[.]icu, k96[.]icu, t7c[.]icu, y4w[.]icu, and the bingo cluster (land[.]77bingos[.]com, land[.]bingo777[.]now, land[.]777bingos[.]xyz) all resolve to CloudFront edge nodes. The bingo cluster shares a single set of four CloudFront IPs, indicating they are served from the same distribution and likely the same S3 or EC2 origin. This consolidation helps attackers efficiently manage multiple lures while maintaining resilience. For example, if one domain is taken down, others remain operational, ensuring continuous delivery.

Tier 3: Dedicated IPs on abuse-tolerant hosting. The most operationally significant finding is the use of dedicated IPs on hosting providers known for abuse tolerance for the most sensitive lure sites. cryptocurrencyworld[.]top and bestcryptocurrency[.]top share a single dedicated IP: 95.214.181.109, registered to Datacamp Limited in Hong Kong (AS212238), a well-documented bulletproof hosting provider. These two domains are the only ones on that IP. mkkku[.]com resolves to 185.53.179.128 (Team Internet AG, Germany). Reverse DNS on that IP surfaced seven additional gambling domains on the same server: bet247[.]ac, gem88[.]ac, gemwin[.]ac, gunbet[.]ac, i9-bet[.]ac, sbet[.]ac, and taisunwin[.]ac, all consistent with the broader Coruna delivery theme. btrank[.]top resolves to a dedicated AWS EC2 instance in Tokyo (54.248.167.86). ddus17[.]com resolves to 103.110.221.8 (JT Telecom International, Japan) with no co-hosted domains, consistent with a dedicated server. This tier shows how attackers balance concealment with operational control. In other words, they use bulletproof hosts where they can operate freely, while still leveraging cloud services for scalability.

Tier 4: China Unicom. pc6[.]com, a large Chinese software download portal listed among the delivery URLs, resolves to nine IPs across China Unicom's backbone (AS4837). The reverse DNS pivots on these IPs returned hundreds of co-hosted domains each, all with Chinese-language names and .cn, .cc, and .cloud TLDs. This is consistent with a large shared hosting environment. The pc6[.]com delivery URL likely represents a compromised page on an existing legitimate site rather than attacker-owned infrastructure. This example highlights how attackers exploit legitimate platforms to distribute their payloads. For instance, a popular Chinese software portal might unknowingly host malicious iframes, putting millions of users at risk.

WHOIS registration timeline

RDAP registration data was successfully retrieved for a subset of delivery domains. The dates cluster tightly, confirming a coordinated registration campaign. For example, many domains were registered within days or weeks of each other in late 2025 and early 2026, suggesting a planned rollout rather than random domain acquisitions. This pattern indicates the attackers prepared their infrastructure carefully, rather than improvising on the fly.

All confirmed registration dates fall between November 2025 and January 2026, a tight 10-week window that aligns perfectly with the campaign's observed escalation, from targeted espionage to broad financial exploitation. Here's why this matters: such a concentrated registration period suggests a coordinated effort to rapidly deploy infrastructure. For example, pepeairdrop01[.]com is currently suspended by its registrar due to failing domain verification, which indicates active takedown pressure from defenders. Think of it this way: this domain was likely flagged and taken offline quickly to disrupt the campaign's operations. Meanwhile, dbgopaxl[.]com stands out as an outlier, registered way back in April 2024. This suggests it might be a pre-positioned asset, set up months in advance to prepare for future use, or perhaps a legitimate domain that was compromised and repurposed for this campaign.

The C2 domains, the 27 DGA-generated .xyz domains, returned 404 errors from the RDAP server. This means they have either been deleted from the registry or were never registered under a standard RDAP-queryable path. Here's what that means in practice: these domains act as short-lived, algorithmically generated fallback domains. The operators register and discard them on a rolling basis to stay ahead of takedown efforts and avoid detection. For example, if one domain is blocked by defenders, another can quickly take its place without any manual intervention, keeping the command and control infrastructure resilient.

Certificate transparency

Certificate transparency logs give us an independent timeline for when domains started using HTTPS. Key findings include: b27[.]icu issued its first TLS certificate on 2025-06-01 (Amazon CA), confirming the domain was active at least six months before the campaign's peak. This early activity suggests it might have been used for initial testing or reconnaissance. Another example is 7p[.]game, which first appeared in CT logs on 2024-03-21 (GoDaddy CA). This is the oldest in the delivery set, implying it’s a long-running gambling operation that adopted Coruna delivery rather than a purpose-built lure site. ai-scorepredict[.]com issued its first certificate on 2026-01-29, the exact same day as its RDAP registration date, confirming it was purpose-built for this campaign. Lastly, tubeluck[.]com first appeared in CT logs in 2019, making it the oldest domain in the entire dataset. This indicates it is a long-established CDN or hosting service that the operator is using as infrastructure, likely to blend malicious traffic with legitimate content.

C2 domain infrastructure

All 27 DGA-generated C2 domains currently return no DNS A records, meaning they don't resolve to any IP addresses. Two domains, vvri8ocl4t3k8n6[.]xyz and rlau616jc7a7f7i[.]xyz, had URLScan entries from March 4, 2026, the day of the GTIG disclosure. Both resolved to Cloudflare IPs at that time. This confirms the C2 infrastructure was live and Cloudflare-fronted on the day of disclosure. Since then, the infrastructure has either been taken down or rotated to new domains. Think of it like changing the locks after a break-in: the operators quickly moved their command and control to avoid disruption and detection by defenders.

---

Four layers of obfuscation before you see a single exploit

Opening the delivery page in a text editor reveals nothing useful at first glance. The Coruna framework uses a sophisticated four-layer obfuscation architecture designed specifically to defeat static analysis tools and automated sandboxes. This means that even experienced analysts face a tough challenge just to understand what the code does.

Layer 0: the outer bootstrap

The delivery HTML contains a minimal JavaScript bootstrap. Every meaningful string is hidden as an array of integers XOR-decoded at runtime. For example:

[107, 49, 105, 97].map(x => String.fromCharCode(x ^ 84)).join("")

Here, each integer is XORed with the key 84 to reveal the actual character. The XOR key varies per string, so there’s no single pattern to match across the entire file. The core logic hides inside new Function(atob("..."))(): a Base64-encoded string that’s evaluated as a new function. This keeps the real code out of the initial parse tree and most static scanners. In other words, the code is locked behind a puzzle that only reveals itself at runtime, making static analysis nearly impossible.

Layer 1: the module dispatcher

After decoding Layer 0, you get a JavaScript object registered as globalThis.vKTo89. This object contains a full SHA-256 implementation and a lookup table of exploit modules keyed by their SHA1 hashes. The dispatcher exposes five API functions:

The LBrh4t function implements a keyed module delivery protocol. Given a module hash ID, it computes SHA256(salt + hash_id).substring(0, 40) and fetches the resulting filename from the server. The salt observed in the analysed samples is cf40de81867d2397. Without knowing the salt, an analyst cannot predict which filenames to request, even if they know the module hash IDs. The base URL is derived from location.href.slice(0, lastIndexOf("/") + 1), meaning all exploit modules are served from the same domain as the delivery page. This setup makes it hard for defenders to intercept or predict module fetches, effectively hiding the attacker's next moves.

Layer 2: module code

Each module is stored as a Base64-encoded string. When decoded, the module JavaScript continues to use XOR-encoded string arrays for all sensitive literals: framework paths, API names, memory addresses, version constants. This layered obfuscation ensures that even if one layer is decoded, the sensitive data remains hidden, forcing analysts to peel back multiple layers before understanding the payload.

Layer 3: inline binary payloads

The largest modules embed their binary payloads as Base64-encoded strings within the JavaScript. The ARM64 shellcode is stored as raw binary. The Mach-O binary is stored with each byte zero-padded to two bytes (UTF-16LE encoding), adding an extra layer of obfuscation against binary signature detection. Think of this like wrapping a package twice to make it harder to identify. This clever trick helps the malware evade signature-based detection tools.

Anti-analysis measures

The framework implements several active anti-analysis checks before running any exploit code. It aborts if Apple's Lockdown Mode is detected. It skips execution in private browsing mode. It verifies a real WebKit rendering engine is present by creating a <math> element and checking that mathcolor="blue" renders as rgb(0, 0, 255). It also checks for RTCPeerConnection availability to confirm a genuine browser environment rather than a headless sandbox. After execution, it reports the outcome to the C2 via a GET request to <base_url>?e=<code>, where 0 means success, 1000 means exploit failure, 1001 means the target version is not supported, and 1003 means a sandbox was detected. These checks help the malware avoid running in environments where it might be analyzed or fail, increasing the chances of successful exploitation.

---

The exploit chain: six phases from page load to Mach-O

Phase 1: target fingerprinting

The fingerprinting module runs first and decides whether the target is worth attacking and which exploit chain to use. The script checks the User-Agent string for Version/ (present in all Safari UAs) and AppleWebKit/. If neither is found, it stops immediately. Then, it distinguishes iOS from macOS Safari using a combination of typeof TouchEvent !== "undefined" and an IndexedDB Blob insertion test. Specifically, attempting to store a Blob object in IndexedDB throws the exception "BlobURLs are not yet supported" on iOS Safari, which serves as a reliable platform fingerprint.

The most technically sophisticated part of the fingerprinting is a WebAssembly memory oracle. The script instantiates a WebAssembly.Table and a WebAssembly.Instance, then reads the internal JSC (JavaScriptCore) cell type tags from memory. The tag value 0x10016 indicates macOS Safari; 0x10017 indicates iOS Safari. This technique reads JavaScriptCore's internal object representation directly from memory, requiring intimate knowledge of WebKit's source code. The iOS version is extracted from the User-Agent and compared against a lookup table of 19 known iOS versions (10.0.0 through 17.0.0) and 13 macOS Safari versions, with separate exploit paths selected for iOS 13 to 15.x and iOS 16.x and above. This precise fingerprinting ensures the exploit chain matches the target’s environment perfectly, increasing the chances of success.

Phase 2: remote code execution via JIT type confusion (CVE-2024-23222)

The primary exploit chain in the samples we analysed is cassowary, targeting CVE-2024-23222, a type confusion bug in JavaScriptCore patched by Apple in January 2024 with iOS 17.3.

The exploit begins by calling a function exactly 1,000,000 times with floating-point arguments. This forces the JSC JIT compiler to specialise the function for float array operations, generating optimised machine code that assumes every array element will always be a double-precision float. Once JIT compilation has occurred, the exploit replaces one element of the target array with a JavaScript object instead of a float. The JIT-compiled code reads this value as a float, interpreting the object's pointer as a 64-bit double. This is the type confusion: JSObject* is being treated as double. By reading back the confused float value, the exploit recovers the object's address in the JSC heap. This is the addrof primitive.

The reverse operation, writing a crafted float into the array, causes JSC to interpret the double as an object pointer, creating a fakeobj primitive pointing to attacker-controlled memory. Using addrof and fakeobj together, the exploit constructs a fake ArrayBuffer object whose backing store pointer is set to an arbitrary address. Reading or writing through this fake ArrayBuffer provides full arbitrary process memory read/write. The exploit stabilises this primitive using heap spraying with 16-element arrays of specific float values and a custom 64-bit integer abstraction class. This combination allows the attacker to manipulate memory at will, a critical step for further exploitation.

Phase 3: defeating ASLR via dyld shared cache scanning

With arbitrary read/write established, the exploit scans process memory for the dyld shared cache to defeat ASLR. On iOS, it locates WebCore, CoreUtils, and IOKit by scanning for their __TEXT segment headers. On macOS, it targets CoreFoundation, CoreGraphics, ActionKit, and RESync. The exploit reads the __TEXT segment headers of each framework to determine their load addresses, and locates _ZN3JSC16jitOperationListE to find JIT-allocated executable memory regions. This step is crucial because ASLR randomises memory locations, and knowing these addresses allows the exploit to reliably execute code.

Phase 4: escaping the sandbox

The sandbox escape module combines two techniques. An SVG <feConvolveMatrix> filter exploit corrupts memory in the WebKit compositor process, allowing the exploit to escape the renderer sandbox. Simultaneously, the exploit uses pthread_main_thread_np, a private macOS and iOS API, to manipulate thread-local storage and gain access to the main thread's execution context, which carries broader system privileges than the renderer thread. Think of it this way: escaping the sandbox is like breaking out of a locked room to access the whole building.

Phase 5: bypassing pointer authentication on Apple Silicon

On Apple Silicon devices (every iPhone since the XR and every M-series Mac), the exploit must defeat Pointer Authentication Codes (PAC), Apple's hardware-enforced control-flow integrity mechanism. The macOS stager module contains the following JSC internal C++ symbols:

_ZN3JSC20SecureARM64EHashPins27allocatePinForCurrentThreadEv
_ZN3JSC10LinkBuffer8linkCodeERNS_14MacroAssemblerENS_20JITCompilationEffortE
_ZN3WTF13MetaAllocator8allocateEmPv
jitCagePtr

The exploit abuses jitCagePtr and SecureARM64EHashPins to allocate executable memory within the JIT cage and sign the ARM64 shellcode with a valid PAC signature. This allows unsigned native code to execute on PAC-enforced hardware. The technique allocates 40 MB of memory with new Uint32Array(10000000) and fills JIT memory with predictable patterns using a JIT spray of repeated x += 1 statements. This approach tricks the hardware into trusting the malicious code, bypassing PAC protections.

Phase 6: shellcode execution and payload delivery

The final stager modules contain three embedded binary components:

The ARM64 shellcode begins with the standard function prologue STP X29, X30, [SP, #-16]! and is injected into JIT-allocated executable memory. It uses dlsym against /usr/lib/system/libdyld.dylib to resolve system functions at runtime, avoiding static imports. The Mach-O binary references private iOS frameworks including SpringBoard, PassKitCore, CoreML, MediaToolbox, and AppleMediaServices. This indicates system-level capabilities such as keychain access, installed app enumeration, and home screen manipulation. The final payload, PlasmaLoader (also called PLASMAGRID by Google GTIG), is fetched from the delivery domain as an encrypted .min.js file. It decodes QR codes from images, fetches additional modules from C2, and exfiltrates cryptocurrency wallet data from popular wallets like MetaMask, Exodus, Bitget Wallet, and Base. This shows the campaign’s clear financial motivation and sophisticated targeting of valuable assets.

---

Twenty-three exploits, five chains, four years of CVEs

The cassowary chain is one of twelve named exploit chains within Coruna. The full kit covers iOS 13 through 17.2.1 with no gaps. This complete coverage means the attackers can target virtually any device running these iOS versions, leaving few safe havens for potential victims.

Two of these chains, Photon and Gallium, exploit vulnerabilities previously used as zero-days in Operation Triangulation, the sophisticated iOS espionage campaign documented by Kaspersky in 2023. Their reuse in a financially motivated criminal campaign directly illustrates how nation-state offensive tools move into the broader threat ecosystem once the underlying CVEs become public knowledge. For example, after these CVEs were disclosed, criminal groups quickly adopted them to target everyday users for profit, turning advanced espionage tools into mass-market malware. On March 5, 2026, CISA added CVE-2021-30952, CVE-2023-41974, and CVE-2023-43000 to its Known Exploited Vulnerabilities catalog with a remediation deadline of March 26, 2026 for federal agencies. This highlights the urgency of patching these vulnerabilities to prevent exploitation and protect critical infrastructure.

The module architecture in full

[Delivery Page: group.html / analytics.html]
    |
    +-- Layer 0: Bootstrap (XOR-obfuscated JS)
    |   +-- Initialises globalThis.vKTo89 dispatcher
    |
    +-- Layer 1: MM Object (Base64 -> JS)
    |   +-- Module 1ff010bb: Math/utility library
    |   |   +-- SHA256, BigInt arithmetic, URL parsing
    |   +-- Module 6b57ca33: Fingerprinting engine
    |       +-- UA parsing, platform detection
    |       +-- WebAssembly memory oracle (JSC cell tags 0x10016/0x10017)
    |       +-- IndexedDB Blob test (iOS detection)
    |       +-- MathML rendering test
    |       +-- WebRTC environment check
    |
    +-- Remote Modules (fetched via SHA256-keyed URLs)
        +-- 8dbfa3fd: JIT type confusion exploit (addrof/fakeobj)
        +-- 55afb1a6: Arbitrary R/W primitive (fake ArrayBuffer)
        +-- 5264a069: WebAssembly-based exploit variant
        +-- 166411bd: WebAssembly JIT spray / BigUint64Array primitive
        +-- d6cb72f5: JIT compiler exploit (1M-iteration warm-up)
        +-- dbfd6e84: Sandbox escape (feConvolveMatrix + pthread)
        |
        +-- [iOS path] bcb56dc5: iOS dyld shared cache scanner
        |   +-- WebCore, IOKit, CoreUtils framework locator
        |
        +-- [macOS path] 2d2c721e: macOS dyld shared cache scanner
        |   +-- CoreFoundation, CoreGraphics, ActionKit locator
        |
        +-- [iOS stager] 164349160: iOS payload stager
        |   +-- ARM64 shellcode (31,308 bytes)
        |   +-- Encrypted Mach-O binary (14,954 bytes)
        |
        +-- [macOS stager] 6241388a: macOS payload stager
            +-- ARM64 shellcode (31,308 bytes)
            +-- Encrypted Mach-O binary (14,954 bytes)
            +-- PAC bypass (jitCagePtr, SecureARM64EHashPins)
            +-- JIT ROP chain

---

Attribution and threat actor context

The campaign delivering Coruna through cryptocurrency and gambling lures is attributed to UNC6691, a financially motivated threat actor believed to operate from China. Here's why this attribution makes sense: the infrastructure heavily uses .icu, .top, .online, and .game TLDs, which are commonly linked to Chinese-operated fraud networks. For example, domains like mijieqi[.]cn and 668ddf[.]cc use Chinese characters or naming conventions typical of Chinese threat groups. Think of it this way: these domain choices and language clues provide strong signals about the operator's origin. Importantly, the exploit imposes no geolocation restrictions; it targets any Safari user worldwide, making it a global threat.

The migration of the Coruna framework from a commercial surveillance vendor, through a nation-state espionage actor (UNC6353), to a financially motivated criminal group (UNC6691) within roughly one year highlights the active secondary market for advanced mobile exploits. Here's what that means in practice: sophisticated zero-day exploits initially developed for espionage are quickly repurposed for profit-driven cybercrime. For instance, the two Operation Triangulation CVEs embedded in the kit, CVE-2023-32434 and CVE-2023-38606, were first publicly documented as zero-days used in a high-level espionage campaign. Now, these same vulnerabilities fuel a mass-exploitation tool targeting cryptocurrency wallets, showing how quickly threat actors pivot their tactics.

---

What you should do

The most effective protection is straightforward: update all Apple devices immediately. The kit explicitly fails against the latest version of iOS available at the time of disclosure. For example, users running iOS 17.3 or later are safe from the primary cassowary chain exploit. Even better, the full kit is neutralized on iOS 17.4 and above. Don't wait—updating your device is the simplest and most reliable defense.

For web teams specifically: the question isn’t just whether your users have patched their devices. You also need to consider whether your site could be used to deliver this payload to unpatched users. For instance, a compromised ad tag, a poisoned analytics script, or a hijacked CDN asset loaded by your pages could turn your site into a distribution node without your knowledge. Your server logs would show nothing suspicious because the exploit runs entirely in the browser, reports to a C2 domain you’ve never heard of, and then exits silently. This stealth makes detection extremely difficult without specialized monitoring.

---

Indicators of compromise

C2 domains (DGA-generated, .xyz TLD)

vvri8ocl4t3k8n6[.]xyz    rlau616jc7a7f7i[.]xyz    ol67el6pxg03ad7[.]xyz
6zvjeulzaw5c0mv[.]xyz    ztvnhmhm4zj95w3[.]xyz    v2gmupm7o4zihc3[.]xyz
pen0axt0u476duw[.]xyz    hfteigt3kt0sf3z[.]xyz    xfal48cf0ies7ew[.]xyz
yvgy29glwf72qnl[.]xyz    lk4x6x2ejxaw2br[.]xyz    2s3b3rknfqtwwpo[.]xyz
xjslbdt9jdijn15[.]xyz    hui4tbh9uv9x4yi[.]xyz    xittgveqaufogve[.]xyz
xmmfrkq9oat1daq[.]xyz    lsnngjyu9x6vcg0[.]xyz    gdvynopz3pa0tik[.]xyz
o08h5rhu2lu1x0q[.]xyz    zcjdlb5ubkhy41u[.]xyz    8fn4957c5g986jp[.]xyz
uawwydy3qas6ykv[.]xyz    sf2bisx5nhdkygn3l[.]xyz  roy2tlop2u[.]xyz
gqjs3ra34lyuvzb[.]xyz    eg2bjo5x5r8yjb5[.]xyz    b38w09ecdejfqsf[.]xyz

Delivery domains (selected)

ai-scorepredict[.]com         pepeairdrop01[.]com
goodcryptocurrency[.]top      cryptocurrencyworld[.]top
bestcryptocurrency[.]top      binancealliancesintro[.]com
b27[.]icu                     7p[.]game
4u[.]game                     h4k[.]icu
spin7[.]icu                   seven7[.]vip
seven7[.]to                   4kgame[.]us
7uspin[.]us                   n49[.]top
98a[.]online                  7ff[.]online
26a[.]online                  cy8[.]top
btrank[.]top                  mkkku[.]com
goanalytics[.]xyz             kanav[.]blog
land[.]77bingos[.]com         land[.]bingo777[.]now
land[.]777bingos[.]xyz        dbgopaxl[.]com
lddx3z2d72aa8i6[.]xyz         dd9l7e6ghme8pbk[.]xyz
fxrhcnfwxes90q[.]xyz          3v5w1km5gv[.]xyz
sj9ioz3a7y89cy7[.]xyz         appstoreconn[.]com
ddus17[.]com                  tubeluck[.]com

Infrastructure IPs (non-CDN)

Additional domains found via rDNS pivot (Team Internet AG, 185.53.179.128)

bet247[.]ac    gem88[.]ac    gemwin[.]ac
gunbet[.]ac    i9-bet[.]ac   sbet[.]ac
taisunwin[.]ac

JavaScript signatures

Module dispatcher:    globalThis.vKTo89
API functions:        WLEBfI, ksQccv, OLdwIx, LBrh4t, tI4mjA
URL obfuscation:      lysNguL, lysNguk, lysNgu6, lysNguv
Deployment salt:      cf40de81867d2397
XOR pattern:          [n1,n2,...].map(x => String.fromCharCode(x ^ K)).join("")
JIT warm-up:          new Uint32Array(10000000) + repeated x += 1
Version boundaries:   13E4, 16E4

Module SHA1 hash IDs

1ff010bb3e857e2b0383f1d9a1cf9f54e321fbb0  (utility library)
6b57ca3347345883898400ea4318af3b9aa1dc5c  (fingerprinting)
8dbfa3fdd44e287d57c55e74a97f526120ffd8f0  (JIT type confusion)
55afb1a69f9e35265f29b113adaa6f34e8215813  (arbitrary R/W)
5264a0694295c0a1978d1b4b03b2ab909e5c6d09  (WASM exploit)
166411bd90ee39aed912bd49af8d86831b686337  (BigUint64 primitive)
d6cb72f5888b2ec1282b584155490e3b6e90a977  (JIT compiler exploit)
dbfd6e840218865cb2269e6b7ed7d10ea9f22f93  (sandbox escape)
bcb56dc5317128d4e53b8474535f4c099bf322b3  (iOS dyld scanner)
2d2c721e64fbbb49c39654930563758332e4eff3  (macOS dyld scanner)
164349160d3d35d83bfdcc001ccd23cd1b3b75d5  (iOS stager)
6241388ab7da11aa490d4ecfed44d952568f008a  (macOS stager)

Binary signatures

ARM64 shellcode:  31,308 bytes | begins fd 7b bf a9 fd 03 00 91 (STP X29, X30 prologue)
Mach-O payload:   14,954 bytes | ARM64 (0xFEEDFACF) | UTF-16LE padded in JS
PlasmaLoader:     ~1,324 bytes encrypted | filename: [40-char hex].min.js

---

Quick recap

Coruna is a spyware-grade iOS exploit kit containing 23 individual exploits across five chains. It covers every version of iOS from 13.0 through 17.2.1. Originally, developers created it for a commercial surveillance vendor. Then, a Russian espionage group used it. Now, a Chinese financially motivated threat actor actively deploys it against cryptocurrency wallets. This evolution shows how exploits can move between different types of actors.

The kit runs entirely in the browser as a self-contained JavaScript payload. It uses four layers of obfuscation and a keyed module delivery protocol that makes static analysis nearly impossible without the deployment salt. The execution chain has six phases, ending with a signed ARM64 shellcode, a Mach-O binary, and a final implant that exfiltrates data from MetaMask, Exodus, Bitget Wallet, and Base wallets. To put it simply: this is a highly sophisticated, multi-stage attack that targets popular crypto wallets directly within the browser environment.

The primary chain, called cassowary (CVE-2024-23222), targets iOS versions 16.6 through 17.2.1 using a JIT type confusion vulnerability in JavaScriptCore. Two other chains reuse zero-days originally discovered during Operation Triangulation. Notably, three CVEs from this kit were added to the CISA Known Exploited Vulnerabilities (KEV) catalog the day after public disclosure, underscoring their severity.

The infrastructure behind Coruna spans more than 50 delivery domains registered within a 10-week window between November 2025 and January 2026. These domains are hosted across Cloudflare, AWS CloudFront, a Hong Kong bulletproof provider (Datacamp Limited), and a dedicated AWS EC2 instance in Tokyo. The 27 C2 domains are DGA-generated using the seed "lazarus" and were Cloudflare-fronted at the time of disclosure. This diverse hosting setup helps the operators evade takedown efforts and maintain resilience.

Here’s the critical point for web teams: this payload is a JavaScript file. It doesn’t need to reside on your server to reach your users. A compromised ad tag, a poisoned third-party script, or a hijacked CDN asset would suffice. Your logs would show nothing suspicious. cside monitors every script that executes in your users' browsers in real time, which is the only layer where this attack becomes visible. Without such monitoring, you might never detect this threat.

---

---

References

1. Google Threat Intelligence Group, "Coruna iOS Exploit Kit Uses 23 Exploits Across Five Chains Targeting iOS 13-17.2.1," The Hacker News, March 4, 2026.
2. Apple Security Advisory, "CVE-2024-23222: WebKit type confusion issue," January 2024. nvd.nist.gov
3. CISA Known Exploited Vulnerabilities Catalog, March 5, 2026. cisa.gov
4. Help Net Security, "Apple fixes actively exploited WebKit zero-day (CVE-2024-23222)," January 23, 2024.
5. Infosecurity Magazine, "Coruna Exploit Kit Targets Older iPhones in Multi-Stage Attack," March 2026.
6. Security Affairs, "Google uncovers Coruna iOS Exploit Kit targeting iOS 13-17.2.1," March 2026.

---

This analysis is based on direct inspection of live Coruna samples retrieved from active delivery domains (b27[.]icu, 7p[.]game) combined with public threat intelligence from Google GTIG, CISA, and iVerify. Infrastructure analysis involved DNS resolution, reverse DNS pivots via HackerTarget, RDAP registration queries, certificate transparency logs via crt.sh, and URLScan passive DNS. All binary analysis took place in an isolated environment to ensure safety.