Inside Coruna and DarkSword Chains: From Web Lures to iOS Exploitation

Executive Summary

Seven months after Google Threat Intelligence Group (GTIG) published its initial analysis of the Coruna iOS exploit framework, the campaign has continued to evolve: the recovered infrastructure now deploys two distinct exploit chains conditioned on the target device's operating system version. Targets running iOS 17.2.1 or earlier receive the legacy Coruna framework (exhibiting byte-identical JavaScript payloads across multiple recovered configurations). Conversely, devices running later iOS builds receive a DarkSword-derived execution chain. Through October 2026, zLabs identified 608 domains delivering Coruna-family code, with recovered configurations across 93 of these sites mapping to 21 distinct tracking collectors. The analyzed distribution footprint spans dating portals, AI-companion platforms, cryptocurrency promotions, media streaming services, and—in several instances—compromised legitimate sites serving the kit via hidden iframes.

This report details our technical analysis of these infrastructure and payload developments. Specifically, we recovered and analyzed both components of the Coruna framework: the client-side JavaScript responsible for environment profiling and exploit chain selection, and the post-escape native payload modules engineered to operate beyond the WebContent sandbox.

What stands out to us:

• No app install, no user consent. The attack begins inside a web page. A visitor taps a link, the page renders normally, and a hidden frame loads the exploit chain. Later stages fetch native code without ever prompting the user to install anything. There is no App Store review to fail, no configuration profile to accept, no permission dialog to dismiss. From the target's point of view, the page can appear normal.
• One codebase, many variants. The lures are disposable; the kit is not. Across multiple sites we found the same core JavaScript runtime — byte-for-byte identical in its decoded form — behind wildly different themes, campaign labels, and tracking servers. Defenders who hunt for lure content or a campaign string may miss related sites. Defenders who hunt for the runtime can connect related sites.
• Native capability that reaches well past the browser. The recovered modules contain kernel memory read and write routines, code that manipulates Apple Mobile File Integrity (AMFI) state, process-memory reads via task ports, application-state monitoring, encrypted C2 communication with certificate validation disabled, and routines that delete crash logs and Safari website-data records.
• Delivery has already escaped the attacker's own infrastructure. SafeDep independently found matching Coruna code inside a compromised npm package, art-template. That means a site can serve Coruna to its visitors without anyone on the operator's side ever registering a lure domain — the kit arrives through the victim site's own dependency tree.

Fig.1: Selected milestones in Coruna activity and public reporting, February 2025–October 2026. Sources: GTIG, SafeDep and zLabs.

Part 1: Delivery: How visitors reach the exploit chains

The initial delivery infrastructure for both the Coruna and DarkSword exploit chains is unremarkable by design. Functioning as the most basic and disposable assets within the campaign, these landing pages serve two primary operational objectives: luring a target to navigate to the malicious URL via Mobile Safari, and maintaining user engagement long enough for a hidden iframe to execute the underlying exploit chain.

The infection mechanism relies on a classic drive-by download pattern. While the foreground page renders legitimate-appearing decoy content, a concealed, off-screen iframe silently fetches and executes the exploit framework in the background. The compromise sequence requires no further user interaction, triggers no native iOS permissions prompts, and leaves the decoy site's visible functionality entirely intact to avoid user suspicion.

Lure pages and hidden frames

Dating and AI-companion platforms provide two such examples (Figure 2). The dating sites rely on reused templates localized for Brazil, Nigeria, and Indonesia. For instance, the domain echomint[.]buzz hides the exact same exploit framework behind a multilingual AI-companion service. The promise of matches and content previews acts as a simple social engineering hook, keeping the target engaged just long enough for the background execution to finish.

Fig.2: Lure-page examples: dating, AI-companion chat and legitimate casino content embedded in an attacker-controlled page.

In some instances, attackers conceal the exploit by framing legitimate third-party content. These attacker-controlled pages display the expected site prominently while loading the exploit in a separate, hidden frame. For example, ax[.]xoovo[.]top uses a full-screen frame to display the legitimate Coins.Game cryptocurrency casino, while a secondary frame loads the attack code out of view. By decoupling the visible decoy from the malicious loader, the page functions exactly as expected while the exploit runs in the background. The HTML for www2[.]disp[.]cc relies on a similar structural technique, pushing the exploit-loading frames off-screen behind standard forum content:

Because the exploit operates within a hidden iframe, there are no visual indicators of compromise. The user sees the expected site, interacts with it normally, and departs without suspicion. Consequently, any security advice that relies on a victim noticing anomalies is rendered completely ineffective against this delivery pattern.

Moving visitors into Safari

Several pages explicitly instruct visitors to exit their in-app browser and open the link in Safari. For instance, the Brazilian dating lure xxtg1[.]eu[.]cc prompts TikTok users to select “Open in browser” to unlock a content preview, subsequently directing them to Safari. These social engineering tactics are designed to direct the target into the specific execution environment required by the exploit to load.

Source: 3x3br[.]eu[.]cc. The message in Portuguese prompts the user to leave TikTok.

The page first appends guide=1 to the URL without reloading. If the initial browser check detects Safari, it redirects to a URL containing view=safari. These URL parameters dictate the visible content shown to the target; the exploit loader, meanwhile, performs its own independent browser checks:

Source: 3x3br[.]eu[.]cc

The Safari prompt is a deliberate component of the delivery mechanism. It transitions targets from an in-app browser into the specific execution environment required by the loader, bridging the social engineering message with the technical browser checks detailed next.

Supply chain attack through a compromised npm package & Enterprise threat

SafeDep documented another delivery route in May 2026: compromised versions of art-template, a JavaScript templating package distributed through npm. The affected browser bundle injected a script that fetched additional code from external infrastructure, leading to Coruna.

This shifts the threat model entirely. When a front-end dependency is backdoored, the malicious loader is pulled into the application during standard build pipelines or dynamically executed client-side. The victim site’s own web servers then deliver the Coruna or DarkSword loader straight to visitors as part of their standard, trusted JavaScript bundles. This explains why many legitimate websites appear as part of this campaign.

Under this delivery model:

• No lure domain exists in the chain: The malicious code is served from legitimate application infrastructure that users and enterprise filtering policies have every reason to trust.
• Reputation defenses fail silently: Domain blocklists and URL categorizers designed to stop disposable .eu.cc, .shop, or .icu lure hosts offer zero protection against first-party scripts.
• Execution is automatic: Any iOS visitor loading the legitimate page triggers the browser profiling and exploit staging without clicking a phishing lure or leaving the site.

For enterprise security teams, this is the far more consequential vector. Consumer-focused lure themes—dating chats, crypto giveaways, and streaming video—rarely intersect with corporate device workflows. A compromised third-party JavaScript package, by contrast, can hide behind internal portals, B2B SaaS platforms, or partner portals that employees visit daily. At the same time, this highlights the need of real-time detection not based on domains or TLD blacklisting.

Part 2: The Coruna Chain in the Browser

The recovered infrastructure hosts two distinct exploit chains (Figure 3). The first targets iOS devices running versions prior to 18 (with specific caveats). This chain is based on the Coruna framework, and we trace its execution path from initial browser memory access through to its native loader and modules. Figure 4 subsequently examines the DarkSword-based iOS 18 chain.

The loader for the Coruna chain verifies that the iPhone identifies as Mobile Safari, rejecting alternative iOS browsers and several in-app browsers. Its execution sequence aligns with GTIG’s Coruna analysis: device checks, a WebKit exploit, and a pointer authentication bypass where required.

The browser selects the exploit route. Separate tracking code decides when to transmit visitor telemetry, so its checks should be analyzed independently from the exploit-selection logic.

Fig.3: Delivery and tracking in the recovered infrastructure, showing the browser stages of the Coruna chain and the separate iOS 18 chain.

Selecting an exploit route

One recovered .js checks the iOS version and directs the target to either a Coruna-laced iframe or an iOS 18 delivery page. The simplified logic below outlines this decision tree:

Within this selector logic, group.html is designated for the Coruna chain on iOS 15.x, iOS 16.x (excluding 16.7.x), and iOS 17.0–17.1.x. The iOS 18.4–18.6 branch redirects the target to a dedicated page for the DarkSword chain. Further along the iOS 18 execution path, rce_loader.js deploys version-specific workers for 18.4/18.5, 18.6, and 18.7.0–18.7.2 (Figure 4).

Fig.4: Version ranges used by the recovered selectors. The Coruna chain opens group.html; the loader for the iOS 18 chain selects a version-specific worker. Device observations in this report cover iOS 18.6.2.

The example below follows each stage of the Coruna chain for iOS 15.2-15.5 and the DarkSword chain for a range of iOS 18 versions. The technical appendix lists the other recovered exploit entries and GTIG's CVE mappings.

Stage 1: Reading and writing browser memory

The exploits leverage CVE-2022-48503, targeting Safari’s WebAssembly implementation, which runs compiled code inside the browser. This stage establishes read and write primitives: reusable operations that enable subsequent stages to inspect and manipulate memory within Safari's WebContent process.

By design, standard web content cannot access this memory directly. These primitives grant subsequent stages the necessary access to bypass the browser's remaining security mitigations. All downstream execution—the Pointer Authentication Code (PAC) bypass, the native loader, and the kernel module—relies entirely on this initial stage converting a WebAssembly flaw in the JavaScript engine into arbitrary memory access.

Stage 2: Bypassing pointer authentication

Code pointers are memory addresses used by a program to locate instructions. Pointer Authentication Codes cryptographically sign these addresses to ensure any tampering is detected before the pointer is utilized, serving as one of the primary reasons memory corruption on Apple silicon does not reliably translate into arbitrary code execution. GTIG identifies breezy15 as a bypass for this specific mitigation. The module we analyzed exposes pointer-signing helper functions invoked by the subsequent stage.

The presence of a maintained PAC bypass, featuring separate variants covering iOS 13.0 through 17.2.1 (see Table 7), serves as one of the strongest indicators of the resources behind this kit. PAC bypasses are not incidental discoveries; they are hard-won, highly version-sensitive, and notoriously fragile across OS updates. An exploit framework maintaining five distinct variants across five major OS generations (iOS 13 through 17), alongside a prerequisite module for later builds, reflects sustained engineering investment rather than an opportunistic assembly of public exploits.

Stage 3: Preparing the native loader

The analyzed Stage 3 variant contains an encoded native loader alongside logic to retrieve additional payload data. This stage decodes the embedded loader and maps it into memory for execution. Acting as a bootstrap executable, the compiled native loader is responsible for unpacking and initializing downstream components; the following section examines the specific recovered modules deployed by the Coruna chain.

Part 3: Native Modules in the Coruna Chain

Up to this point, all execution is confined to the browser environment. The native modules (Figure 5) represent the primary objective of the chain: compiled ARM64 Mach-O binaries, executed without user interaction or local installation, and engineered to operate with elevated privileges far beyond the browser sandbox.

Across 19 containers, we extracted 90 entries, including 55 Mach-O files representing 24 distinct binaries—twelve of which are version-specific builds of a single kernel module. This ratio is itself a notable finding. Maintaining twelve kernel module variants demonstrates explicit engineering for coverage: the developers are continually rebuilding and maintaining this component against a matrix of iOS releases. This level of maintenance overhead is typically only assumed for campaigns anticipating a long operational lifespan and a broad target surface. While Coruna was originally developed by a nation-state actor for highly targeted operations, its leak following initial detection has effectively commoditized the toolkit. Consequently, multiple distinct threat actors are now deploying and profiting from this exploit framework.

Fig.5: Capabilities identified through analysis of native modules in the Coruna chain: code-signing changes, application and memory access, communication, and cleanup.

Kernel memory and code-signing checks

The kernel controls access to memory and system resources. The recovered module includes kernel-memory read and write routines and changes state associated with Apple Mobile File Integrity (AMFI), part of iOS's code-signing enforcement:

Source: recovered kernel module (type 0x09). Reconstructed pseudocode; names added.

The pseudocode locates references named developer_mode_status and allows_security_research, reads a value, and writes values back to the associated locations. This shows the module targeting state used by code-signing checks.

For defenders, unexpected changes to code-signing enforcement are a high-priority integrity signal. They should be investigated alongside other device events and the code markers in this report.

Application state and process memory

The orchestration module checks application state and includes a routine that reads process memory through a supplied task port, a handle used to access that process. The excerpt below shows an application-state query and a separate read of loaded-library information:

Source: recovered orchestration module (type 0x08). Reconstructed pseudocode combines separate routines; descriptive names added.

The first routine asks about an application's state. The second retrieves metadata about libraries loaded into a process. These operations provide application and memory-layout information to native code.

Another component, module type 0x0f, checks whether it is running in one of several system processes before initializing a module. Its process list includes keybagd, CloudKeychainProxy, and GSSCred, names associated with key and credential services.

Command, control and cleanup

The communication code includes an HTTPS client and a ChaCha20 encryption implementation. The HTTPS routine disables certificate-chain validation, skipping the check that a server certificate chains to a trusted authority. Skipping certificate checks lets the implant accept any server certificate, including self-signed ones, so the operator does not have to maintain valid certificates for its servers. If the ChaCha20 layer wraps the command traffic, TLS inspection alone would not reveal its contents. The excerpt shows the setting passed to Apple's networking API:

Source: recovered communication routines (module type 0x08). Reconstructed pseudocode; variable names added.

The cleanup module contains routines to delete diagnostic and launchd logs. A separate routine in the orchestration module calls Safari's website-data deletion API:

Source: recovered log-deletion module (type 0x0a) and orchestration module (type 0x08, Safari website data). Reconstructed pseudocode from separate routines; names added, filter arguments and checks omitted.

The targets include WebKit diagnostic reports, JetsamEvent records, and launchd.log. JetsamEvent records describe process termination under memory pressure; launchd is the service manager. Removing these records and Safari website data would reduce the artifacts available to investigators.

This makes timely collection valuable. Security teams should preserve diagnostic data when crash, restart, or integrity anomalies appear, while those records are still available.

Part 4: Following the DarkSword chain

The shared delivery infrastructure also distributed a DarkSword-derived iOS 18 chain. zLabs analyzed this vector through melatibiru[.]win, recovering ten distinct exploit scripts served from the central staging host ssc[.]vever3eds[.]com.

The browser loader dynamically profiles the device version to serve dedicated Web Workers: on iOS 18.6.2, it deploys rce_worker_18.6.js alongside specialized helper scripts, while conditional branches select targeted workers for iOS 18.4–18.5 and iOS 18.7.0–18.7.2. The 18.6 worker includes hardcoded memory offsets for an iPhone 11 running iOS 18.6.2 (build 22G100), matching the analysis environment. Executing these routines within a Web Worker isolates the exploit logic from the page’s main rendering thread, minimizing UI disruption while memory manipulation occurs in the background.

Architecturally, the exploit pipeline is segmented across distinct privilege boundaries:

1. Initial Browser Stage: Establishes remote code execution (RCE) within the unprivileged WebContent process.
2. GPU Process Sandbox Escape (sbx0): Targets WebKit’s dedicated GPU process to pivot out of the renderer.
3. Media Subsystem Escalation (sbx1): Pivots into mediaplaybackd, an iOS system daemon responsible for media pipelines.
4. Post-Escape Orchestration Worker: Manages the subsequent native payload stages.

The recovered sbx1_main.js component embeds initialization routines equipped with arbitrary memory read/write primitives and native function invocation helpers. During execution, zLabs observed both WebKit's GPU process and mediaplaybackd attempting to create a shared IPC directory at /private/var/tmp/c2_ipc—operations systematically blocked by the system's sandbox enforcement. Concurrently, mediaplaybackd received direct peer connections from the GPU process via XPC, illustrating how the attack chain leverages cross-process messaging to bridge privileges across isolated environments.

Crucially, dynamic telemetry captured an outbound TLS ClientHello originating directly from mediaplaybackd to ccsigen321qc[.]com—the remote command-and-control (C2) endpoint explicitly configured within pe_worker.js (Figure 6).

Post-exploitation modules and command traffic

Following the initial browser stages, the compromised device retrieved seven additional JavaScript modules from ccsigen321qc[.]com via the /api/payload/get endpoint. The C2 server delivered the module source code within a JSON src field. The retrieved files included pe_worker_body.js, c2_agent.js, and telegram_v1.js, facilitating the dynamic deployment of post-exploitation capabilities.

The command agent implements a specific routine to load telegram_v1.js. This module contains logic designed to parse Telegram’s local storage and extract authentication material. The following function call, extracted from c2_agent.js, illustrates this execution:

The observed network traffic served distinct operational roles. The exploit worker transmitted browser-stage execution telemetry to vrgrt4t33[.]com/log.html via HTTP/3. Concurrently, the post-exploitation components leveraged ccsigen321qc[.]com for module retrieval, routine check-ins, task polling, and data exfiltration.

During the iOS 18.6.2 execution sequence, zLabs observed 144 HTTPS POST requests directed to ccsigen321qc[.]com, all returning HTTP 200 OK responses. This traffic profile included seven module requests, 14 /beacon check-ins, and 11 /api/task/pull requests (Figure 6).

Fig.6: Findings from the iOS 18 chain: version-specific browser code, denied directory-creation attempts from WebKit's GPU process and mediaplaybackd, a TLS handshake naming the configured destination, and subsequent module delivery, command traffic, and data uploads.

zLabs confirmed successful data exfiltration via the iOS 18 chain on a device running iOS 18.6.2. SpringBoard—the core system process responsible for managing the iOS home screen—initiated an outbound connection to ccsigen321qc[.]com. The compromised device exfiltrated an Apple Notes database file (NoteStore.sqlite) and an inventory of 214 installed applications to the C2 server, which successfully acknowledged the transfer. Following the execution sequence, zLabs also observed JavaScriptCore (Apple’s native JavaScript engine) actively running within the context of both mediaplaybackd and SpringBoard.

These findings trace the complete iOS 18 execution path from browser-staged JavaScript, through intermediate sandbox pivots in the GPU process and media subsystem, culminating in native daemon compromise and direct C2 network egress.

Part 5: Code reuse and shared delivery infrastructure

Related components of the attack chain appear across various decoy themes. Specific configurations change the campaign identifier and the tracking collector—the server designated to receive visitor telemetry (Figure 7). Certain builds, including the jiaoyou[.]eu[.]cc variant, also exhibit modifications to their module-loading routines.

The provided indicators of compromise (IOCs) detail 93 domains whose configurations map to 21 distinct tracking collectors. This shared collection infrastructure provides investigators with pivot points to trace relationships across the disparate domains.

Fig.7: Examples of website-to-collector relationships in configurations delivering the attack chain. Arrows show configured destinations for visitor reports.

What the tracking code reports

The tracking script executes within a hidden iframe. It resolves the target's public IP address via a third-party lookup service and transmits it alongside the iOS version (parsed from the User-Agent string), a campaign identifier, and a domain value. Depending on the specific build, this domain value is extracted from a URL parameter, the iframe's hostname, or document.referrer. The script transmits a telemetry beacon every ten seconds; a captured response from the collector confirms successful receipt.

These parameters enable the backend collector to correlate targets with specific campaigns and landing pages. Notably, this telemetry mechanism operates independently of the loader logic that dictates the exploit execution path. For threat hunting purposes, defenders can pivot on this specific beacon format in conjunction with known destination endpoints and Coruna code artifacts.

Following the shared code across sites

Code and configuration analysis correlates seemingly unrelated infrastructure. For instance, a specific Indonesian dating lure appears across four domains reporting to distinct telemetry collectors. Loader filenames also reused across hosting environments, although their underlying payload contents may vary between builds.

The configuration on xxtg1[.]eu[.]cc specifies the campaign identifier 1DECX7UIQIB95, whereas 66wc[.]eu[.]cc utilizes k7Xp3Rm9Qz alongside a different tracking collector. Despite these variations, both configurations reference the identical Coruna loader artifact.

Source: loader configurations on xxtg1[.]eu[.]cc and 66wc[.]eu[.]cc. Decoded configuration summary; channelCode label and site comments added.

Relying solely on the initial campaign identifier would fail to surface the second configuration. However, the shared loader hash cecd08aa6ff548c2 and the global namespace globalThis.obChTK serve as additional code artifacts. Here, the namespace refers to the global object scope under which the malicious JavaScript exposes its functions and modules.

Additional examples illustrate how connected sites share underlying delivery infrastructure:

• Shared Staging Hosts: ssc[.]vever3eds[.]com hosted loaders for multiple dating sites whose configurations pointed to distinct tracking collectors. Similarly, two adult-content portals (kjkp[.]com[.]cn and qcsh[.]com[.]cn) retrieved an identical 29,924-byte runtime via the /static/js/vendor/base.min.html path.
• Infrastructure Indicators: Historical DNS (pDNS) records link several dating lures to the IP address 5[.]255[.]61[.]234. Furthermore, an SSL/TLS certificate for commoditytrendpilot[.]site co-listed stocktrendpilot[.]net. While shared hosting and certificate Subject Alternative Names (SANs) provide initial leads, analysts should correlate them with recovered code artifacts before designating them as definitive campaign indicators.

On the comic-hosting site toongod[.]us, a script masquerading as jquery.min.js was fetched from ajax[.]googleapls[.]com—a typo-squatted domain impersonating Google's legitimate hosted library CDN. This script generated an invisible iframe pointing to a111[.]life/guard.html, which subsequently initiated the Coruna exploit chain:

Source: jquery.min.js served by ajax[.]googleapls[.]com.

Because it uses a familiar filename, this script is easily overlooked during casual audits. Website administrators can mitigate this vector by auditing third-party script dependencies and enforcing strict Content Security Policy (CSP) directives to restrict which external origins are permitted to execute code.

Recurring URI paths, hostnames, decoded payload artifacts, and configuration parameters offer valuable indicators for ongoing threat hunting. The accompanying Indicator of Compromise (IOC) appendix details these collectors and staging hosts, alongside the complete mapping of the 93 compromised domains to their respective collectors.

Part 6: Attribution and assessment

Code links to Coruna and DarkSword

Matching code artifacts provides high confidence that this exploit chain utilizes the Coruna framework.

The overlaps include an identical 29,924-byte decoded module-management runtime, the globalThis.obChTK global namespace, the static loader identifier cecd08aa6ff548c2, and specific string-obfuscation routines relying on XOR decryption. Collectively, these shared code markers establish a significantly stronger technical link than overlapping hostnames or surface-level page templates. The accompanying IOC appendix details the full runtime hash and associated module identifiers.

Furthermore, SafeDep's independent analysis of the art-template campaign identified matching loader logic and module identifiers hosted on distinct delivery infrastructure, providing external validation for the code-level attribution to Coruna.

The iOS 18 chain is DarkSword-derived and shares the primary staging host ssc[.]vever3eds[.]com with the Coruna chain. Section 4 details its underlying code base and observed dynamic behavior.

Clues about the operators

Portions of the recovered code contain inline Chinese-language source comments. Those comments describe part of the development context; operator attribution requires evidence about who deployed the code.

GTIG has previously documented the Coruna toolkit across diverse operational contexts, including commercial surveillance customers, state-sponsored espionage groups, and financially motivated threat actors. The framework's availability across multiple distinct campaigns indicates broad democratization following its initial exposure. Accordingly, the attribution in this report is strictly scoped to the underlying code base and its associated delivery infrastructure.

Part 7: Protection, detection and mitigation

For users and device owners

• Prioritize Immediate OS Updates: Maintain iOS devices on the latest software release. This is the primary technical control required to neutralize these exploit frameworks: every CVE mapped within this attack chain targets an already-patched vulnerability. The framework's entire operational model relies on the window of exposure between vendor patch release and user adoption.
• Treat "Open in Safari" Prompts as Unfavorable Indicators: Treat any unsolicited prompt directing you to reopen a link inside Mobile Safari as a stop sign. Terminate the interaction immediately and access services directly via known bookmarks, official domains, or native applications.
• Exercise High Caution Around Unsolicited Links: Delivery vectors for this campaign span online dating platforms, AI companions, cryptocurrency promotions, and TikTok preview lures. Be particularly wary of links originating from unknown contacts, new social connections, or posts promising exclusive previews, rewards, or investment returns.
• Recognize the Limits of Link Hygiene: While link caution reduces exposure, it is insufficient on its own. Coruna code has been identified as hosted on compromise-based lures (e.g., comic-reading sites) and embedded within malicious JavaScript packages where no suspicious link was presented to the user. System-level patching remains the absolute boundary control.
• Enable Lockdown Mode for High-Risk Profiles: High-profile individuals—including journalists, activists, executives, and public-sector personnel—should enable iOS Lockdown Mode. On supported, updated devices, Lockdown Mode restricts web engine capabilities and attack surfaces leveraged by browser-delivered exploit chains.

For security teams

• Enforce Compliance & OS Version Policies: Establish strict conditional access policies requiring all fleet devices accessing enterprise assets to run supported, fully patched iOS builds. Eliminate exceptions for devices that have reached end-of-life (EOL) status, establishing scheduled hardware replacement plans instead.
• Incorporate BYOD into Mobile Security Scope: Modern exploit kits operate agnostically regarding device ownership. Security policy enforcement, patch management validation, and threat visibility must extend equally across corporate-owned and Bring-Your-Own-Device (BYOD) endpoints.
• Deploy Mobile Threat Defense (MTD): Implement endpoint-level MTD solutions to gain telemetry beyond standard Mobile Device Management (MDM). MTD provides runtime visibility into web threats, vulnerable OS versions, anomalous process crashes, network irregularities, device integrity compromises, and advanced mobile spyware activity.
• Maintain Continuous Telemetry & Diagnostic Logging: Advanced exploit chains actively purge post-exploitation artifacts from disk to evade forensic detection. Security teams should establish continuous diagnostic log collection for high-risk users, international travelers, or endpoints triggering elevated threat alerts.
• Apply Multi-Layered Web Content Filtering: Enforce web filtering across managed devices to block known malicious destinations, phishing domains, and newly registered domains (NRDs). Filtering policies must inspect both native web browsers and in-app web views (In-App Browsers), where social engineering lures frequently originate.

How can Zimperium help

Zimperium Mobile Threat Defense (MTD) addresses this activity in multiple different layers.

• At delivery. Phishing Protection warns users about known phishing URLs, and Enhanced Phishing Protection can block sites classified as risky where policy requires it. Because the browser chain starts from a single page visit, interrupting that request is the highest-value intervention available.
• At exposure. The Vulnerable iOS Version and Actively Exploited iOS Version detections let teams find exposed devices and prioritise updates. An actively-exploited-version alert means the vulnerabilities on that device are being used in real attacks — which, for a kit built entirely on patch lag, is the metric that most directly predicts risk.
• On the device. MTD can flag unusual system and app crash patterns, unexpected restarts, and integrity changes including disabled iOS code signing. Given the AMFI manipulation in the Coruna chain's kernel module, that last signal is the one most closely related to behaviour we found in the code. iOS network detections look for unusually large outbound transfers and connections to countries outside a device's normal pattern.
• On follow-up. Forensics Analysis provides a manual Deep Scan for crash, system, and network anomalies, with alert reasons, app identifiers, anomaly times, and traffic or country details depending on the event. Teams can compare those findings against the indicators in this report.

Coordination

Selected Cloudflare-fronted infrastructure was reported to Cloudflare. Prior work by Google Threat Intelligence Group and SafeDep is cited throughout. Indicators of compromise will be kept up to date when new domains are found.

Indicators of compromise

Due to the complexity of the IOCs reported and in the spirit to keep them as much up to date as possible, they can be found in the following repository.

MITRE ATT&CK for Mobile Mappings

Table 1. MITRE ATT&CK for Mobile techniques relevant to the delivery methods and code capabilities described here.