A Russian state-linked threat actor has launched a targeted cyberattack against a Ukrainian government agency, exploiting a cross-site scripting (XSS) vulnerability in Zimbra Collaboration Suite to steal credentials and sensitive email data.
Dubbed “Operation GhostMail,” the campaign stands out for its complete absence of traditional attack indicators — no malicious file attachments, no suspicious links, and no macros.
The attack was delivered through a phishing email received on January 22, 2026, by the Ukrainian State Hydrology Agency — a critical national infrastructure body under Ukraine’s Ministry of Infrastructure.
Written in Ukrainian, the email posed as a routine internship inquiry from a supposed fourth-year student at the National Academy of Internal Affairs (NAVS).
The message was worded to appear harmless, even including an apology in case it reached the wrong inbox — a classic tactic to disarm recipient suspicion.
Seqrite researchers identified the campaign after the phishing email was uploaded to VirusTotal on February 26, 2026, recording zero detections at the time.
Concealed inside the email’s HTML body was a large base64-encoded JavaScript payload, hidden within a display:none div block.
The exploit targeted CVE-2025-66376, a stored XSS vulnerability in Zimbra Collaboration Suite patched in ZCS versions 10.0.18 and 10.1.13 in November 2025.
.webp)
The flaw involves insufficient sanitization of HTML content using CSS @import directives. Once a victim opened the email in Zimbra’s Classic UI with an active authenticated session, the payload executed silently in the browser.
Based on technical overlaps with previously documented Zimbra exploitation patterns and the geopolitical nature of the target, Seqrite attributed Operation GhostMail to APT28 (Fancy Bear) with medium confidence.
The targeting of a Ukrainian government agency responsible for maritime and hydrological infrastructure aligns with Russian state-sponsored cyber operations observed against public-sector institutions amid the ongoing conflict.
Once the payload executed, the attacker silently harvested session tokens, login credentials, backup two-factor authentication codes, browser-saved passwords, and up to 90 days of the victim’s email archives — all without raising a single alert.
Data was exfiltrated over both HTTPS and DNS channels, making detection through conventional network filtering particularly difficult.
Two-Stage Infection Mechanism
The attack operated in two clearly defined stages, both running entirely within the victim’s browser without ever writing anything to disk.
In Stage 1, the JavaScript loader first checked whether a script with the ID “zmb_pl_v3_” was already running, preventing duplicate injections.
It then decoded a base64 payload using the atob() function and applied XOR decryption with the key “twichcba5e” to unpack the final JavaScript payload.
%20(Source%20-%20Seqrite).webp)
This decoded script was injected into the top-level document, escaping the webmail’s iframe sandbox and inheriting full access to the browser’s cookies, localStorage, and same-origin SOAP API rights.
Stage 2 introduced the full browser stealer, which began by generating a unique 12-character alphanumeric token per victim, used as an identifier in every command-and-control (C2) request.
The hardcoded C2 domain was zimbrasoft[.]com[.]ua, registered on January 20, 2026 — two days before the phishing email arrived. Nine parallel data-collection operations launched simultaneously, maximizing data yield within a single browser session.
These operations captured email content, server configuration, CSRF tokens, mobile device profiles, OAuth application access, backup 2FA codes, and browser-autofilled credentials.
The attack also silently enabled IMAP access on the victim’s account and created a persistent app-specific password named “ZimbraWeb,” giving the attacker long-term mailbox access that survives a full password reset.
Organizations running Zimbra should immediately upgrade from version 8.8.15 to at least version 10.1.x.
Administrators should audit all accounts for app-specific passwords named “ZimbraWeb” and revoke them without delay.
SOAP API monitoring should be deployed, as calls to GetScratchCodesRequest and CreateAppSpecificPasswordRequest are rarely seen in normal usage and warrant immediate investigation.
DNS filtering should be enforced against the identified IOC domains, and IMAP or POP3 access should be disabled for accounts without a clear business need.
Staff must also understand that a clean-looking email with no attachments and no external links can still deliver a fully functional malicious payload hidden inside its HTML body.
Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.
