A mobile spying campaign reused flaws that already had fixes

A website visit could start the attack

Security researchers at Sekoia published an investigation on November 4 into an operation that delivered attack code to some visitors using outdated iPhones or Android devices. The team says it uncovered the operation in mid-October. The software flaws had already been fixed when the campaign began, according to its analysis. The new evidence is how the attackers used them together and where they placed the code that made the first move.

In a watering-hole attack, the operator tries to reach people through a site they have a reason to visit. Sekoia found injected code on legitimate sites and separate lookalike sites that relayed genuine content. The team also reported a compromise of a Ukrainian analytics service. A shared script can extend the reach of an intrusion across sites that run it, even when those sites are operated by different organizations. The researchers date that incident to August 27 through September 3. They could not recover one intermediate script from its original host and assessed its match to a sample recovered elsewhere.

Source notes: 1.

Exposure and infection require different evidence

The first script gathered information about a visitor’s device and browser. The infrastructure could then return exploit code suited to a selected configuration. A visitor could trigger that delivery by loading the page, without approving an installation or entering a password. The distinction is important for staff training. Recognizing a fake login form helps against credential phishing, while the browser and operating system have to withstand code that executes as part of an ordinary page load.

An affected website’s traffic figures would count people with different devices and software versions. Those figures cannot tell an investigator how many visitors received an exploit, how many exploits succeeded or what data was transferred. Sekoia obtained three complete chains by presenting different browser profiles. Its report establishes what the recovered code could do in the observed configurations. It gives no verified total of compromised phones.

Source notes: 1.

Three paths reached different data

For an iOS 16.7 profile, Sekoia recovered a chain designed to extract Safari cookies. A chain delivered to an iOS 18.5 profile used the DarkSword toolkit and went further, from code execution in web content to escape from the browser’s restrictions and access to device data. The researchers found code for collecting messaging databases, stored credentials, location data and photos. These are capabilities recovered from one chain. Which data left any particular phone is a question for an incident investigation.

On Android, Sekoia recovered a chain that combined a Chrome renderer flaw with a Qualcomm Adreno driver vulnerability. Its payload collected Chrome data and saved Wi-Fi information. The researchers saw delivery to certain older Chrome profiles and could not explain why the server skipped Chrome 143. That omission reflects how this operation selected targets. It provides no basis for treating that browser branch as safe.

Source notes: 1, 2, 3, 4, 5.

A fix has to reach the device

Apple’s December 2025 security note for iOS 18.7.3 identifies one WebKit flaw used in both recovered iOS paths, CVE-2025-43529. Google Threat Intelligence separately documented earlier DarkSword campaigns in March 2026 and traced patches for several components of the kit. On Android, Google’s August 2025 security bulletin identifies the Qualcomm flaw, CVE-2025-27038. The March 2026 Chrome release record documents the separate browser flaw, CVE-2026-3910. The vendor records establish that individual fixes were available. They cannot establish when a given phone installed them.

For a personal phone, check the newest update the manufacturer offers for that exact model. On Android, also check the Android security update and the version of Chrome, since a browser update and a device update cover different parts of the observed chain. For a managed fleet, record what the device is actually running after the update. An approved rollout policy tells IT what ought to happen, while a recorded build or patch level shows which handsets still need attention.

A practical inventory can separate three questions for each phone. Can the model still receive security updates? Which system build is installed today? Which browser version is actually in use? If a model can no longer receive fixes, an inventory makes that gap visible. For teams that manage phones, it also gives the person responsible for replacing devices a list based on support and installed versions instead of purchase dates alone.

Source notes: 2, 4, 5.

What the attribution and recovery findings support

Sekoia linked the operation to APT29 with moderate to high confidence, citing several kinds of overlap, including infrastructure and a partner’s observations involving an earlier operation. Google’s earlier research documents use of DarkSword by several different actors. A shared toolkit therefore cannot identify an operator on its own. The attribution is Sekoia’s assessment of the broader evidence. Lumacta has no independent attribution or device examination.

Sekoia says the payloads it analyzed did not establish persistence. That limits what the samples show about continued execution, while the possible disclosure of information remains a separate issue. A restart cannot recall a copied cookie or password. If a security team has credible evidence of exposure, the next decision is what needs investigation or containment based on the affected device, observed time and account activity. An update protects against the patched flaws going forward. The history of the device and its accounts determines what else needs review.

Source notes: 1, 3, 6, 7.