Sekoia says APT29 watering holes used patched iOS and Android flaws, one route via a compromised tracker

A one week tracker window that closed 62 days before the write-up, and a scale given two ways

Sekoia says a Ukrainian web analytics tracker, Plerdy, was modified from 27 August to 3 September 2026, a window of 7 days (derived), and that the visitors of the sites loading it were exposed to an exploit kit for that week. Sekoia published its account on 4 November 2026, 62 days after the window closed (derived). Its own post gives the scale of the exposure two ways: "hundreds of legitimate websites" in the introduction, and "thousands of websites, the large majority of them Ukrainian" in the section on the tracker. The post does not reconcile the two.

This briefing reads Sekoia's post, dated 4 November 2026, in full, from its introduction to its indicators section, on 4 November 2026, from 11:11 UTC. BleepingComputer's report of the same day was read as a secondary source and checked line by line against it. Google's March 2026 report on DarkSword and its August 2024 report on an earlier set of watering hole attacks, the National Vulnerability Database records for eight CVE ids, and Apple's security pages were read to test what the post says about fixes and history. Sekoia sells security operations and threat intelligence products, and says its Threat Detection and Research team found this in its own research. The attribution to APT29 is Sekoia's assessment, with the confidence level it states.

What the tracker window does not establish matters as much as the dates. It does not say how many devices were exploited, who the victims are, or what became of the cookies and device data the chains took. It does not say how the tracker was broken into. In the introduction Sekoia writes "we assess" that the intrusion set carried out that compromise, while the section on the tracker states it without that word, so the confidence attached to the tracker route is the looser one. And a site that loaded the tracker is not a phone that was exploited: the post says a delivery server received requests from many sites, not how many visitors were served a chain.

The angle is that the only interaction is the visit, and that every flaw is old. Sekoia says all three chains "rely entirely on known, already-patched vulnerabilities", and that none works against a fully updated device. So the exposure is a phone or browser that had not updated, plus iPhone 8 and iPhone X class phones that stop at iOS 16.7, where this briefing could not find a fix on the record (set out below, and this site's reading, not Sekoia's). What is new is the delivery: three routes in, one profiling script, platform specific chains, cloned sites and a tracker script. The purpose Sekoia describes is cookie and data theft that, in its words, may allow reuse of authenticated sessions and access to webmail. That is how Sekoia describes the risk: a mobile visit that can end in account access.

What Sekoia says it found

Sekoia says its team uncovered, in mid October 2026, a large scale watering hole campaign involving compromised or cloned websites in the United States, Ukraine, the Czech Republic and Bulgaria. "High profile" is Sekoia's phrase for the sites. Its conclusion adds an Australian medical clinic to the compromised sites, so the four countries in the introduction are not the whole list. The investigation began with a detection of a malicious script inclusion on the site of a Ukrainian gas production company, which led Sekoia to the delivery server.

Three routes lead to one payload. Sekoia says the three infection vectors, direct injection on legitimate sites, lookalike domains and the tracker, all deliver a code injection that loads an external script to profile the visitor's browser and device. The delivery host then uses the mobile and browser version to serve one of three exploit chains for iOS or Android, "without user interaction". The interaction is the visit itself: nothing is tapped or downloaded, but the page has to load. Sekoia says the final payloads take cookies or full device data from iPhones, and Chrome data and Wi-Fi settings from Android phones, without establishing persistence.

Zoom

Sekoia says it is coordinating with the CERTs of the affected countries to help identify victims and to assess options for disrupting the infrastructure. It thanks CERT-UA and Google's Threat Analysis Group for help, the second for identifying the exploits and CVEs. It names no victim organisation as a confirmed device compromise and gives no count.

Three routes in, and who Sekoia says was hit

A note on the two named sites, and on Plerdy. These are Sekoia's reports that the sites were cloned and that the tracker was modified. They say nothing about the security of America250, Raffles London at The OWO or Plerdy, and this briefing makes no claim about it or about how any of them responded; the post says nothing on either point. The cloning method is an adversary in the middle approach, which Sekoia calls "AiTM like": a visitor is relayed to the real site through the copy, so the page looks right while an extra script rides along.

On the tracker, Sekoia cannot say what the intruders wanted. It writes that it remains unclear whether they meant to reach the visitors of specific sites or to infect as many unpatched phones as possible and pick through the data afterwards. Its conclusion offers two readings: an alternative delivery vector after direct injection failed on specific Ukrainian targets that used the Plerdy script, or a wider net. It does not choose between them. The "hundreds" and "thousands" figures may describe different things, sites exposed against sites that loaded the file, but the post does not say so, and BleepingComputer repeats the larger figure.

One profiling script, and a fingerprint that Sekoia says steers almost nothing

The script all three routes load is named UltimateFingerprinter by the intruders, per Sekoia. It is about 2.3 MB, of which roughly 98 per cent is a minified copy of a well known JavaScript library appended as dead code. Sekoia offers two possible reasons, without choosing: to hinder automated analysis by language models by exceeding their context window, or to look legitimate by sitting inside a familiar library.

It gathers 394 fields from 61 collectors: classic device fields such as canvas, audio and fonts; sandbox checks such as sensors, battery and network timing; Apple specific features; and newer web interfaces such as USB, Bluetooth and payment. The values go to a second address containing a random nonce, which returns exploit code if the submitted data meets the attacker's criteria.

Then comes the part that deflates the 394. Sekoia writes that, despite all the fields collected, "the fingerprint has almost no effect on exploitation delivery". Only three values can block it: an implausible screen width or height, such as 99999, or a touch point count of zero, meaning a device with no touchscreen. In those cases the host returns an empty successful response and serves nothing. Sekoia says the purpose of the extensive fingerprint remains unclear, and that it saw no evidence the data influenced delivery or was reused later in the chain. The platform chosen does depend on the operating system and browser version, which the delivery host checks, so the picture is: version decides the chain, the rest of the fingerprint is collected and, as far as Sekoia saw, not used.

Three chains, the versions they target, and what each takes

Sekoia tested different browser profiles against the fingerprinting endpoint and retrieved three complete chains, which it calls A, B and C. The post does not say whether other profiles would receive other chains.

Four more CVE ids appear in the post but are not used: CVE-2024-27808 and CVE-2024-27833 remain in chain A as dead, unreachable code, probably from an earlier version of the kit, and CVE-2025-31277 and CVE-2025-24201 are offered by the DarkSword kit as an alternative entry and an alternative escape that this delivery does not use. Sekoia says these four are not used in this delivery.

Two operational details bear on how far the damage goes. The iPhone chains set a marker cookie to stop a second infection on the same phone, but Sekoia says a miscalculation makes it expire after one minute rather than one day, so only a very quick repeat is prevented. The Android chain has no such check. And Sekoia says none of the payloads establishes persistence. That is the post's wording; it does not say a restart would end the activity. BleepingComputer adds that inference. It is plausible, but it is the news report's step, not the post's.

Every flaw has a fix on the record, but not every phone has a fix listed

Sekoia says each flaw was resolved by its vendor before the campaign began. The National Vulnerability Database (NVD) records, read on 4 November 2026, show all eight CVE ids in the three chains were published before the tracker window opened, and seven name a fixed version; CVE-2025-27038 names none. The newest record is CVE-2026-3910 in Chrome, published on 13 March 2026, 167 days before the window opened (derived), and the newest iOS one is CVE-2026-20700, fixed in iOS 26.3 and published on 11 February 2026, 197 days before (derived). The oldest is CVE-2024-27834, fixed in iOS 16.7.8, which Apple's list dates to 13 May 2024, 836 days before the window opened (derived).

Chrome is the simplest case. Chain C targets Chrome 139 to 145, and NVD names 146.0.7680.75 as the first version free of CVE-2026-3910, so the whole targeted range sits below the fixed version (derived). Because Sekoia describes the chain as starting with that Chrome flaw, a phone on a fixed Chrome should not get past the first stage; that is this site's inference from Sekoia's staging, not a test. The Adreno flaw is a separate, device level driver fix, so the Android patch level matters too. The iOS chain B flaws were fixed in the 2025 and early 2026 builds that this site read in its earlier briefing on the DarkSword kit and its six flaws, which also covers which iPhone models stopped at an iOS 18 build.

Now the gap, and it is this site's reading of the records, not Sekoia's. Apple's own list, read on 4 November 2026, shows iOS 16.7.16, released on 11 May 2026, for the iPhone 8, iPhone 8 Plus and iPhone X, the line chain A targets. The security notes for iOS 16.7.15 and iOS 16.7.16 list one CVE each, and neither is CVE-2025-43529 or CVE-2024-27834. The list shows no published CVE entries for iOS 16.7.13 and 16.7.14. NVD names no iOS 16 build for CVE-2025-43529. So for those phones this briefing found no Apple entry naming a fix for the flaw chain A uses for code execution. That is not proof that none exists, since Apple can ship a fix without listing it, and Sekoia says an up to date system is safe. It is the reason the first checklist item is not just "update".

A second thing this briefing cannot reconcile. NVD says CVE-2024-27834 was fixed in iOS 16.7.8, dated 13 May 2024 on Apple's list. Sekoia says the delivery host for chain A filters for iOS 16.7 and 16.7.10, and Apple's list dates iOS 16.7.10 to 7 August 2024, 86 days after 16.7.8 (derived). The post does not say whether chain A works on a build from 16.7.8 onward, and nothing read here tests it, so the question stays open.

DarkSword: what Sekoia says, and what BleepingComputer adds

Sekoia calls DarkSword a suspected Commercial Surveillance Vendor developed iOS exploit kit, uploaded to VirusTotal in September 2026. It says chain B "is DarkSword", compared against that uploaded kit and a public analysis of it, and that chain A reimplements the kit's code execution flaw and keeps two other flaws as leftover dead code. It adds that the evidence points to a third party supplying the exploits: chain A's host filter covers only iOS 16.7 and 16.7.10, though the exploits work from 16.0 to 17.4, which Sekoia reads as operators reusing code without tuning it.

BleepingComputer writes that DarkSword was "first documented in March" and used "since at least November 2025 by multiple threat groups". Neither statement is in Sekoia's post. They match Google's report of 18 March 2026, which says that since at least November 2025 it has seen multiple commercial surveillance vendors and suspected state sponsored actors use the chain, against targets in Saudi Arabia, Turkey, Malaysia and Ukraine, for iOS 18.4 through 18.7. The dates describe different events: first public documentation (18 March 2026, per Google) and an upload of the kit to a malware sharing service (September 2026, per Sekoia). Google also describes a cluster it tracks as UNC6353, which it calls a suspected Russian espionage group, using the kit on compromised Ukrainian websites through March 2026. Sekoia's post does not mention that cluster, and this briefing draws no link between it and APT29. The kit and its history are in this site's earlier briefing on DarkSword and its fixes.

The practical consequence is the one Sekoia states in its conclusion as an assessment: packaged exploit chains from the surveillance industry lower the cost of advanced mobile attacks for state backed groups, and Sekoia expects reuse to become more frequent. It is a forecast, and the post gives no data on how many groups hold the kit.

How Sekoia reaches APT29, and how much weight each piece carries

Sekoia assesses with moderate to high confidence that the campaign was run by APT29, "or at least one of its subgroups". APT29, Midnight Blizzard, Cozy Bear and The Dukes are names for one intrusion set that Sekoia says is widely attributed to Russia's Foreign Intelligence Service (SVR). These are labels with a stated confidence. The post does not say that any government or agency has attributed this campaign, and a reader should keep the label and the confidence together.

Zoom

Read as a whole, the case is a set of overlaps and consistencies, with one piece nobody outside can test. Sekoia states a confidence level for each step it assesses, and hedges the actor as "at least one of its subgroups". Sekoia's conclusion also notes that no single sector pattern emerges across the directly compromised sites, which it says complicates a strategic reading, and that it lacks visibility of the targeting intelligence that may have chosen them.

The dates in the post, and what is not dated

Zoom

Taking mid October as roughly the 15th, which is an assumption because the post gives no day, the tracker window had closed about six weeks before Sekoia says it uncovered the campaign (42 days, derived), and the post followed about three weeks after (20 days, derived). Sekoia says it found the tracker route in the course of analysis, after first seeing requests to the delivery server from numerous sites, which suggests (this site's inference) a reconstruction after the event, not a live observation. The delivery domain was created on 2 April 2026, 147 days before the window opened (derived), so some infrastructure existed for months before the tracker was touched. The post does not date when any chain first served a victim.

What the post states, and what it does not

Where the coverage and the post differ

BleepingComputer's report is accurate on most points and was used as a pointer, with the post followed wherever they differ. Six differences are worth knowing before the news version is repeated.

Four friendly names

"Zero click" suggests that nothing needs to happen. Something does: a phone has to load a page carrying the script. The phrase describes the absence of a tap on a malicious link, which is the main thing a user can control, but it does not mean the user did nothing.

"N day" sounds like the comforting kind of flaw. It means a flaw with a fix already available, and Sekoia's reading is that the campaign targets devices that have not updated. It is true as far as the flaws go and says nothing about a phone that cannot take the fixing release. "High profile" is Sekoia's phrase for the cloned and compromised sites; it is a description, not a count. And "an up-to-date operating system is safe from these attacks" is Sekoia's statement about these three chains, a vendor's finding, not a guarantee about the next flaw. It was not tested here.

What to do, in the order worth doing

Items 1 and 5 follow what Sekoia's post says. The others are this site's suggestions, drawn from the post's facts, and are labelled so.

Technical details

Sekoia's post prints indicators: two lookalike domains, three delivery and exfiltration hosts with addresses, file and path names, and SHA-256 hashes of the stages. It says it withholds the rest of its indicators, its YARA rules and details of compromised websites, which are in its own product and available to national CERTs and law enforcement bodies under TLP:AMBER. The post prints no detection query, no rule and no hunting command, so none is given here. Everything below is copied from the post and defanged as Sekoia defanged it: do not browse to any of it. A defender searches DNS, proxy and web server logs and site files for these strings, and blocks them at the resolver or gateway. No code, script or payload from the post is reproduced.

The two lookalike (adversary in the middle like) sites and the delivery domain each pointed to, as Sekoia's indicators table prints them. The creation dates are printed day first.

Domain                 Created      IPv4              Hosting provider      Malicious delivery domain
theowo[.]club          18/06/2026   188.190.17[.]232  EDIS GmbH (AS57169)   static.flux-telemetry[.]com
america250[.]holiday   19/05/2026   192.121.46[.]25   EDIS GmbH (AS9009)    adsprism-stat[.]com

The delivery and exfiltration hosts. The two Shock Hosting entries share an autonomous system number. The post's text says the tracker redirect host forwarded requests to the other delivery hosts listed in the next block.

Domain                        Type          Created      IPv4              ASN       AS name
static.flux-telemetry[.]com   Delivery      02/04/2026   109.104.106[.]107  AS395092  Shock Hosting LLC
edge-ord.clouds-stacks[.]com  Delivery      26/08/2026   95.133.231[.]28    AS219399  servinga GmbH
ad.starx-net[.]com            Exfiltration  03/04/2026   195.58.140[.]105   AS395092  Shock Hosting LLC

Strings to search for in site files, proxy logs and web server logs. The tracker file path is the one Sekoia says was modified; a legitimate copy would not point to another host. The marker cookie is set on the visitor's phone by the two iPhone chains, so a defender is unlikely to see it, and it is listed because Sekoia names it.

Tracker file the intruders modified:   a.plerdy[.]com/public/js/click/main.js
Fingerprinting script file name:        5b4c8fea5cbcee273e8d830f52-temfp.js
Other delivery hosts named in the text: ads-it-assets[.]com, cdn.adv-static[.]com, wpvortex-mod[.]com, assets-int[.]com
Exfiltration endpoint (port and path):  ad.starx-net[.]com:8881/telemetry/v12
Marker cookie set on iPhone chains:     VDGH_TOKEN_REF
Android model code that stops chain C:  SM-S938B

SHA-256 hashes of the stages, as Sekoia's indicators table lists them. The post's body also prints different hashes for some of the same stages, without explaining the difference: for Class B /v1 and /v2, and for the two Class C variants. Both sets are shown so a hunt can search for either.

a7d2493df00565c21587b0cad2a9fe7ca1e5590acf796da6e499be0ffde44cc3  Class-A-Stage1
bee3e014e3df87ddce0250b0985b87f6868a427a7b650a74b7ffedb9d57f3088  Class-A-Stage2
c170fda024183645c0aa681149304e50506509c3498bb6b9a5f5ced6aa73e5fa  Class-B-Stage1
2ffb35e3f9e55286a930fb887e73764a913166648135fe0ca7551736d97d7bfa  Class-B-Stage2
69b6cb327a4d5da99399718f6a66f84de69f89425b0a31f2dcee0682f811596f  Class-B-Stage3
29d283ebd08d0cd3b2e6f4a67718d3d6e7a6be01d0613d716bce218dba57a928  Class-C-Stage1-JS
06c17b31d36838f3d29044784aa047d5c2d9174d3356c1211cf25f9df677445f  Class-C-Stage2-JS
183d62d682aea8018491c8559544e8d6a9ab0e1abd05ecbb6c97daa4f438d2b8  Class-C-Stage2-CVE-2025-27038
387a7fb768db1350a9788d9704e7a72abe07152734e0ff026af72b417e36268c  AndroSnitch

35c0cd19a7334b544c193e392bcd9a8f1d1f43cf6b61be5bf1d9e35537aff2ef  Class B /v1, in the body
621112712ec515e8791129c62feda8fff6654a0116882401609503cacc08054a  Class B /v2, in the body
ae3241d96cc2d99538c7aff60f382cc8dac13859bcbea3ee84992d24d22a8108  Class C, Chrome 139 to 144, in the body
41e6fd33a30d36dabff9ea408d9766a6583edcc107968f6dc1499f2586381967  Class C, Chrome 145, in the body

The question that exposes the gap

The fixes were all published before the campaign began, and the one weak point in Sekoia's reading is a phone that cannot take them. So if a script that your own website loads from a third party changed tonight, which of your phones and your visitors' phones would run it tomorrow, and could you tell, by the end of the day, which iOS and Chrome build each of them is on?

Key facts