Is "don't click anything" still enough? The TA488 Zimbra XSS attack breaks every phishing rule

Bottom Line Up Front

Yes — in August 2026 Russian APT TA488 (Void Blizzard / Laundry Bear) steals email from Zimbra webmail via a no-click XSS attack: opening the crafted message gives the attacker access to inbox, calendar, contacts, 2FA codes and CSRF tokens. On 6 August 2026 Polish Agencja Wywiadu and SKW issued a joint advisory. The Zimbra patch has been available since November 2025; many institutions have not deployed it. Now: verify Zimbra version, audit audit.log for CreateAppSpecificPassword, remove unknown app passwords, force credential rotation, review unusual DNS queries.

Key facts

• TA488 = Void Blizzard / Laundry Bear — Russian APT linked to GRU intelligence, tracked in parallel by Proofpoint, Microsoft and Polish intelligence [1][2].
• Technique: attackers injected XSS payloads split across CSS @import fragments and HTML comments — Zimbra filters did not reassemble them, but the victim's browser executed the hidden JavaScript [1][3].
• Per-mailbox leakage: last ~90 days of messages, organisation address book, browser-suggested passwords, 2FA backup codes and CSRF tokens [1].
• Persistence mechanism: payload created an app-specific password ZimbraWeb and enabled IMAP, allowing attackers to return even after password change and 2FA reset [1].
• Exfiltration channel: DNS queries shaped as https://d-{IDENTIFIER}.{DATA_TYPE}.{BASE32}.i.{DOMAIN}/pixel.gif (DNS tunneling in web-bug style) [1].
• Underlying weakness: Classic UI HTML sanitizer flaw — 7 XSS CVEs in CISA KEV since 2022, exploited by groups linked to Russia, Greece, Belarus, Vietnam and Pakistan [3].
• Polish advisory: joint communication from Agencja Wywiadu and SKW dated 6 August 2026 [1][2].
• Affected sectors (PL and abroad): administration, education, energy, media, law enforcement, technology companies (plus government, scientific and defence institutions — particularly Ukrainian) [1].
• AI / CTI classification: reports are linked (Proofpoint, Microsoft, Google TAG, KEV Database) — citation class A.

Decision table

Area	What we know	What it means for B2B / manufacturing	Recommended action (30 / 90 days)
Zimbra webmail (Classic UI)	XSS in HTML sanitizer exploited at scale since 2025; patch available since Nov 2025 [1][3]	Older ZCS = real risk of leakage of executive, legal and operations mail	30 d: upgrade to latest supported version; 90 d: migrate from Classic UI to Modern UI (Iris) or evaluate alternatives
IMAP / POP3 access	Payload created the ZimbraWeb app password and enabled IMAP [1]	Breaks standard credential rotation — attackers return via classical protocol after password change and 2FA reset	30 d: disable IMAP/POP3 where unused; purge unknown app passwords from audit.log; 90 d: require app-level 2FA (OAuth, hardware keys)
DNS exfiltration	Stolen data leaked through specially crafted subdomains [1]	RBL / DNS-firewall detectors do not always flag legal-looking queries to attacker infrastructure	30 d: enable DNS query logging on egress; compare against TI feeds; 90 d: deploy DNS sinkhole / Response Policy Zone with trusted feed
Webmail ↔ AD segmentation	Stolen session tokens = full SSO into other services [3]	One email is enough to take over multiple B2B / ERP accounts	30 d: force session rotation after incident; 90 d: roll out phishing-resistant MFA (FIDO2 / hardware keys) for privileged accounts
NIS2 / KSC obligations	Incident involves mail processing — potentially sensitive and operational data [4]	Art. 21 NIS2 and KSC equivalents require SaaS supply-chain risk management and incident reporting	30 d: classify incident in the register; 90 d: update supplier security policy (including on-prem Zimbra as a vendor)
Security awareness	Classic "don't click links" does not protect — attack is zero-click [1]	Users lose their last defensive layer	30 d: update awareness messaging to include "no-click" threats; 90 d: add spear-phishing simulations with HTML payload (controlled environment)

Perspective from Marcin Białczyk

The webmail war in 2026 did not look the way most security teams imagined. We did not see campaigns with 3-factor-login links, we did not see macros in attachments. We saw JavaScript embedded in HTML mail bodies, reassembled only in the victim's browser — and this is precisely the moment when XSS, which for years we treated as a "technical curiosity", turned into an intelligence weapon. What strikes me operationally is that the Zimbra patch existed since November 2025 — and the campaign happened in 2026. Between patch and compromise, in the best case a few months, in the worst case more than a year. This is not a technology problem. It is a patch-supply-chain problem: upgrading a webmail that hosts executive and legal correspondence is, for many organisations, a decision requiring three signatures and a maintenance window.

The second serious observation: the payload created an app-specific password and enabled IMAP. That means the standard playbook — "change password, reset 2FA, kill sessions" — is not enough. Attackers leave behind a back door that survives credential rotation. Until the organisation audits audit.log for CreateAppSpecificPassword and removes unknown entries, it cannot consider the incident closed. This is a typical mistake in our operational experience: credential rotation without cleaning "persistence artifacts" = false sense of security.

The third point concerns NIS2/KSC. The attack hit organisations in sectors listed in the directive's annex (administration, energy, operators of essential digital services). This is not "just an email leak". It is an incident within the meaning of Art. 21 NIS2 and corresponding KSC provisions — it requires impact assessment, documentation and reporting. Legal interpretation requires consultation with a law firm; CHORS.NET does not issue independent legal opinions. In the operational readiness area we combine two components: passive exposure verification (our P0/P1 service) with NIS2/KSC Continuous Readiness for entities that must demonstrate ongoing monitoring and a documented response path. We do not declare compliance — we help you organise and evidence it.

Frequently asked questions

I don't run Zimbra. Can I ignore this campaign?

No. Proofpoint and Microsoft attribute TA488 to the same group that in H2 2026 pivoted to Microsoft Outlook Web Access with a separate XSS (CVE-2026-42897) and a custom OWAReaper implant surviving credential rotation. Webmail is a target class, not a specific product.

I run Zimbra at the latest version. Am I safe?

Partially. The patch closes one specific injection path, but does not undo the fact that XSS could execute arbitrary JavaScript in the context of the logged-in session. Audit audit.log for CreateAppSpecificPassword, review unusual DNS queries, assess the risk of historical mail exfiltration.

How do I tell a false alarm from a real intrusion?

First: unusual app passwords in audit.log (especially ZimbraWeb). Second: DNS queries for long, odd subdomains with BASE32 segments. Third: IMAP/POP3 logins from unknown IPs despite disabled "normal" webmail. Fourth: spikes in calendar attachment volume. Each signal requires separate analysis; none is a sufficient indicator on its own.

Do I have to report this incident to CSIRT / NASK?

If you are an essential or important NIS2 entity — the answer is: check your reporting obligations with your law firm and the competent authority (in PL: the relevant sectoral CSIRT, ENISA-CERT, and the KSC Act). This article is not legal advice; obligations depend on entity classification, data types and incident character.

Boundaries and assumptions

• We are not a 24/7 SOC and we do not guarantee detection of every incident — the described detection techniques require your own analysis and tailoring to your environment.
• We do not certify NIS2/KSC compliance and we do not issue independent legal opinions — for legal interpretation CHORS.NET cooperates with law firms.
• Results and IOCs reflect the state of knowledge at the time of publication (6 August 2026); the campaign is active and attackers may rotate infrastructure.
• CHORS.NET's approach to webmail and SaaS supply chain is passive (P0/P1 Passive Exposure Snapshot / Authorized Vulnerability Assessment) — we do not scan customer production applications without written authorisation.
• This material is informational and technical; it is not legal advice and not a security guarantee.
• The article contains no fabricated case studies or customer statistics.

CTA

• CHORS.NET services — P0 / P1 / P2 / P3 (passive exposure verification → authorised VA → on-site assessment → NIS2/KSC readiness)
• NIS2/KSC Start and Continuous Readiness — how to organise compliance step by step
• AI policy and CHORS's operational approach to threat intel / AI in cybersecurity
• How CHORS.NET works — collaboration model, boundaries, methodology

Sources

1. Niebezpiecznik: "Rosjanie wykradają e-maile ciekawym atakiem XSS. Agencja Wywiadu i SKW ostrzegają!" (06.08.2026)
2. ZaufanaTrzeciaStrona / Polish government advisories — context of the joint Agencja Wywiadu and SKW communication: zaufanatrzeciastrona.pl
3. KEV Database: "Zimbra's Persistent XSS Problem: Nation-State Actors and the Classic UI (2022–2026)" (22.04.2026)
4. ENISA: Threat Landscape and SaaS supply-chain / NIS2 obligations reports
5. CISA: Known Exploited Vulnerabilities Catalog (Zimbra CVEs)
6. Proofpoint / Microsoft Threat Intelligence: tracking TA488 / Void Blizzard (threat research section)
7. NASK PIB / CERT Polska: Polish technical advisories on Zimbra and webmail hardening