Operation GhostMail reveals how a crafted Zimbra email exploited a stored XSS flaw to hijack active sessions steal credentials and exfiltrate sensitive data in a targeted campaign against Ukraine linked to a Russian APT
Continue reading
Operation GhostMail is a strong example of why “just opening an email” can still become a full compromise when the mail client itself is the target. According to Seqrite Labs, the campaign used a phishing email with no attachment and no obvious malicious outbound link.
The entire payload sat inside the HTML body and was designed to trigger a stored XSS condition in Zimbra Collaboration Suite’s Classic UI when a victim viewed the message inside an authenticated webmail session. Seqrite attributes the activity with moderate confidence to tradecraft previously seen in Russian state-sponsored operations against Ukrainian government entities, and notes that the case was reported to CERT-UA.
What makes this case especially important is that the exploitation surface was not a workstation vulnerability in the traditional sense, but a webmail application with active session context.
Once the email rendered in the browser, malicious JavaScript executed with access to the authenticated Zimbra session, making this closer to a browser-resident post-exploitation environment than a simple phishing event. The official vulnerability mapping aligns with CVE-2025-66376, a stored XSS flaw in Zimbra Classic UI caused by insufficient sanitization of crafted CSS `@import` directives inside HTML email content.
The lure was mundane on purpose. Seqrite says the email was written in Ukrainian and framed as an internship inquiry from a student associated with the National Academy of Internal Affairs. That kind of social engineering is effective because it looks legitimate, low-risk, and easy to dismiss as ordinary correspondence.
Seqrite also notes that the message appeared to come from infrastructure associated with NAVS and initially showed no obvious malicious signals in reputation-based checks.
The payload itself was hidden in the HTML body, not delivered as a file. Seqrite describes a `<div style="display:none">` container holding a large Base64-encoded JavaScript payload, plus malformed-looking CSS and tag structures intended to survive browser parsing while evading simplistic regex-based inspection.
That matters because many mail filters still over-rely on pattern matching against obvious `<script>` tags, suspicious links, or executable attachments. In this case, the exploit’s power came from how the email was rendered, not from what the email contained in a conventional sense.
The underlying issue was a stored XSS problem in Zimbra Classic UI. NVD describes CVE-2025-66376 as affecting Zimbra Collaboration Suite 10 before 10.0.18 and 10.1 before 10.1.13, with the bug tied to CSS `@import` directives inside HTML email.
Zimbra’s own security pages state that the issue was fixed in ZCS 10.0.18 and 10.1.13, both released on 6 November 2025. In practice, that means a crafted email could persist on the server and execute when a user later viewed it in the vulnerable web client.
The technical significance is that this was not a one-shot reflected XSS. It was stored, which is much more dangerous in a collaboration platform because the malicious content can sit in the mailbox until a target opens it, potentially after multiple internal routing hops or mailbox sync events.
Seqrite says the exploit also leveraged tag-name fragmentation and `@import` noise to frustrate sanitization logic and reconstruct executable script structures at parse time. That combination of persistence and parser abuse is exactly what makes mail-client XSS so attractive to advanced operators.
Seqrite breaks the payload into two main stages. Stage 1 is a JavaScript loader that checks for prior injection, decodes a Base64 payload, and then applies XOR using the key `twichcba5e` before loading the final script.
That sort of layered encoding is not sophisticated by itself, but it is enough to slow casual inspection and many automated detonation pipelines. The loader then runs in the top-level document context so it can reach session data and bypass iframe boundaries.
Stage 2 is the browser stealer. Seqrite says it harvests credentials, session tokens, backup 2FA codes, browser-saved passwords, mailbox content, attachments, browser/device metadata, and account configuration data.
It also sends a unique 12-character victim token to the command-and-control infrastructure so the operator can correlate activity across requests and failures. In other words, the payload is designed not merely to steal one thing, but to turn a single authenticated mailbox session into a multi-pronged data collection opportunity.
One especially notable mechanism is the use of Zimbra’s own SOAP APIs against the victim’s account. Seqrite says the malware reads the CSRF token from `localStorage`, then uses it to issue authenticated SOAP requests that look like normal webmail activity. That is a clever abuse of application trust boundaries: if the browser already holds the session and CSRF material, the payload does not need to break the platform’s authentication layer; it simply borrows it.
Seqrite also says the C2 could see detailed failure information because exceptions were posted back with stage names and stack traces.
The theft targets go well beyond inbox browsing. Seqrite says the script attempted to retrieve backup recovery codes through `GetScratchCodesRequest`, create an app-specific password through `CreateAppSpecificPasswordRequest`, enumerate OAuth consumers, inspect ActiveSync device status, and enable IMAP access through account preference changes. Those steps are important because they give the attacker durable access even if the user changes the main password or notices suspicious login activity later. App-specific passwords and backup codes can survive or outlast the initial browser session, which makes them a high-value target in an account-takeover chain.
Seqrite also notes a more novel trick: the payload injects hidden username and password fields off-screen and waits for the browser password manager to autofill them. That is a browser-layer credential theft method rather than a pure webmail technique, and it demonstrates that the operator was willing to combine application abuse with client-side harvesting. The same report says the malware also gathered 90 days of email by looping through daily exports via Zimbra’s built-in export endpoint.
The exfiltration model was built for resilience. Seqrite says the malware used both HTTPS and DNS, with data encoded into RFC 4648 Base32 for DNS tunneling and chunked into 60-character segments. It also used HTTP POSTs for larger structured objects, including server configuration dumps and staged payload output. The dual-channel approach is smart because DNS can sometimes escape environments where direct HTTPS is filtered, while HTTPS can carry richer blobs when allowed.
Seqrite further reports that the mailbox export loop used a checkpointing mechanism in `localStorage` so already-exfiltrated days would be skipped if the tab was reopened. That kind of state management tells you the campaign was engineered for long dwell time, not just opportunistic theft. It is also a reminder that browser storage can become an operational asset for attackers once code executes in a trusted web session.
Seqrite’s attribution is careful rather than absolute. The company says the technical overlaps with prior Zimbra exploitation activity and the targeting alignment against Ukraine are consistent with Russian state-sponsored intrusion sets, but it frames that as moderate-confidence assessment rather than definitive naming. That distinction matters. In cyber threat analysis, tooling overlap, target selection, and infrastructure timing can strongly suggest a cluster, but they do not always prove the actor identity by themselves.
The strategic context also fits the broader pattern of Russia-linked operations against Ukrainian public-sector infrastructure. Seqrite explicitly states that the target was a Ukrainian state hydrology agency involved in navigational and maritime support functions, which makes the mailbox itself part of a larger government support ecosystem rather than just a generic email account. In that sense, the campaign looks designed for intelligence collection and operational preparation, not noisy disruption.
From a risk-management perspective, the most important practical point is that this vulnerability is now in the wild and has already entered the U.S. government’s Known Exploited Vulnerabilities Catalog. NVD shows CVE-2025-66376 as added to CISA’s KEV catalog on 18 March 2026, with a remediation due date of 1 April 2026. CISA’s own catalog and alert confirm that this was added based on evidence of active exploitation.
There is also a small but meaningful scoring nuance. NVD currently shows a CVSS 3.1 base score of 6.1 Medium for the NVD assessment, while MITRE’s CNA score appears as 7.2 High. That kind of discrepancy is not unusual when different scoring bodies interpret impact and user interaction differently. For defenders, the exact score matters less than the fact that the issue is actively exploited and tied to a mail client used in high-value environments.
Zimbra’s published fix path is clear: 10.0.18 for the 10.0 line and 10.1.13 for the 10.1 line. Zimbra’s security advisories also explicitly call out the stored XSS fix in the Classic UI, and the release notes place it in the November 2025 patch cycle. If an environment still exposes an older Classic UI build, the attack surface remains alive regardless of how sophisticated perimeter email filtering may be.
This campaign underlines a few uncomfortable truths. First, webmail is not just a delivery channel; it is an execution environment if the client allows dangerous HTML parsing in an authenticated session. Second, stored XSS in a mail platform can become a launchpad for credential theft, token theft, mailbox harvesting, and persistent account abuse without dropping a traditional payload onto the endpoint. Third, defenses need to assume that browser state, CSRF tokens, and app passwords are all reachable once the client trust model collapses.
For defenders, the practical response is straightforward: upgrade to the fixed Zimbra releases, monitor for suspicious app-specific password creation, review OAuth consumer grants, inspect unusual SOAP activity, and look for DNS or HTTPS beacons to attacker-controlled domains that resemble the infrastructure pattern Seqrite documented. Mailbox-level alerts should also flag unexpected changes to IMAP settings, 2FA backup code access, and mass export behavior. Those are all high-signal indicators because they map directly to the functions the payload tried to abuse.
Operation GhostMail is not interesting because it used a flashy exploit. It is interesting because it used a mundane user action, a legitimate-looking email, and a trusted collaboration platform to build a multi-stage browser-side intrusion path. The campaign chained social engineering, stored XSS, browser memory access, SOAP abuse, and dual-channel exfiltration into a single coherent operation. That is the real lesson: in modern email security, the boundary between “message” and “execution” is thinner than many teams still assume.
148 malicious npm packages masquerading as student proxy and school Wi-Fi bypass tools. Rather than compromising developers during installation
