{"id":2163,"date":"2026-08-28T09:42:38","date_gmt":"2026-08-28T09:42:38","guid":{"rendered":"https:\/\/www.kadam.net\/blog\/?p=2163"},"modified":"2026-09-01T14:14:18","modified_gmt":"2026-09-01T14:14:18","slug":"darksword-ad-traffic-ios-attack","status":"publish","type":"post","link":"https:\/\/www.kadam.net\/en\/blog\/advertisers\/darksword-ad-traffic-ios-attack\/","title":{"rendered":"DarkSword Reached Ad Traffic: Why a Normal Landing Page Can Hide an iOS Attack\u00a0"},"content":{"rendered":"\n

The landing pages looked normal. The way the traffic was being bought did not. Kadam’s compliance data reveals the buy-side signals behind the DarkSword malvertising cluster. <\/em><\/p>\n\n\n\n

Imagine an ordinary ad for an expensive watch. The creative looks harmless, and the landing page resembles a standard online store. Nothing on the page would necessarily raise a flag during ad moderation. <\/p>\n\n\n\n

But what a reviewer sees is not necessarily what every visitor gets. More importantly, this campaign does not require a user to click the ad at all. The exploit can be triggered when the page loads, meaning visitors can be exposed by the impression alone. This is a zero-click attack<\/strong>, and it is one of the reasons the case matters to publishers as much as it does to ad networks. <\/p>\n\n\n\n

On August 20, 2026, Kaminari Ad published a research report on a malvertising campaign delivering DarkSword, an iOS exploit chain previously associated with targeted attacks. <\/strong><\/p>\n\n\n\n

Kadam and Kaminari Ad are part of the same group of companies. The technical investigation described in this article comes from Kaminari Ad Threat Research, while the buy-side observations below come from Kadam’s compliance team. <\/em><\/p>\n\n\n\n

DarkSword is not new. Google Threat Intelligence Group documented the exploit chain earlier this year. But Kaminari found that its distribution model had changed: it had moved into ordinary paid advertising traffic<\/strong>, hidden behind seemingly legitimate websites promoting watches, trading platforms, crypto products and other offers. <\/p>\n\n\n\n

Over 11 weeks, Kaminari recorded 7,537 verified observations across 209 storefront domains and 337 rotating gate hosts<\/strong>. A storefront<\/em> is the normal-looking commercial website shown to visitors, while a gate<\/em> is the hidden script that checks the visitor’s device and determines which file it receives.<\/p>\n\n\n\n

Importantly, 7,537 observations does not mean 7,537 infected users<\/strong>. In Kaminari’s methodology, one observation is one crawl of a creative or landing page from a specific country and device profile. The number measures how widely the campaign appeared across the traffic Kaminari monitored, not how many devices were compromised.<\/p>\n\n\n\n

For the advertising industry, the important part of this story goes beyond the iOS exploit itself. It shows how malicious activity can hide behind a normal-looking landing page, avoid standard checks and use the advertising setup itself to find potential victims. <\/p>\n\n\n\n

A clean landing page does not always mean a clean campaign<\/strong><\/h2>\n\n\n\n
\"DarkSword<\/figure>\n\n\n\n

Traditional ad moderation often starts with basic checks: what does the creative show, where does the URL lead and what is there on the landing page?<\/p>\n\n\n\n

In this case, those checks could return a completely normal result. The malicious behavior was hidden deeper in the page and depended on who opened it. <\/p>\n\n\n\n

Kaminari found that the sites loaded additional resources that checked the visitor’s device before deciding which code to serve. The checks included different parameters such as the iOS version, browser, touch support and GPU.<\/p>\n\n\n\n

The gate did not simply decide whether to attack a visitor. It decided which exploit loader to serve<\/strong>.<\/p>\n\n\n\n

Real iPhones running Safari on iOS 18.4 through 18.7, with the expected touch and GPU characteristics, were routed to the DarkSword chain. Googlebot, Headless Chrome and other automated or non-matching environments were explicitly filtered out.<\/p>\n\n\n\n

But the alternative was not necessarily a clean page. In the second-generation gate analyzed by Kaminari, visitors who did not match the DarkSword profile were routed to a second exploit loader from a different exploit family<\/strong>.<\/p>\n\n\n\n

In other words, in the second-generation gate there was no benign branch<\/strong>: the gate chose which attack a visitor received. <\/p>\n\n\n\n

This is one of the most important lessons from the case: the landing page itself is no longer always the only object that needs to be moderated.<\/strong> How it behaves for different users can matter just as much as what it looks like. <\/p>\n\n\n\n

What Kadam saw from the advertising side<\/strong><\/h2>\n\n\n\n
\"DarkSword<\/figure>\n\n\n\n

An advertising platform sees a different part of the operation: how the attackers are acquiring potential victims in the first place. <\/strong><\/p>\n\n\n\n

While the activity was being investigated, the Kadam compliance team reviewed campaign behavior associated with the cluster.<\/p>\n\n\n\n

The clearest anomaly was not an increase in iOS traffic overall, but the versions of iOS advertisers were deliberately buying<\/strong>. New campaigns manually targeting only iOS versions below 18 increased from a normal baseline of zero to four per week to between 26 and 69 per week<\/strong>, roughly a twentyfold increase. At the same time, overall demand for iOS traffic did not grow.<\/p>\n\n\n\n

Advertisers had not suddenly become much more interested in iPhone traffic. A specific group of campaigns had become interested in older iPhones<\/strong>, which was a much stronger signal than traffic volume alone.<\/p>\n\n\n\n

The team also saw other characteristics repeatedly appearing together: newly registered advertiser accounts, domains that were used only briefly, iOS-only targeting and the same landing domains appearing across multiple accounts.<\/p>\n\n\n\n

Kadam’s compliance review connected 31 advertiser accounts and 310 campaigns to the cluster.<\/strong> Since June 1, those accounts had generated about $31,000 in spend<\/strong>. The largest single account spent approximately $5,500 across 2.76 million impressions<\/strong> targeting Japan, the United States, France and Turkey.<\/p>\n\n\n\n

The pattern went further. Accounts were typically registered only one to three days before their first campaign<\/strong> and funded with stablecoin deposits in fixed $100 and $200 tranches. Yet none of those characteristics crossed the thresholds that would normally route an advertiser to manual moderation. The activity had been structured to sit inside that gap.<\/p>\n\n\n\n

Once Kadam connected the accounts, campaigns and landing domains into a single cluster, the cluster was actioned as a whole.<\/strong><\/p>\n\n\n\n

None of these signals is conclusive on its own. But when new accounts, short-lived domains, iOS-only targeting and shared landing pages repeatedly appear together, the pattern changes. <\/p>\n\n\n\n

For Kadam, this is one of the most important ad-tech takeaways from the DarkSword case: security signals can exist not only inside the creative or landing page, but in the way a campaign is configured and operated.<\/strong><\/p>\n\n\n\n

Moreover, looking only at individual campaigns can be misleading. Modern malicious operations can distribute their activity across accounts, domains and campaigns so that each individual element remains relatively unremarkable.<\/p>\n\n\n\n

The pattern becomes visible at the cluster level<\/strong>.<\/p>\n\n\n\n

Kadam’s review found that shared landing domains were particularly useful for connecting apparently separate advertiser accounts. Some seemingly obvious indicators turned out to be much less useful. Seventeen accounts shared a partial authentication-IP bucket<\/strong>, which initially looked like a possible connection. But the same bucket contained 2,643 unrelated users<\/strong>, making it useless as evidence on its own.<\/p>\n\n\n\n

The payment method produced the same problem. All accounts in the cluster used the same method, but it was also the most popular payment option on the platform, used by 242 users during the same two-month period<\/strong>.<\/p>\n\n\n\n

This is an important lesson for compliance teams: effective detection is not about collecting every unusual signal. It is about identifying combinations that actually distinguish coordinated malicious behavior from normal advertiser activity.<\/p>\n\n\n\n

What this changes about ad moderation<\/strong><\/h2>\n\n\n\n

The DarkSword campaign also highlights a limitation of treating moderation as a one-time check performed before a campaign goes live. Ad moderation increasingly needs to combine content checks with behavioral analysis<\/strong>.<\/p>\n\n\n\n

The investigation also produced several concrete operational conclusions on the buy side.<\/p>\n\n\n\n

First, block by landing domain rather than by advertiser account alone.<\/strong> When several accounts share the same destination, acting on only one account allows the operation to move its budget to another.<\/p>\n\n\n\n

Second, resolve the landing-page IP during campaign moderation and compare it with infrastructure associated with already blocked advertisers.<\/strong> The IP is not sufficient evidence on its own, but it can strengthen other indicators.<\/p>\n\n\n\n

Third, move certain combinations to manual moderation before the first spend.<\/strong> In this case, a newly registered advertiser combining popunder traffic, iOS-only targeting and a free-TLD landing domain is substantially more informative than any of those characteristics considered separately.<\/p>\n\n\n\n

These findings add a behavioral layer to moderation. Creative and destination checks still matter, but campaign configuration, advertiser relationships and infrastructure can reveal intent that the landing page itself does not. <\/p>\n\n\n\n

Researchers made progress when they stopped looking only at where the landing page redirected users and instead examined the full request tree and the resources loaded by the page.<\/p>\n\n\n\n

For ad networks, this adds another layer to moderation.<\/p>\n\n\n\n

The question is no longer only: \u201cIs this landing page allowed?\u201d<\/strong><\/p>\n\n\n\n

It may also need to be: \u201cDoes the behavior surrounding this campaign make sense?\u201d<\/strong><\/p>\n\n\n\n

Security researchers and ad platforms see different parts of the attack <\/strong><\/h2>\n\n\n\n

This case also shows why cooperation between security researchers and advertising platforms is important. <\/p>\n\n\n\n

Security researchers can analyze the exploit, malicious code and infrastructure. An ad platform sees a different set of signals: how traffic is bought, which operating systems are targeted, how quickly domains change and whether the same patterns appear across multiple campaigns.<\/p>\n\n\n\n

These views complement each other. Kaminari showed what the exploit was doing; Kadam’s compliance data showed how the operators were acquiring potential victims.<\/strong><\/p>\n\n\n\n

From targeted exploit to paid distribution<\/strong><\/h2>\n\n\n\n

DarkSword was originally documented by Google Threat Intelligence Group in March 2026 as a six-vulnerability iOS exploit chain used by commercial surveillance vendors and suspected state-sponsored actors against targets in Saudi Arabia, Turkey, Malaysia and Ukraine<\/strong>.  Earlier campaigns were associated with much more targeted delivery methods, including specially prepared sites and compromised websites.<\/p>\n\n\n\n

What happened next explains how a surveillance-grade exploit chain ended up in ordinary commercial ad traffic.<\/p>\n\n\n\n

GTIG published its DarkSword research on March 18, 2026<\/strong>. On March 21<\/strong>, only three days later, the working chain appeared in a public GitHub repository and was subsequently forked hundreds of times. Kaminari recorded its first appearance in bought advertising traffic on June 11<\/strong>.<\/p>\n\n\n\n

The barrier to reuse was relatively low. The leaked components were ordinary HTML and JavaScript files that could be copied and hosted without developing an exploit chain from scratch. Once the tool became publicly available, operators no longer needed surveillance-vendor-level capabilities to use it. They needed distribution, and paid advertising provided it.<\/p>\n\n\n\n

The motive changed as well. Earlier DarkSword activity documented by GTIG was associated with espionage and targeted surveillance. In the campaign analyzed by Kaminari, the objective was financial: stealing cryptocurrency wallet data and destroying wallet-related application data after collection. <\/p>\n\n\n\n

This fits the post-leak shift described by security researchers: sophisticated mobile exploits moving from longer-term surveillance toward faster, financially motivated hit-and-run operations.<\/p>\n\n\n\n

The campaign analyzed by Kaminari represents a different model.<\/p>\n\n\n\n

Instead of choosing a particular victim in advance, attackers can buy advertising traffic and use special filtering on the destination page to decide which visitors are useful.<\/p>\n\n\n\n

The whole route of an attack changes. An attacker does not necessarily need to know who a particular user is in advance. They can purchase traffic at scale and allow the infrastructure to identify devices matching the required technical profile.<\/p>\n\n\n\n

The infrastructure was also highly disposable.<\/p>\n\n\n\n

According to Kaminari, the median lifetime of the storefront domains observed in the campaign was just 1.5 days<\/strong>.<\/p>\n\n\n\n

That creates another problem for conventional defenses. A domain reputation system can eventually identify a malicious domain, but if the operator replaces domains faster than reputation systems can classify them, a static blocklist is always working with yesterday’s infrastructure.<\/p>\n\n\n\n

The buyer’s targeting and the actual reach are not the same thing <\/strong><\/h2>\n\n\n\n

The geography of the campaign revealed another ad-tech problem.<\/p>\n\n\n\n

The five countries named in the initial escalation \u2014 Japan, India, Brazil, the United States and Vietnam \u2014 accounted for only about 20% of the observed volume<\/strong>. Great Britain was the largest market by volume<\/strong>, despite not being mentioned in the initial escalation. France and Germany were both among the top seven, while India, initially named as a key target, ranked only 25th with 71 observations.<\/p>\n\n\n\n

This gap shows how different the buyer’s configured targeting and the actual distribution of programmatic traffic can become. A buyer may believe a campaign is concentrated in a handful of countries while the inventory it purchases spreads it much further.<\/p>\n\n\n\n

It also means this problem cannot simply be pushed back onto the buy side. Once malicious advertising enters the programmatic supply chain, exposure can spread across publishers and inventory far beyond the markets the buyer appears to be targeting.<\/p>\n\n\n\n

What happens on a vulnerable iPhone?<\/strong><\/h2>\n\n\n\n

The DarkSword branch uses several iOS vulnerabilities to move from a web page toward deeper access to the device.<\/p>\n\n\n\n

The user does not need to install an application or enter a password into a fake login form to trigger the exploit process. Loading the relevant page on a matching device is enough for the delivery mechanism to start.<\/p>\n\n\n\n

The payload recovered by Kaminari was clearly financially motivated. It collected photos, notes, contacts, installed applications and cryptocurrency wallet data, maintained a shell channel, and then deleted the contents of application containers identified as cryptocurrency wallets. <\/p>\n\n\n\n

Researchers also observed a second exploit loader, separate from DarkSword. Kaminari could not map this family to any published CVE, determine which exact iOS or Safari versions it supports, or establish its current patch status.<\/p>\n\n\n\n

What they could establish is important: a current, fully patched iPhone reaching the second-generation gate is routed into this branch, and the branch attempts an exploit.<\/strong> Updating therefore protects a device from the known DarkSword chain, but it does not remove it from the campaign’s second attack path.<\/p>\n\n\n\n

If you use an iPhone: update, but don’t treat it as complete protection <\/strong><\/h2>\n\n\n\n

Keeping iOS updated is still essential. Apple has patched all six vulnerabilities used by the known DarkSword chain, closing the last of them in iOS 26.3.<\/strong> DarkSword itself has no support above iOS 18.7.<\/p>\n\n\n\n

However, the Kaminari investigation shows why being fully updated should not be treated as immunity from this particular campaign. Current iPhones are routed away from DarkSword and toward the second exploit loader, whose CVE mapping and patch status remain unknown.<\/p>\n\n\n\n

Lockdown Mode is the additional control Kaminari recommends for both paths<\/strong>, because it disables the JIT and WebAssembly surfaces this class of exploit relies on.<\/p>\n\n\n\n

The practical recommendation is therefore twofold: keep iOS fully updated and consider Lockdown Mode when stronger protection against sophisticated web-based attacks is appropriate.<\/strong><\/p>\n\n\n\n

What Kadam changed after the investigation <\/strong><\/h2>\n\n\n\n

Once the pattern was identified, Kadam quickly traced the related advertisers and blocked the entire cluster<\/strong>. The compliance team also updated moderation policies so similar combinations of signals can be detected earlier, before campaigns start spending<\/strong>, rather than only after suspicious activity becomes visible at scale.<\/p>\n\n\n\n

The findings were also shared with industry partners<\/strong> so that other platforms could look for the same patterns in their own traffic and react faster if similar campaigns appeared elsewhere.<\/p>\n\n\n\n

The DarkSword case also showed which shortcuts do not work. A shared authentication-IP range or a common payment method may look suspicious, but both produced large numbers of false positives in this investigation. The goal is not to block on more signals. It is to identify the combinations that actually distinguish coordinated malicious activity from normal advertiser behavior.<\/p>\n\n\n\n

Kadam’s compliance team connected and actioned the cluster identified in this investigation. The findings also give us a clearer framework for detecting similar procurement patterns when the next campaign does not use the same domains, creatives or exploit chain.<\/p>\n\n\n\n

The broader lesson for ad tech<\/strong><\/h2>\n\n\n\n

The DarkSword case shows how convincingly malicious activity can blend into ordinary advertising.<\/p>\n\n\n\n

A creative can look normal, a landing page can resemble a legitimate store, and a domain may have no negative reputation. Some of the strongest warning signs may not be visible on the page at all.<\/p>\n\n\n\n

Content shows what the user sees. Technical analysis shows what the page actually does. Campaign behavior shows how the operator is buying and using traffic.<\/strong><\/p>\n\n\n\n

In this case, the clearest signals came from the way campaigns, accounts and domains were connected. Looking at those signals together makes it possible to detect similar schemes even when attackers switch to different domains, creatives or exploit chains.<\/p>\n\n\n\n

Read the full technical investigation by Kaminari Ad Threat Research:<\/strong> DarkSword in the ad stack: an iOS exploit chain delivered as malvertising.<\/em><\/p>\n\n\n\n

\n
Read the full investigation<\/strong><\/a><\/div>\n<\/div>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Learn how DarkSword spread through paid ad traffic, why standard landing page checks could miss the threat, and which signals Kadam\u2019s compliance team uncovered.<\/p>\n","protected":false},"author":5,"featured_media":2164,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[2],"tags":[98],"class_list":["post-2163","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-advertisers","tag-anti-fraud"],"custom_author":"Kadam","_links":{"self":[{"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/posts\/2163","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/comments?post=2163"}],"version-history":[{"count":2,"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/posts\/2163\/revisions"}],"predecessor-version":[{"id":2180,"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/posts\/2163\/revisions\/2180"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/media\/2164"}],"wp:attachment":[{"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/media?parent=2163"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/categories?post=2163"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kadam.net\/blog\/wp-json\/wp\/v2\/tags?post=2163"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}