660 Dead Domains Later, DarkSword Lands on Employee iPhones Through an Ad Nobody Clicked

1.07 iOS infections per 1,000 devices. That is the number iVerify publishes at the conservative end of its own range in the 2026 Advanced Mobile Threat Report, and it works out to about one in 900 of the consumer iPhones it scans carrying signs of spyware. Roughly three quarters of those detections are criminal rather than state-sponsored, after credentials and cryptocurrency. In every enterprise case iVerify confirmed against a criminal actor, the person holding the phone sat at or below managing-director level.

One of those infections began when an advertisement finished loading. The employee was scrolling Instagram, a World Cup ad served from ad-track[.]live rendered, and a DarkSword variant started running on the handset. No tap on the ad, no download, no configuration profile. iVerify and Report URI call this a half-click attack, because the only action required of the victim is to keep scrolling.

Relevance verdict. Two things decide whether this is your problem. The first is the iOS build number on every phone that opens company mail. The published Coruna chains cover iOS 13.0 through 17.2.1; the DarkSword chain iVerify tracked covers 18.4.0 through 18.7.2. If every one of those handsets is on 26.7.3 or 27.2.1, the builds Apple shipped on November 9, the published chains do not reach them and the next two sections are background. The second is the HTML you publish. If any page on your own site loads a script from a domain nobody at your company can name the owner of, you have a job this week regardless of what your phones are running. Everything below is organised by which of those two surfaces you actually control.

What leaked in March, and what it costs to use now

Google's Threat Intelligence Group published Coruna on March 3, 2026: a few hundred samples carrying five complete iOS exploit chains, 23 exploits between them, covering iOS 13.0 through 17.2.1, including non-public exploits and mitigation bypasses. Google found it hosted on a large set of fake finance-themed sites, delivered by a hidden iframe that fired as soon as an iOS device loaded the page. The kit has been linked to a financially motivated group and to suspected Russian espionage activity tracked as UNC6353, and some of the vulnerabilities it carries had previously been tied to Operation Triangulation.

Two weeks later Zimperium zLabs described DarkSword as the successor, built for iOS 18.4 through 18.7 and run as a hit-and-run operation. It escapes the browser, pivots through graphics components, compromises the kernel, runs entirely in memory, steals messages, wallets and authentication material, then erases its own traces. It installs no binary implant. Zimperium's first clusters were in Ukraine, Saudi Arabia and Turkey.

Then the code got out. A newer version of DarkSword appeared on GitHub within about a week of the March disclosure, and criminal groups forked it. One of those forks, which iVerify labels P7, is the variant it pulled off a financial institution employee's phone. The exploit engineering is excellent and it is no longer the interesting part. What changed is the distribution model: a chain built to be spent carefully against selected targets is now sprayed across ad inventory, where one more attempt costs whatever one more impression costs.

The delivery channel grew out of dead JavaScript

The mechanism that made volume possible has nothing to do with iOS. Report URI's Scott Helme traced an operation called DeadTag, reported this week, that buys expired domains which once served analytics and advertising tags. Thousands of sites still carry those tags in their templates, so every visitor's browser dutifully fetches whatever the new owner decides to serve. Report URI counted more than 660 re-registered domains in the network and estimated the traffic reaching them at about 135 million visits a month.

The injected script does not deliver a payload directly. It calls a server that decides where each visitor goes, and the filtering is the clever part: search engines, security scanners, headless browsers and anything else that smells automated receive nothing at all. Real iPhones on vulnerable builds get the exploit through the browser. Everyone else gets a casino sign-up page, a fake survey, or a search ad for a dentist. This is why the scan you ran against that page came back clean, and why it will keep coming back clean.

Zimperium's count through October 2026 was 608 domains serving Coruna-family code, with routing decided by version: handsets on 17.2.1 or earlier get the legacy Coruna framework, later builds get the DarkSword-derived chain. Several of those domains belong to legitimate sites that were compromised and now serve the kit through a hidden iframe. zLabs also documented a Telegram module built to pull authentication material straight out of local storage, and one Coruna payload that searched text and images on the device for wallet recovery phrases.

The phones you manage

The gate is the build number, not the model or the age of the handset. An iPhone 15 left on 18.6.1 is in the DarkSword window; an iPhone XR updated to 26.7.3 is outside both. So the first query is an inventory one, and in Intune it is one call away.

# Managed iOS devices and the build each one is actually running.
# Needs DeviceManagementManagedDevices.Read.All.
az rest --method get \
  --url "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?\$filter=operatingSystem eq 'iOS'&\$select=deviceName,osVersion,userPrincipalName,lastSyncDateTime" \
  | jq -r '.value[] | [.osVersion, .deviceName, .userPrincipalName, .lastSyncDateTime] | @tsv' \
  | sort -V

# Anything that sorts below 17.2.2 is in the Coruna range.
# Anything from 18.4.0 to 18.7.2 is in the DarkSword P7 range.
# The 18.7 line is now at 18.7.12; current releases are 26.7.3 and 27.2.1.

What to do with the result

• Devices inside either window. Push the update and set a compliance deadline short enough that the device goes non-compliant before the next payroll run, rather than a grace period measured in weeks.
• Devices that cannot leave the 18.7 line. 18.7.12 shipped on November 9 and sits above the top of the published P7 range. That is the floor, and it is not a substitute for moving the handset onto a supported major version.
• Devices with no recent sync. A phone that has not checked in for a month is reading company mail with an unknown build. Treat an empty lastSyncDateTime as a finding, not a gap in the report.

One trap worth knowing before someone suggests it in a meeting. Apple's Lockdown Mode documentation is explicit that a device in Lockdown Mode cannot install configuration profiles and cannot enrol in MDM or supervision. You get one or the other on a given handset. For the two or three people whose phone is genuinely worth a chain, Lockdown Mode without enrolment is a defensible trade. For everyone else, enrolment with an enforced minimum build is the better deal, because it is the control that keeps working after the person stops thinking about it.

The phones you do not manage

Most companies under 200 people have no MDM at all. Staff read company mail in the native Mail app on a phone they bought themselves, and the security team, which is usually one person who also runs the network, has no inventory. You can still read the build, because every sign-in writes it down.

// Entra ID sign-in logs: which iOS builds are reaching your tenant,
// bucketed against the two published exploit windows.
SigninLogs
| where TimeGenerated > ago(30d)
| extend os = tostring(DeviceDetail.operatingSystem)
| where os has_any ("Ios", "iOS", "iPhone", "iPad")
| extend build = extract(@"(\d+(?:\.\d+){0,2})", 1, os)
| where isnotempty(build)
| extend v = parse_version(build)
| extend window = case(
    v <= parse_version("17.2.1"), "Coruna range",
    v >= parse_version("18.4.0") and v <= parse_version("18.7.2"), "DarkSword P7 range",
    "outside the published ranges")
| summarize signins = count(), people = dcount(UserPrincipalName),
            apps = make_set(AppDisplayName, 5) by build, window
| sort by window asc, signins desc

The OS string in those logs is coarse and sometimes stale, so treat the output as a population estimate rather than an asset register. It is still enough to answer the only question that matters this week, which is whether anybody is signing in from a build inside either window. Where the answer is yes, an Entra Conditional Access policy with an app protection requirement will set a minimum OS version for the apps you control, and it will do nothing about Safari, which is where the exploitation happens.

Be honest with yourself about detection on these devices. There is no agent, so your signal is a user telling you the phone ran hot and Safari crashed repeatedly, backed by the crash logs Zimperium names as the artefact to pull, including WebKit and mediaplaybackd. iVerify's finding is harsher still: traces age off these devices quickly, a reboot or a software update can remove the running malware along with the evidence, and to the researchers' knowledge no device with a confirmed DarkSword or Coruna infection has received an Apple threat notification. Waiting for Apple to tell you is not a detection strategy, and it was never advertised as one.

The tags on your own website

This is the surface nobody audits, and it is the one a small business can fix completely in an afternoon. If your marketing site still references a tag from a vendor that shut down three years ago, the domain is a DeadTag candidate and your visitors are the traffic. Enumerate the origins first.

#!/usr/bin/env bash
# Every third-party origin a page loads a script from, with the registration
# date of the domain serving it. A creation date much newer than the tag
# itself is the DeadTag signature.
SITE="https://example.com"

curl -sL "$SITE" \
| grep -oE '<script[^>]+src="https?://[^"]+"' \
| grep -oE 'https?://[^/"]+' \
| sed -E 's#https?://##' \
| sort -u \
| while read -r host; do
    created=$(whois "$host" 2>/dev/null \
      | grep -iE '^[[:space:]]*(creation date|created|registered on)' \
      | head -1 | cut -d: -f2- | tr -d ' ')
    printf '%-42s %s\n' "$host" "${created:-NO WHOIS RECORD}"
  done

Run it against every template you publish, not just the home page, because the tag that outlived its vendor is usually sitting in a footer include. Then work the output in this order. Delete every origin nobody can name a current owner for; a tag whose vendor is gone is doing no work and carries all of the risk. Pin what remains with subresource integrity where the vendor publishes a stable file. Then add a Content-Security-Policy with an explicit script-src allowlist and a reporting endpoint, so the next time an unexpected origin appears in one of your pages it arrives as a report in your inbox rather than as a payload in a visitor's browser.

Read the build number off every phone that opens company mail

Do the inventory today and finish it this week. Pull the builds from Intune if you have it and from sign-in logs if you do not, list every handset inside 13.0 to 17.2.1 or 18.4.0 to 18.7.2, and get those people updated before you spend another hour on policy. Then run the script audit against your own site, because the same operation that reached that employee's phone through an Instagram ad is reaching other people's phones through websites whose owners have no idea they are hosting the first stage. Both jobs are small. Neither one gets done by the person who is already handling the printer and the firewall rules, which is exactly why they have not been done yet.

The part we get asked to help with is rarely the patching. It is building the mobile inventory in the first place for a company that never enrolled a phone, and then answering the question that follows a suspected infection, which is whether anything of value left the device before the user rebooted it and destroyed the evidence.