DarkSword: how an iOS exploit chain works and how we detect and defend against it

Context

This article supplements the situation report on the Apple threat notifications of October 2026 with the technical side. Apple has not named an exploit chain for the current wave. The best-documented iOS exploit kit of the year is DarkSword, published in a coordinated disclosure by Google Threat Intelligence Group (GTIG), Lookout and iVerify on 18 March 2026. Whether DarkSword or one of its implants is behind the current notifications is unknown. DarkSword is, however, the reference case for what an iOS exploit chain looks like, how it is delivered, how several actors use it in parallel and what traces it leaves. From that we derive the detection and hardening measures we implement for customers.

The article summarises and contextualises research by GTIG, Lookout and iVerify. It is not based on our own analysis of DarkSword samples.

DarkSword at a glance

The exploit chain

GTIG describes six vulnerabilities in four stages. Notably, the entire chain including the implants runs in JavaScript and therefore never needs to bypass iOS protections against unsigned binary code (PPL, SPTM).

The version numbers apply equally to iOS and iPadOS.

Three of the six vulnerabilities were already patched when first observed. The chain nevertheless worked for months because a relevant share of devices had not been updated. That is the key finding for patch management: success is decided not by the zero-days but by the fleet's patch level.

To be clear about scope: the P7 variant described by iVerify on 8 October 2026 is an evolved implant that is loaded after successful exploitation of the same chain. iVerify documented no new vulnerability and found no evidence that P7 can compromise patched devices. For patch assessment, the GTIG baseline therefore stands unchanged: the chain is closed with iOS 26.3 or 18.7.7. Where October coverage mentions "26.4", that refers to the current release at the time, not to the patch boundary.

Delivery

All observed actors use the same base logic, which GTIG attributes to the DarkSword developers, with their own modifications:

1. Landing page on a compromised or fake website checks via JavaScript for an iPhone running Safari (touchscreen, Apple Pay, WebGL2, absence of Chrome/Firefox objects). UNC6748 redirects Chrome traffic into Safari via x-safari-https:// because no Chrome exploit was available.
2. Session storage marker uid prevents re-infection within the same browser session.
3. Invisible iframe (1×1 pixel, off-screen) loads frame.html, which in turn loads rce_loader.js.
4. Loader selects the matching RCE worker by iOS version and fetches further stages via XMLHttpRequest. PARS Defense encrypts this transport with ECDH and AES.
5. Visitors not infected are redirected to a legitimate page (top.location.href), keeping the attack invisible to the user.

In October 2026, iVerify documented two further distribution channels: ad networks (a World Cup-themed Instagram ad infected a bank employee's iPhone with P7 DarkSword) and more than 660 expired analytics and ad-tag domains that were re-registered and loaded with exploit code. The P7 loader was also found on hundreds of PrestaShop stores in a directory disguised as analytics code. In no case does infection require a click; loading the page is enough.

Implants and their traces

Two observations for forensics. First: several implants deliberately delete crash reports. Missing crash logs are not proof on their own, since they can also be absent for ordinary operational reasons. A conspicuous gap for exactly the processes the chain uses (mediaplaybackd, WebKit) during a period of demonstrable use is, however, a reason to check the other artefacts specifically. Second: none of the documented implants is persistent. A reboot ends the infection, but not the attacker's access to data and session tokens already exfiltrated, and it destroys the volatile traces an analysis needs.

Indicators

Network indicators from the GTIG report (March 2026); full collection in the GTI Collection and at iVerify:

File: GHOSTBLADE sample 2e5a56beb63f21d9347310412ae6efb29fd3db2d3a3fc0798865a29a3c578d35 (SHA-256).

GTIG provides four YARA rules (GHOSTKNIFE, GHOSTSABER, GHOSTBLADE, DarkSword implant library paths); iVerify published domains and hashes for P7 in October. Both sources are linked below. We maintain the indicators in NEOSEC Intel and provide them to customers as a feed.

Detection and hardening

The chain runs entirely in the browser and in device memory. Traditional endpoint telemetry of the kind EDR provides on Windows or Linux does not exist on iOS. Detection is therefore possible at three other points: at the network edge, in identity logs, and on the device itself during forensic analysis.

Network layer (OPNsense, Unbound, proxy)

The network layer only reaches devices browsing through the corporate network. Mobile devices spend most of the day on cellular or third-party Wi-Fi. Network measures are therefore a complement, not a foundation.

Identity layer (Microsoft 365 / Entra ID, Google Workspace) via Wazuh

A compromised iPhone gives the attacker session tokens and keychain contents. Whether stolen tokens can be used elsewhere depends on token binding, device-bound conditional-access policies and token lifetimes; where those protections are not active, reuse is visible in identity logs. The table below describes the detection logic we are implementing as the XIEM package "Mobile Session Abuse". These are rule drafts that must be calibrated against actual telemetry in each environment; the package is in progress and not yet released.

As an example, the simplest of the six rules, an inbox rule on a VIP mailbox, based on the Wazuh Office 365 module. The VIP list is a CDB list. Set-Mailbox with ForwardingSmtpAddress is deliberately omitted here because the parameter sits in the office365.Parameters array and needs its own pre-processing.

<group name="office365,mobile_session_abuse,">
  <rule id="100700" level="10">
    <decoded_as>json</decoded_as>
    <field name="office365.Operation">^New-InboxRule$|^Set-InboxRule$</field>
    <list field="office365.UserId" lookup="match_key">etc/lists/vip-mailboxes</list>
    <description>M365: inbox rule changed on VIP mailbox ($(office365.UserId), $(office365.Operation), source $(office365.ClientIP))</description>
    <mitre>
      <id>T1114.003</id>
    </mitre>
    <group>pci_dss_10.6.1,gdpr_IV_35.7.d,</group>
  </rule>
</group>

The rule is a draft: field names apply to the Wazuh Office 365 module in version 4.x, the vip-mailboxes list must be created and registered in ossec.conf, and the level is deliberately high because inbox rules on VIP mailboxes are rarely changed legitimately by script. The other five rules require time-window correlation (impossible travel, bulk download) or enrichment (ASN classification) and therefore cannot be expressed as a single rule.

In every case, the prerequisite is that these log sources reach the SIEM at all. For most customers we take over, this is the case for Entra ID sign-in logs but often not for the unified audit log.

Device layer (MDM and forensics)

What limits detection

Security apps on iOS run in the same sandbox as every other app and can see neither into other processes nor into the kernel. Products such as iVerify therefore do not scan in real time; they analyse sysdiagnose archives and configuration and detect traces of an infection after the fact, not the exploit at the moment of execution. That is useful, but it is not prevention.

TLS inspection at the perimeter is technically possible for ordinary Safari traffic on managed devices with an enterprise certificate installed; certificate pinning mainly affects Apple's own services and individual apps, not the web in general. It nevertheless helps little against this chain: mobile devices are outside the corporate network most of the time, delivery runs over legitimate ad and CDN infrastructure, and the exploit code is obfuscated and changes with each campaign. Without current signatures for the loader, inspection produces no hits.

Two measures prevent the attack itself: a patch level that closes the exploited vulnerabilities, and Lockdown Mode, which blocks the JIT-based RCE stages. Everything else limits the damage or makes it visible afterwards.

Concrete support

For customers and prospects, we offer three services that follow directly from this analysis:

• Executive Exposure Check. Structured inventory of which people around management belong to the target set of mercenary spyware, which devices and accounts they use, and which information has been shared with them over uncontrolled channels. Deliverable: risk matrix and action list. One to two days.
• Executive Device Hardening. Lockdown Mode, MDM compliance, channel separation and travel rules for management and key personnel, including briefing. Two hours per person.
• Mobile IR Retainer. Defined reporting path for Apple threat notifications, forensic preservation and MVT analysis within 24 hours, replacement-device process, support in assessing the reporting obligation under § 32 BSIG. As an extension of existing DFIR retainers or standalone.

For SIEM customers, we roll out the Unbound blocklist with DarkSword, Coruna and P7 indicators as part of ongoing operations. The XIEM package "Mobile Session Abuse" follows once calibration is complete.

Limitations

This article summarises the analyses by GTIG, Lookout and iVerify and derives measures from them; it is not based on our own reverse engineering of DarkSword samples. The detection logic in the identity section is a concept with one example rule, not a tested rule set. Patch decisions should be made against your own device fleet, not adopted wholesale. This article was produced with AI assistance and editorially reviewed (Art. 50(2) AI Act).