Sekoia's November 4 investigation describes a mobile espionage campaign that turned compromised websites, lookalike portals and a third-party analytics script into delivery routes for iOS and Android exploits. The practical risk is not just a damaged phone: stolen browser cookies and credentials can expose business services after the original device activity stops.

For small businesses and government contractors, the immediate priorities are to verify mobile operating-system and browser updates, review plausible exposure, and recover affected accounts separately from the device. Sekoia says the analyzed chains use already-patched vulnerabilities and do not work against fully updated devices. This is newly published campaign research, not a disclosure of new zero-days.

What the investigation establishes

In its original Poisoned Source report, Sekoia says it uncovered the operation in mid-October 2026. It identified direct JavaScript injection into legitimate websites, attacker-controlled lookalike sites that proxied genuine content while inserting malicious code, and a compromise of the Plerdy SEO Tracker.

The analytics incident has a specific historical window: August 27 through September 3, 2026. Sekoia says the tracker was loaded by thousands of websites, predominantly Ukrainian, while its introduction describes exposure across hundreds of legitimate sites. Neither figure is a confirmed count of infected phones. Organizations should not interpret the November publication date as the start of that compromise or assume every visitor was successfully exploited.

The common delivery sequence profiled visitors and selected a mobile exploit chain. Sekoia retrieved three complete chains and their final payloads. Its analysis describes cookie theft on iOS, broader device-data harvesting through DarkSword on another iOS path, and an Android payload it calls AndroSnitch that collects Chrome data and saved Wi-Fi credentials. The broader iOS harvesting included messaging databases, passwords and tokens, location-related records and photos.

Attribution is an assessment, not certainty

Sekoia attributes the operation to APT29, or at least one of its subgroups, with moderate to high confidence. It describes APT29 as a Russian-nexus intrusion set widely attributed to Russia's Foreign Intelligence Service, the SVR. Its reasoning includes technical and infrastructure overlaps, operational patterns and evidence shared by partners about earlier activity.

Bulwark is reporting that explicitly qualified assessment, not independently confirming the operator. The locations of compromised websites do not themselves establish attribution. Likewise, Sekoia's discussion of possible diplomatic targeting is an assessment of intent, not evidence that a named delegation or hotel guest was compromised.

Who should act

Prioritize staff whose phones access corporate email, collaboration systems, sensitive client communications or government-contract information. Include personally owned phones permitted to use business accounts: a device outside the managed inventory can still carry valuable authenticated sessions.

Sekoia's delivery tests identified particular older iOS and Android Chrome profiles, but those observations are not a complete vendor-supported affected-version matrix. This article does not establish exact fixed releases. Use the current supported updates provided by the device and browser vendors, verify installation through management telemetry where available, and replace or restrict devices that no longer receive security fixes.

A practical response sequence

  1. Verify the updates actually landed. Check the deployed mobile OS, browser version and available security updates. On Android, check device security updates as well as Chrome; updating only one component is not a substitute for maintaining both. Apply your organization's supported-device and access-compliance policy.
  2. Scope exposure without declaring every visitor infected. Review available DNS, proxy, mobile-security and identity logs against the delivery and exfiltration indicators in Sekoia's report. Retain event-time evidence and the historical analytics window. A visit to a compromised site is an investigation lead, not proof of payload delivery or data theft.
  3. Recover sessions and credentials from a trusted device. Where compromise is suspected, revoke relevant sessions and tokens, reset exposed credentials and investigate account activity. Review mailbox access, forwarding changes and suspicious authenticated sessions. Password changes alone may not invalidate every existing session.
  4. Consider secrets beyond email. The reported payloads can reach messaging data and Wi-Fi credentials. Assess the business information and network credentials present on the affected phone and rotate exposed shared secrets where warranted.
  5. Preserve evidence before disruptive recovery. Involve qualified incident responders when sensitive communications or contract data may be involved. Coordinate collection, containment and notification decisions with the responsible security and legal teams.

Why a reboot is not account recovery

Sekoia reports that the analyzed payloads did not establish persistence. Restarting a device may interrupt that nonpersistent activity, but it does not retrieve exfiltrated information, revoke a stolen cookie or make an unpatched phone safe from another malicious visit. Do not treat the absence of an installed malicious app as proof that the device and its accounts were unaffected.

Bulwark assessment

The material change is the combination of trusted browsing routes and reusable mobile exploit chains. User training remains useful for lookalike links, but it cannot carry the defense when a legitimate site or shared script is altered. Lean teams need an enforceable mobile-update baseline and an account-recovery procedure that works even when endpoint evidence is limited.

The public report does not establish a confirmed number of compromised users, prove that every delivery route remains active today, or supply all of the researcher's private indicators and rules. Its core defensive lesson is still concrete: close the device exposure, then check whether the sessions and secrets that device held have escaped.

Sources and limits