Sekoia’s Threat Detection & Research team disclosed on 4 November 2026 a mobile watering-hole campaign it assesses with moderate-to-high confidence is associated with APT29. Named Poisoned Source, the operation used compromised legitimate websites, lookalike reverse-proxy websites and a one-week compromise of the Ukrainian Plerdy SEO Tracker to inject JavaScript into visitors’ browsers. The loader fingerprinted device/browser characteristics and selected platform-specific n-day exploit chains. Reported objectives included stealing browser cookies, Chrome data, Wi-Fi passwords and, in some iOS chains, extensive personal data. Exposure could occur simply by visiting a compromised page; a user did not necessarily need to download an app or click a second-stage link.
🕵️ Poisoned Source: APT29-Linked Watering-Hole Operations Targeting iOS and Android Users
Research date: 6 November 2026 | Technical research and defensive guidance
Sekoia assessed the operation as associated with APT29 with moderate-to-high confidence. This is a research attribution based on technical overlaps, operational patterns, victimology and infrastructure—not a publicly adjudicated identification of individual operators. The reporting does not establish a verified victim count, a complete affected-site list or that every visitor was exploited.
Executive summary
1. Attack classification and overview
This is a watering-hole / drive-by browser exploitation campaign with a supply-chain delivery component and adversary-in-the-middle-style reverse-proxy sites. Rather than sending every victim a direct phishing message, the operator places malicious code on websites already visited by target populations.
Initial access: injected JavaScript delivered through compromised websites, lookalike domains or a compromised third-party analytics script.
Reconnaissance: browser and device fingerprinting, including operating-system and browser version.
Exploitation: platform-specific n-day vulnerabilities against vulnerable iOS/Safari or Android/Chrome configurations.
Collection: browser cookies, Chrome information, Wi-Fi credentials and, in some iOS chains, broader device databases and personal information.
The public reporting describes browser-based delivery without a required user click for vulnerable devices; final payloads were reported not to establish persistence.
2. Campaign delivery architecture
Compromised legitimate websites: Sekoia reported malicious JavaScript added to website templates or appended to existing JavaScript assets. The loader fetched an external script identified as UltimateFingerprinter. Examples included a Ukrainian gas-production company, a US chemical-industry trade association, a European political-party website and a Bulgarian military-related website. The strategic relevance of every affected site was not established.
Lookalike reverse-proxy domains: intermediary sites fetched genuine website content and modified page HTML to inject malicious JavaScript. Sekoia documented america250[.]holiday impersonating america250.org and theowo[.]club proxying Raffles London at The OWO.
Analytics supply-chain compromise: between 27 August and 3 September 2026, attackers reportedly modified a.plerdy[.]com/public/js/click/main.js, part of the Plerdy SEO Tracker. Because this third-party component was embedded by thousands of websites, compromise of one shared script could expose visitors across many downstream sites; most were reported to be Ukrainian.
3. Fingerprinting and victim selection
UltimateFingerprinter collected browser and device characteristics through web APIs. Sekoia described 61 collectors producing 394 JSON fields, including canvas, audio, WebGL, fonts, CSS, screen, sensors, battery, network/performance signals and Apple-specific properties. Data was sent to attacker-controlled infrastructure, which could return further JavaScript.
Important caveat: Sekoia stated that the extensive fingerprint’s precise operational purpose remained unclear. Its investigation observed basic device plausibility checks affecting exploit delivery but did not establish that all collected fields were later used to select victims or drive exploitation. Fingerprinting alone is not proof of individual targeting.
4. Exploit chains and data targeted
iOS chain A — cookie theft: reported target iOS 16.7, using CVE-2025-43529 and CVE-2024-27834 to deliver JavaScript malware intended to steal browser cookies. Stolen cookies may permit authenticated session reuse, depending on service-side protections.
iOS chain B — broader device collection: reported target iOS 18.5. Sekoia associated this with DarkSword and listed CVE-2025-43529, CVE-2026-20700, CVE-2025-14174, CVE-2025-43510 and CVE-2025-43520. Reported collection scope included SMS/iMessage, Apple Mail indexes, voicemail, messaging databases, iCloud Keychain and Wi-Fi passwords, contacts, call history, Safari history/cookies, photos, and data associated with Health, Calendar, Notes and iCloud Drive.
Android chain C — Chrome data and Wi-Fi passwords: reported target Android devices running Chrome 139–145, excluding version 143 for reasons not known to researchers. The chain used CVE-2026-3910 and CVE-2025-27038 for remote code execution, sandbox escape and privilege escalation before delivering AndroSnitch. Sekoia also reported a device-model exclusion for Samsung Galaxy S25 Ultra (SM-S938B); the reason was not established.
5. How attackers can use the data
Session hijacking: browser cookies may provide access to already-authenticated webmail, collaboration, cloud and business services.
Account reconnaissance: browsing history, contacts, messages and mail-related data can reveal relationships, roles, projects, travel and sensitive interests.
Credential/network access: Wi-Fi passwords and keychain-related material may expose network access or secrets, depending on device protections and what was extracted.
Follow-on intelligence: messages, documents, calendars and contacts can support tailored spear-phishing and further intrusion.
These are plausible consequences of the reported data types, not confirmation that every consequence occurred for every victim.
6. Threat actor assessment
Sekoia assessed with moderate-to-high confidence that the operation was conducted by APT29, also tracked as Midnight Blizzard, Cozy Bear or The Dukes, and widely attributed by governments and researchers to Russia’s Foreign Intelligence Service (SVR). The assessment was based on technical overlaps, operational patterns, victimology and infrastructure. This is a research attribution, not a publicly adjudicated identification of individual operators.
Victimology included sites likely to attract strategically relevant visitors, including military, special-forces and defence-equipment audiences in the context of the Russia–Ukraine war. Sekoia stated it could not determine whether the campaign sought particular individuals or broad opportunistic collection followed by selective review.
7. Historical context and timeline
November 2023–February 2024: Google Threat Analysis Group documented APT29-suspected watering-hole activity on Mongolian government websites delivering iOS WebKit exploits and collecting browser cookies from vulnerable devices.
2024: Google TAG also reported an Android Chrome exploit chain in the broader Mongolian website watering-hole context, illustrating cross-platform targeting.
27 August–3 September 2026: Sekoia dates the Plerdy tracker compromise to this one-week window.
Mid-October 2026: Sekoia’s TDR team identified wider Poisoned Source activity involving compromised sites, reverse-proxy lookalikes and mobile exploit delivery.
4 November 2026: Sekoia published its technical investigation; subsequent reporting summarized findings and the APT29 assessment.
Operational sequence: compromise/inject website or analytics script → visitor loads page → JavaScript fingerprints browser/device → delivery infrastructure selects platform-specific n-day chain → exploit targets vulnerable browser/OS → payload collects data → information may be used for session reuse, profiling and follow-on targeting.
8. Individual protection
Install iOS, Android, Safari and Chrome security updates promptly; keep automatic updates enabled where practical.
Restart devices after major updates and verify completion.
Treat unexpected redirects, unusual browser behaviour, repeated crashes or unexplained account activity as warning signs.
Use passkeys or phishing-resistant MFA for important accounts; these do not prevent device exploitation but reduce some downstream account-takeover paths.
Review active sessions and sign out unknown sessions; rotate credentials from a known-clean device if compromise is suspected.
Change Wi-Fi passwords if there is credible evidence they were extracted; use WPA2-AES/WPA3 and unique router administrator credentials.
Report suspicious websites to the site owner and relevant national CERT or organizational security team.
9. Organizational controls and incident response
Maintain mobile-device inventory and compliance reporting for OS/browser patch levels; prioritize executives, diplomats, researchers and travelling personnel.
Use MDM/UEM to enforce minimum OS versions, encryption, screen lock, jailbreak/root detection and rapid patch compliance.
Review third-party JavaScript, analytics, advertising and tag-manager dependencies; minimize them, monitor integrity and maintain a rapid disable/rollback process.
Use CSP, Subresource Integrity where appropriate, strict script allow-lists and change monitoring for public websites.
Monitor identity providers for unusual session reuse, new devices, anomalous geography, token replay and unexpected OAuth authorizations.
For suspected compromise: identify devices/users and visit windows; isolate affected devices while preserving evidence; revoke sessions and refresh tokens; review cloud/mail logs for unusual access, exports and forwarding rules; rotate exposed secrets; preserve DNS/proxy/browser/MDM/identity telemetry; notify relevant privacy/legal teams and CERTs.
10. Evidence caveats and conclusion
Publicly named infrastructure included america250[.]holiday, theowo[.]club, static.flux-telemetry[.]com, edge-ord.clouds-stacks[.]com and ad.starx-net[.]com, as well as the Plerdy tracker path. Treat these as historical indicators and validate against current trusted intelligence before blocking or publishing. The research does not provide a verified victim count, a complete affected-site list, or proof every visitor was exploited.
Poisoned Source shows why website reputation alone is insufficient. A trusted site can be compromised directly, altered through a shared third-party script or imitated through a reverse proxy. Keeping mobile operating systems and browsers patched is the most important individual control; dependency integrity, mobile-device posture, session monitoring and rapid response are essential organizational layers.