Session CRT-20261106 — 6 November 2026 · Afternoon Edition

Halil, the confirmed Plerdy mechanics are narrower than the headline. Sekoia reports that Plerdy was compromised from 27 August to 3 September 2026, exposing thousands of predominantly Ukrainian sites. After the page finished loading, injected code fetched UltimateFingerprinter from static.flux-telemetry[.]com at 109.104.106[.]107. Hunting guidance says desktops were screened out before exploitation; a secondary reconstruction says the profiler collected 394 fields and the delivery server selected an iOS or Android chain. The exact selection rules and allowlists are not public. A partner reportedly matched the activity to a private 2025 APT29 report, so that attribution is not independently inspectable from the public evidence.

A Plerdy or fingerprinter request proves exposure, not payload delivery—it is the doorbell, not evidence that the intruder entered. Stronger evidence requires subsequent connections to exploit-delivery infrastructure, exploit-stage artifacts, or post-compromise traffic. The secondary reconstruction identifies patched WebKit/Chrome chains and ad.starx-net as an exfiltration destination; desktop hits are especially likely to be fingerprinting only. Therefore, “thousands of affected websites” is a reach estimate, not a victim count.

Website owners should preserve the exact Plerdy JavaScript and served HTML with hashes, timestamps, headers and CSP reports; CDN, WAF, reverse-proxy and origin logs covering 27 August–4 September; Plerdy administrative and credential records; and organizational DNS, proxy, firewall and mobile-device telemetry for the published infrastructure. Preserve browser history, cache and diagnostics from suspected phones before wiping them. Origin logs alone are insufficient because the malicious dependency executed in visitors’ browsers.

Three actions for tonight: (1) inventory every site that loaded Plerdy during the window and capture evidence before changing it; disable it only if current integrity cannot be established. (2) block and retrospectively hunt the published domains/IP, escalating devices only where traffic progressed beyond fingerprinting. (3) update exposed iOS/Android devices immediately, then isolate devices showing exploit or exfiltration traffic and revoke their sessions. This merits urgent scoping—not an enterprise-wide compromise declaration. The kill chain closes only where second-stage or post-exploitation evidence exists.

The cleanest way to read Poisoned Source is as five separate gates. FACT: Reporting says attackers compromised the Plerdy analytics script, turning legitimate websites into watering holes that fingerprinted visiting phones and selected an iOS or Android chain. Loading that script proves contact, not exploitation. On iOS, the reported branch used DarkSword-derived browser exploitation; on Android, reporting links browser and Qualcomm flaws to delivery of AndroSnitch. AndroSnitch infection is therefore an Android post-exploitation state—not evidence that every Android visitor was infected, and not an iOS implant. “Zero-click” is also misleading here: execution may require no additional tap after page load, but the device still had to encounter the poisoned site.

Credential or session theft sits later still. A loaded exploit, crash, or callback can establish attempted execution; it does not by itself prove authentication material was collected. I would call a device confirmed compromised only with device-level evidence such as successful exploit-stage execution followed by payload activity, implant artifacts, command-and-control traffic, or observed collection/exfiltration. For iOS, compromise does not require finding an installed app or persistence; browser-to-device exploitation and subsequent collection can be sufficient. UNKNOWN: The available reporting does not establish that every exposed device reached that stage, nor does it provide a complete victim count or a reliable branch-by-branch persistence picture.

The Apple Pointer Authentication item, CVE-2024-27834, being placed in CISA’s KEV catalog materially raises patch urgency because KEV records known exploitation. For high-risk users—government staff, journalists, researchers, dissidents, and executives—I would require the latest supported iOS/iPadOS build immediately, remove or replace unsupported devices, and investigate users with watering-hole exposure. I would not wipe the entire Apple fleet merely because the vulnerability entered KEV: that designation does not prove Poisoned Source used it against a particular organization or that any specific handset was compromised. The evidence available here also does not provide the exact fixed-build matrix, so teams should verify that against Apple’s advisory rather than assuming a nominally “recent” version is safe.

Preserve first, remediate second. Correlate affected-domain timestamps against DNS, proxy, VPN, browser, and MDM records; then place matching devices on forensic hold. For iOS, preserve an encrypted backup, sysdiagnose/analytics and crash data, Safari artifacts where legally permitted, OS/build inventory, and network telemetry. For Android, preserve a bug report and available logs, package inventory, a forensic acquisition where authorized, and any AndroSnitch APK, hash, signing certificate, and command-and-control evidence. Export corresponding identity-provider, email, VPN, and cloud-session records before revocation. Mere contact gets rapid patching and monitoring; exploit evidence gets isolation and forensic escalation; confirmed payload activity or collection gets session revocation, credential rotation from a clean device, device erasure/re-enrollment or replacement, and account-level incident response.

Halil, I see no evidence that Poisoned Source and Operation FlashHole are one operation; their delivery chains, platforms, and victimology remain distinct.

• Poisoned Source — APT29/G0016–SVR: moderate confidence. Reporting converges on a compromised Plerdy analytics script delivering mobile browser exploits, including Chrome/Qualcomm-linked exploitation. The APT29–SVR relationship is well established separately, but the cited campaign reporting does not expose the infrastructure, certificate, passive-DNS, or tooling pivots needed for high-confidence campaign attribution. ATT&CK: T1195.002, T1189, T1203. Defenders should scope affected third-party-script consumers and visiting mobile devices—not merely named websites. Alternative: another intelligence service or commercial exploit operator compromised the script. Falsification would require independently corroborated infrastructure history, exploit-build markers, or operator-controlled certificates tying delivery servers to prior G0016 activity.

• Operation FlashHole — Lazarus: moderate confidence. Kaspersky traces activity to at least July 2025: tailored résumé/portfolio lures and watering holes led through INISAFE CrossWeb EX V3, with its high-integrity service spawning an in-memory malware chain. That behavior continues the Korean-software-abuse pattern associated with Operation SyncHole, but the precise CrossWeb abuse mechanism remains unknown. ATT&CK: T1566, T1189, T1203. Scoping must include CrossWeb process ancestry, memory execution, and South Korean sectors beyond earlier victim sets. Alternative: a separate DPRK cluster—or Korean-focused actor—copied Lazarus tradecraft. Shared unique code, configuration keys, cryptographic material, and independently attributed infrastructure would falsify that alternative; generic lures and exploitation of locally ubiquitous software would not.

Halil, this is a browser-side software-distribution compromise, not currently evidence of npm, source-repository, or customer-server compromise. Fact: Sekoia reports that a.plerdy[.]com was compromised from 27 August through 3 September 2026; the tracker was loaded by thousands of websites, predominantly Ukrainian ones. Reporting identifies the affected resource as a.plerdy[.]com/public/js/click/main.js and describes mobile exploit delivery. Assessment: exposure therefore begins with every webpage that referenced that resource during the affected week, then narrows to visitors whose browsers actually fetched and executed a malicious response. It does not automatically include every Plerdy customer, every visitor outside that window, or the websites’ backend systems. Unknown: whether targeting was conditional by site, geography, device, or visitor—and whether the failed trust link was Plerdy’s account, build process, or CDN deployment channel.

For reconstruction, website owners should combine: historical HTML and JavaScript snapshots; tag-manager and CMS/plugin change history; CSP reports; DNS, secure-web-gateway and proxy records for a.plerdy[.]com; browser or mobile-threat-defense telemetry; and identity-provider, application-session, password-reset, and administrative-access logs. Origin web logs can identify visitors to affected pages but generally cannot prove that a third-party script was fetched or which bytes it returned. Plerdy’s CDN request logs, response/version history, deployment audit trail, hashes, and any targeting conditions are therefore the decisive records. Preserve evidence for at least 27 August–3 September, with a buffer on both sides until Plerdy establishes exact first and last malicious delivery.

The response split should be concrete: Plerdy/vendor must preserve and disclose CDN and deployment evidence, publish affected hashes and indicators, determine the failed control, rotate deployment credentials and signing material where applicable, and identify customer properties served the altered object. Website owner must disable the Plerdy resource, block it through CSP, enumerate every property and page that referenced it, correlate affected visits with authentication or privileged workflows, and retain browser, identity, and access evidence. Customer/end user action should be risk-based: users whose devices merely visited an affected page need notification and device/browser updating; users showing exploit or suspicious identity telemetry need mobile-device investigation, session revocation, credential rotation, and review of subsequent account activity.

Script removal only stops future delivery. It is insufficient where the malicious response executed and mobile exploitation may have succeeded, or where an affected page exposed authenticated sessions, credentials, administrative functions, or wallet interactions to browser-side code. In those cases, treat the device and accessible sessions as potentially compromised until telemetry rules that out. The remaining gap is substantial: without Plerdy’s per-request delivery records and targeting logic, website inventories show possible exposure, not confirmed payload execution.