A large-scale watering hole operation hitting iOS and Android users is spreading through three vectors at once — compromised websites, look-alike domains, and, most consequentially, injected code riding on Plerdy SEO Tracker, the Ukrainian web analytics product embedded across third-party sites. Sekoia's threat research team, which laid out the operation in a report covered by The Hacker News on 4 November, attributes the campaign to APT29, the Russia-linked group also known as Cozy Bear.
The attribution remains Sekoia's, not independently confirmed here. The campaign's reported scale, its active window, and whether the attacker infrastructure remains live are all absent from the material published so far — figures that would normally frame how urgently defenders should treat the advisory.
What the injected code does
According to Sekoia researchers, including Amaury-Jacques Garçon, the injected JavaScript collects browser and device attributes from visitors before proceeding to deliver exploits against both Apple's iOS and Google's Android platforms. The mechanics of those payloads have not been disclosed: no specific vulnerability — no confirmed zero-day, no named WebKit or Chrome remote code execution bug, and no zero-click claim — has been attached to the campaign in the public record at the time of writing.
One point of genuine ambiguity sits at the centre of this story. The disclosure does not resolve whether Plerdy's own infrastructure was breached, allowing malicious code to be pushed to every site loading the tracker, or whether Plerdy's script was merely impersonated or repackaged by the attackers on compromised sites. The two scenarios warrant different responses. If Plerdy's CDN or build pipeline was compromised, affected operators should verify script hashes against a known-good source today. If a look-alike script was served only on individual compromised sites, Content Security Policy and strict script allowlisting are the more relevant controls.
Why the vector matters more than the name
The differentiating element here is not the APT29 label but the reach pattern it implies. A hijacked analytics script's blast radius scales with the product's install base, not with the attackers' intrusion activity: every site loading the tracker becomes a potential delivery point, whether or not it was individually targeted. For organisations that treat third-party JavaScript as inert marketing tooling, this is the category of risk that vendor questionnaires routinely miss.
Sekoia and The Hacker News have published indicators associated with the campaign. Defenders should pull them from the primary sources and check them against DNS, proxy, and endpoint telemetry rather than relying on second-hand summaries.
Mitigations
- Sites loading Plerdy: inventory every page and subdomain embedding the tracker, compare the served script against the vendor's expected hash or a cached known-good copy, and confirm the script's origin is allowlisted in CSP.
- Third-party JS generally: adopt subresource integrity where feasible, restrict script sources to explicit allowlists, and log unexpected script origins.
- Mobile devices: keep iOS and Android patched against current platform updates; exploit details here are undisclosed, so defence rests on vendor patches once issued.
HK angle: audit what your pages load
Hong Kong web and IT teams running content sites, e-commerce platforms, or campaign microsites can take a concrete step this week: enumerate every third-party script tag in production (tag managers, analytics, heatmaps, chat widgets), record each origin, and flag any you could not name unprompted. Script inventory is the prerequisite for CSP, SRI, and incident scoping — and it is the check this incident shows can no longer be deferred.
No response from Plerdy, Apple, or Google was noted in the source material. For an industry long comfortable treating analytics scripts as harmless, the lesson is uncomfortable: the trust you extend to a vendor's JavaScript is trust you cannot audit — until it is the only thing standing between a visitor and an exploit kit.
一場大規模針對 iOS 及 Android 用戶的水坑攻擊行動正同時透過三條途徑擴散——被入侵的網站、仿冒域名，以及影響最為深遠的一條：掛載於 Plerdy SEO Tracker 之上的注入代碼。Plerdy 是一款烏克蘭網頁分析產品，廣泛嵌入於眾多第三方網站。Sekoia 的威脅研究團隊在一份報告中詳述了該行動（The Hacker News 於 11 月 4 日報道），並將此次攻擊歸因於 APT29，即俄羅斯關聯組織 Cozy Bear。
上述歸因屬 Sekoia 一方的判斷，並未在此獨立證實。已公布的材料中，欠缺該行動的據報規模、活躍時間窗口，以及攻擊者基礎設施是否仍然在線等資料——這些數據通常是判斷防禦者應以何等緊迫程度處理該警告的依據。
注入代碼的運作方式
據 Sekoia 研究人員（包括 Amaury-Jacques Garçon）所述，注入的 JavaScript 會先行收集訪客的瀏覽器及設備特徵，繼而向 Apple 的 iOS 及 Google 的 Android 平台投放 exploit。相關 payload 的運作機制至今未有披露：截至本文撰寫時，公開紀錄中並未將任何特定漏洞歸因於此行動——沒有已確認的 zero-day，沒有指名的 WebKit 或 Chrome remote code execution 漏洞，亦沒有 zero-click 的說法。
本則報道的核心存在一處真正的懸而未決之處：披露文件未能釐清，究竟是 Plerdy 自身的基礎設施遭入侵，令惡意代碼得以推送至所有載入該 tracker 的網站；抑或僅是攻擊者在被入侵網站上仿冒或重新打包 Plerdy 的腳本。兩種情境所需的應對截然不同。若 Plerdy 的 CDN 或 build pipeline 確遭入侵，受影響的營運者應即日以已知良好來源核對腳本 hash。若仿冒腳本僅在個別被入侵網站上投放，則 Content Security Policy 及嚴格的 script allowlisting 是較為對症的防禦措施。
為何攻擊途徑比組織名稱更值得注意
此處的關鍵差異並非 APT29 這一個標籤，而是它所暗示的影響範圍模式。一個被劫持的分析腳本，其爆炸半徑取決於該產品的安裝基數，而非攻擊者的入侵活動規模：每一個載入該 tracker 的網站都成為潛在投放點，不論它是否曾被單獨鎖定。對於視第三方 JavaScript 為無害的市場推廣工具的機構而言，這正是一類供應商問卷調查經常遺漏的風險。
Sekoia 與 The Hacker News 已公布與該行動相關的 indicator。防禦者應從一手來源取得，並對照 DNS、proxy 及 endpoint telemetry 進行核查，而非依賴二手摘要。
緩解措施
- 載入 Plerdy 的網站：盤點所有嵌入該 tracker 的頁面及 subdomain，將實際投放的腳本與供應商預期的 hash 或已留存的良好副本比對，並確認腳本來源已列入 CSP allowlist。
- 一般第三方 JS：在可行情況下採用 subresource integrity（SRI），將 script 來源限制於明確的 allowlist，並記錄所有預期以外的腳本來源。
- 流動裝置：確保 iOS 及 Android 已套用現行平台更新；此處的 exploit 細節未有披露，防禦只能依賴供應商發布的 patch。
香港角度：審計你的網頁載入了甚麼
香港的網頁及 IT 團隊若營運內容網站、電商平台或活動 microsite，本周即可採取一項具體行動：列舉生產環境中每一個第三方 script tag（tag manager、分析工具、heatmap、chat widget），記錄其 origin，並標記任何你無法不假思索說出名稱的項目。腳本清單是落實 CSP、SRI 及事件範圍界定的前提——而這次事件顯示，這項檢查已不能再拖延。
來源材料中未見 Plerdy、Apple 或 Google 有任何回應。對於長期習慣將分析腳本視為無害的業界而言，這一課並不好受：你延伸予供應商 JavaScript 的信任，是一份你無從審計的信任——直到它成為訪客與 exploit kit 之間僅存的屏障。