Originally published on the Kaminari Ad blog. Kaminari Ad is an ad quality and security platform for publishers and ad networks — this kit is what its malvertising protection now flags on every scan.
This is a condensed version of our report. The full DarkSword report covers how the cloaking gate fingerprints visitors, the second exploit loader served to patched iPhones, the storefront layer, buy-side indicators, C2 and telemetry hosts, file hashes and an FAQ.
The findings in brief
- An iOS exploit chain built for targeted espionage is being delivered through ordinary paid ad inventory, at scale, to whoever happens to see the ad.
- The chain is DarkSword, documented by Google in March 2026. Three days after that report it was leaked to a public GitHub repository. We first saw it in bought ad traffic eleven weeks later.
- 7,537 observations across 209 storefront domains and 337 rotating gate hosts, running for eleven weeks, present in the traffic of roughly 15% of active accounts on our platform.
- The payload is financially motivated, not espionage: it steals cryptocurrency wallet data, then deletes the contents of the wallet apps' own containers.
- No click is required — it runs on page load. Updating closes the DarkSword branch, but a second exploit loader, which we could not map to any published CVE, is what a current iPhone gets served instead.
- We shipped a detection on 20 August 2026. It covers every customer on the platform, applies retroactively to historical traffic, and lands on scan reports you can hand to a partner.
- The invisibility will not last. When browser blocklists and reputation systems react to a campaign this size, they do not excise one sub-resource — they flag whole domains and the properties serving them. Whoever is still carrying it then wears the reputation hit.
The campaign in numbers
Measured from our own crawls of live ad traffic, as of 2026-08-20 11:39 UTC:
| Figure | What we measured | Why it matters |
|---|---|---|
| 7,537 | verified observations, earliest 2026-06-11 | Running at scale for weeks, not a one-off test |
| 209 / 337 | storefront domains / cloaking-gate hosts, rotating continuously | A domain blocklist cannot keep up with this |
| 1.5 days | median storefront-domain lifetime | A blocklist is stale before it ships |
| 212 | advertiser brands, 22 impersonating real companies | Identities are disposable; real brands are used as bait |
| ~15% | of active accounts on our platform had it in their traffic | Not a niche edge case — it is widespread |
| 2 | separate exploit families served, by device | A patched phone is routed to a different attack, not to safety |
One clarification before these numbers get quoted. A "scan" is one crawl of one creative or landing page from one country on one device profile. It measures how widely the campaign was running across the inventory we see. It is not a count of infected people, and nothing here should be read as one.
Detection status: covered since 20 August
Start with the uncomfortable part. According to the networks that reported this to us, none of the tools they had in place flagged this during the period we observed it, June to August 2026 — neither their antivirus engines nor their other ad-verification vendors. That is their assessment of their own tooling at that time, not a claim we have tested on their behalf, and not a statement about what any vendor detects today — but it is consistent across more than one report, and it is consistent with how the kit is built: the storefront breaks no content policy, and the exploit never appears as a navigation hop for a URL-based check to catch.
On 20 August 2026 we shipped a detection for it. Every page we scan is now checked for this kit's delivery infrastructure and, when it is present, the scan is tagged iOS Browser Exploit Attempt at high severity.
Three properties of that detection matter more than its internals:
- It is global. The tag applies to every organisation on the platform, not only the account that reported the problem. Networks working with us are covered, and so are the publishers and advertisers downstream of them.
- It is retroactive. It was applied to historical traffic as well as new scans, so the back catalogue was re-evaluated rather than just everything from today onward.
- It is public. The tag appears on shareable scan reports, so a network can show a partner or an advertiser the evidence without handing over an account.
We are deliberately not publishing the exact pattern or its bounds. This operator rotates domains inside two days and gate hosts inside a fortnight; a rule published in full is a specification for evading it. What we do publish is the indicator set below, and any network can build its own equivalent from it — those are observable properties of the kit, which the operator already knows it has, rather than properties of our detection.
One point of precision, since the tag name is deliberate: it says attempt. What we observe is a page reaching out to this kit's delivery infrastructure. We do not execute the exploit chain, and we do not claim any particular device was compromised. Delivery is what we detect, and delivery is what we report.
Gate fingerprints — block on these
| Fingerprint | Type | Notes |
|---|---|---|
/gooll/gooll.html |
URL path | generation 1, hosted on the landing domain itself |
/expires/expires.html |
URL path | generation 2, loaded cross-origin |
^rk\.[a-z0-9]{12,20}\.icu$ |
host pattern | generation 2 delivery hosts |
/expires/rce_loader.js |
URL path | exploit chain entry point |
/expires/rce_worker_18.4.js, /expires/rce_worker_18.6.js
|
URL path | RCE stages |
/expires/rce_module.js, /expires/rce_module_18.6.js
|
URL path | RCE stages |
/expires/sbx0_main_18.4.js, /expires/sbx1_main.js
|
URL path | sandbox escapes |
/pe_main.js |
URL path | privilege escalation; match only alongside the above |
32- or 40-hex .js under /expires/
|
URL pattern | rotating payload names, both families |
Hostnames rotate within days; these paths have held for two months. C2 hosts, generation-2 delivery hosts and SHA-256 hashes for every stage are in the indicators of compromise section of the full report.
What to do about it
If you run an ad network or exchange. Match the gate paths and the host pattern across the entire request tree of a landing page, not just its redirect chain. A domain blocklist built from this report will be stale within days; the fingerprints have held for two months. Treat a page that loads /gooll/gooll.html, or anything under /expires/ from a random .icu host, as malicious regardless of what the page itself contains. On the advertiser side, the buy-side indicators above catch this before the first impression rather than after. If you already scan with us, none of this is work you need to do — the tag fires on every scan, retroactively included.
If you run a site that carries third-party ads. The exploit does not need a click. It runs when the page loads on a vulnerable device, which means your visitors are exposed by the impression alone. Sub-resource review matters more than landing-page review here, and "the creative looked fine" is not a defence you can rely on.
If you carry an iPhone. Update, and do not treat being up to date as immunity here. Updating closes the DarkSword branch outright: all six of its vulnerabilities are patched as of iOS 26.3 and it has no support above 18.7. But the second loader is what a current device gets handed instead, we have no patch status for it, and it attempts an exploit regardless of version. Lockdown Mode is the meaningful control on both paths, because it disables the JIT and WebAssembly surfaces this class of chain is built on.
Read the full report: DarkSword in the ad stack: an iOS exploit chain delivered as malvertising — technical anatomy, the complete indicator set and the buy-side indicators that catch this before the first impression.
Top comments (0)