Third-Party Script Compromise: How APT29 Turned Sites Into Traps

A third-party script compromise at Ukrainian analytics vendor Plerdy, plus JavaScript planted on hacked sites from the US to Bulgaria, fed phone visitors into a campaign Sekoia ties to Russia's APT29. If your pages load outside code, your site can serve an attack without a single visible change.

How does a normal website become the watering hole?

A website becomes a watering hole when attackers turn it into a trap for the people who already visit it. In this campaign they did it three ways. Sekoia, the French threat-intelligence firm, found the operation in mid-October 2026, and Security Affairs reported it on 5 November.

The attackers injected JavaScript into hacked legitimate sites, built cloned sites with hidden code, and compromised the Plerdy web-analytics service so that every site loading its tag served the attack too. All three paths ended at the same profiling script.

Most of the compromised or cloned properties sat in the US, Ukraine, the Czech Republic and Bulgaria, with no tidy industry pattern. Sekoia describes them by category: a Ukrainian gas production company (the first site it spotted), a major US chemical industry association, a European far-right political party, a Bulgarian website linked to the military and, later in the report, an Australian medical clinic.

Sekoia links the activity to APT29, the group tied to Russia’s foreign intelligence service (SVR) and also tracked as Cozy Bear, Nobelium, BlueBravo, Midnight Blizzard and The Dukes. Its confidence is moderate to high, not certain. The case rests on several threads:

• A CERT found backend files on a compromised site with traces matching a private report on a 2025 APT29 watering-hole campaign.
• Google’s Threat Analysis Group (TAG) noted the framework resembles a 2024 APT29 campaign against Mongolian government websites.
• Victims skew toward Ukraine and the US, and the infrastructure is spread across several hosting providers.
• The hacked Czech far-right party site fits APT29’s record of targeting European political parties.

The attackers did not want the gas company’s data or the clinic’s database. They wanted the phones of the people reading those pages.

What happened to the Plerdy tracker?

For roughly a week, from 27 August to 3 September 2026, the Plerdy tracker served the attackers’ code alongside its own. Sekoia names the compromised host as a.plerdy[.]com, a script loaded by thousands of websites, most of them Ukrainian. Visitors to those sites during that window received Plerdy’s analytics plus the attackers’ profiling script.

The affected sites included military and military-recruitment properties covering the army, special forces and military equipment. That is exactly the audience a Russian intelligence service would want to profile. None of those operators needed to be hacked themselves: they had one script tag pointing at a vendor, and the vendor was the weak point.

Sekoia offers one possible reason for going after Plerdy: direct code injection into high-value Ukrainian sites that used the tracker may have failed, so the operators moved one hop upstream. The report frames this as a possibility, not a finding.

This attack pattern is not new. The 2018 British Airways and Ticketmaster breaches both traced back to tampered JavaScript, and the 2024 Polyfill.io incident pushed malicious code through a single CDN script embedded on an estimated 100,000-plus sites. We covered a smaller version of the same problem when a checkout skimmer hid inside a shared Plausible tracker.

Sekoia is coordinating with the CERTs of the affected countries, though it has not named them. It also has not explained why the campaign went unnoticed from early September until mid-October.

Why can the page look fine while the script is not?

The page looks normal because the malicious code lives in files the browser loads, not in anything a visitor reads on screen. In the Bulgarian case, the attackers modified an existing JavaScript library on the site, and Sekoia found no change to the visible pages. An editor clicking through the site would have seen nothing wrong.

The profiling script was built to blend in. Its operators call it UltimateFingerprinter, and it runs 61 collectors that assemble 394 fields describing the visitor’s device and browser. The code is attached to a minified AngularJS library that makes up about 98% of a 2.3 MB file.

Sekoia thinks the bulk may be meant to defeat analysis by large language models, or simply to look like a normal vendor bundle. Big minified files are common on commercial sites, so size alone raises no alarm.

Oddly, little of that data seemed to gate anything. Only two conditions stopped exploit delivery, both values no real phone would report: implausible screen sizes such as 99999, or zero touch points. Sekoia does not know why the rest was collected and saw no sign it was used later.

The fake sites are a separate problem. One copied America250, the US initiative marking the country’s 250th anniversary. The other, theowo[.]club, now offline, reverse-proxied the site of Raffles London at The OWO, a luxury hotel in the Old War Office building near the UK Ministry of Defence and 10 Downing Street. A reverse proxy serves the real site’s content live, so the clone behaves like the original.

Sekoia raises the idea that the hotel clone targeted diplomatic delegations, noting that Ukrainian President Volodymyr Zelensky reportedly stayed there during a London visit on 14 October 2026. It stresses this remains unconfirmed.

The distinction for owners: a clone abuses your brand on someone else’s domain. An injected library attacks your visitors on your own domain, under your own certificate, and that one is your cleanup job.

Which visitors' phones were actually exposed?

Only phones running outdated software were exposed. Sekoia says none of the three exploit chains uses a zero-day, nothing persists on the device, and the vendors had fixed every flaw before the campaign began. A fully updated iPhone or Android phone was not at risk.

The researchers recovered three complete chains by testing different browser profiles against the fingerprinting server:

• Chain A targets iOS 16.7 and steals cookies.
• Chain B targets iOS 18.5 and takes full device data. Sekoia identifies it as DarkSword, a suspected iOS exploit kit from a commercial surveillance vendor, uploaded to VirusTotal in September 2026. Its haul includes text messages and iMessages, WhatsApp and Telegram databases, Keychain passwords and tokens, contacts, call history, photos, Health data, location caches and Safari cookies.
• Chain C targets Android Chrome 139 to 145, skipping 143 for reasons Sekoia cannot explain. Its payload, which Sekoia calls AndroSnitch, grabs Chrome cookies, saved logins, history and Wi-Fi settings, and halts on the Samsung Galaxy S25 Ultra. It resembles AndroSnatch, a 2024 payload documented by Google TAG, though the sample is too small to prove a family link.

One sloppy detail: the iOS cookie chains were meant to set a marker cookie blocking reinfection for a day, but a coding error makes it expire after one minute.

No persistence cuts both ways. A reboot clears the implant, but stolen cookies, tokens and saved passwords keep working. If staff phones lagged on updates and visited affected sites, review active sessions and rotate credentials. A stolen session cookie for your CMS or hosting panel turns a phone compromise into a site compromise.

How do you audit for a third-party script compromise?

Start with an inventory, because you cannot protect scripts you do not know you load. Open your key pages (home, login, checkout, contact forms) in the browser’s developer tools, filter the Network tab by JS, and record every domain.

Compare that list with what your theme, plugins and tag manager are supposed to load. Analytics, chat widgets, heatmaps and testing tools often add scripts nobody remembers approving. Then match each script to a control:

• Subresource Integrity (SRI). An integrity hash on a script tag makes the browser refuse the file if a single byte changes. The catch: SaaS trackers update without notice, so SRI on a live vendor URL breaks the tracker at every update. It fits versioned library files, or a copy you host yourself and update deliberately.
• Content Security Policy (CSP). A script-src allowlist stops browsers loading code from hosts you never approved, which blocks many injected tags. It would not have stopped the Plerdy compromise, because the bad code came from an approved host. Run it in Report-Only mode first to learn what your pages really load.
• Change monitoring. File-integrity monitoring on the server catches a Bulgarian-style edit to a local library. External monitoring that fetches your pages and hashes every script, including third-party ones, catches vendor-side changes. Test with a mobile user agent, since some injections fire only for phones.
• Vendor pruning. Remove trackers you no longer use. Each one is another company whose breach becomes yours.

If your site loaded Plerdy between 27 August and 3 September, assume visitors were exposed during that window even if your own files are clean. Confirm with the vendor that the current script is clean, and check whether local rules require you to tell users.

What we check first when a site's JavaScript looks wrong

In our cleanup work, injected JavaScript rarely sits in the page template. It is usually appended to a legitimate library: a jQuery copy, a slider plugin’s bundle, a theme’s minified main.js. Owners and many scanners skip those files. The Bulgarian case is the same trick executed at nation-state level. Our first steps:

• Diff every .js file in the theme, plugins and uploads against a fresh copy from the official source. A changed size or modification date on a minified file is a fast first filter.
• Search the database for script tags in posts, options and widget content, since WordPress and Joomla both store HTML there.
• Look for unfamiliar hosts in the rendered page source, especially ones that appear only for mobile user agents.
• Check admin accounts, scheduled tasks and recently changed PHP files. Injected JavaScript usually has a server-side backdoor behind it that will put it back.
• Purge every cache layer (plugin, server, CDN) after cleanup, or visitors keep receiving the poisoned file.

The honest caveat: APT29 is an exotic threat, but the hygiene that blocks it also blocks the ordinary attacks behind most hacked sites. That means updated plugins and themes, two-factor login, file-integrity monitoring and website antivirus scanning. A web application firewall shuts down many of the plugin exploits used to plant the code in the first place.

Why does APT29 use ordinary websites, and what is still unknown?

APT29 uses ordinary websites because it wants specific visitors, and the cheapest route to them runs through pages they already trust. Sekoia also reads the campaign as evidence that exploit kits are moving down-market: state groups keep reusing frameworks from commercial surveillance vendors such as DarkSword, and packaged chains lower the cost and skill needed. Sekoia expects more of this reuse.

Several questions remain open:

• Whether the attackers chose sites to reach specific people, or hit as many unpatched phones as possible and sorted the data later. Sekoia thinks some sites were picked to profile individuals of interest but cannot confirm it.
• Whether the hotel clone was aimed at diplomats.
• Why Chrome 143 was excluded, and why the script gathered 394 fields when only two checks mattered.
• Whether any affected site was flagged by Google Safe Browsing. The report does not say, and code that fires only for selected mobile visitors can slip past automated scans.

For indicators, use Sekoia’s report and your national CERT’s advisories; we are not reproducing domains or file details here. The lesson matches the case where a DebugBear monitoring script was hijacked on Polymarket: every script tag is a trust decision.

FAQ

What is a watering hole attack on a website?

It is an attack where criminals compromise or clone a site that their targets already visit, then use it to deliver malicious code to those visitors. The site owner is usually not the target; the audience is.

Can a hacked analytics script infect my visitors?

Yes. When the Plerdy tracker was compromised between 27 August and 3 September 2026, every site loading it served the attackers' profiling script to visitors, even though those sites' own files were untouched.

Are fully updated iPhones and Android phones safe from this campaign?

According to Sekoia, yes. The chains targeted iOS 16.7, iOS 18.5 and Android Chrome 139 to 145 (except 143), and every flaw was fixed by its vendor before the campaign began.

How can attackers inject JavaScript without changing the visible page?

They append code to an existing JavaScript file, such as a library or minified theme bundle, which runs in the browser but displays nothing. Sekoia saw exactly this on a Bulgarian site.

Would Content Security Policy have stopped the Plerdy compromise?

No. CSP blocks scripts from unapproved hosts, but the malicious code came from Plerdy's approved host. A self-hosted, pinned copy protected with Subresource Integrity would not have picked up the altered file.

If you are unsure what your pages load or whether a script changed overnight, our monitoring, firewall and malware removal plans watch your files and scripts and clean up injected code when it appears.