Contribution
This post adds a detection chain for the Laundry Bear Zimbra campaign that does not depend on yesterday's command and control domains. It joins three behaviours from one webmail session: account changes through Zimbra SOAP, repeated mailbox archive requests, and high-cardinality DNS or HTTPS traffic from the user's browser. The chain turns the campaign's collection sequence into a hunt that remains useful after the attacker moves its infrastructure.
The pattern
A Russian state-supported group tracked as Laundry Bear, Void Blizzard, CL-STA-1114 and TA488 has been compromising Zimbra Collaboration Suite users to steal mail. The joint advisory published by CISA and partner agencies says the campaign began by July 2025 and used CVE-2025-66376 while it was still a zero-day. Unit 42 independently describes the same activity cluster and says the targets included government, defence, transportation and financial organisations across several regions.
The lure is an email, but this is not ordinary click-through phishing. A target using a vulnerable Zimbra Classic Web Client only has to view the message. CSS @import directives trigger the stored cross-site scripting flaw, and an SVG onload field starts an obfuscated JavaScript payload in the authenticated webmail page. The browser already has the victim's Zimbra session and CSRF token, so the script can call the same SOAP interfaces as the legitimate client.
The payload, named Ulej by the agencies, carries out twelve ordered stages. It gathers the victim's address and environment, retrieves two-factor authentication scratch codes, creates an application passcode, checks OAuth consumers, attempts to pull a saved password from browser autocomplete, enables IMAP, enumerates the Global Address List, and downloads mail archives. The public reporting is unusually specific about the sequence. That makes behaviour a better detection anchor than an IP address.
The collection target is not a handful of messages. Ulej queries each of the previous 90 days separately through /home/~/?fmt=tgz&meta=0&query=date:-{DAY_OFFSET}d AND (not in:junk). It also enumerates the directory through 1,521 SearchGalRequest operations spread across 20 batches. The resulting data goes to an actor-run framework called Flowerbed over HTTPS and DNS.
The infrastructure is deliberately disposable. The joint advisory lists servers used for periods measured in weeks, and Unit 42 recorded multiple domains and IP addresses over the campaign. IOC matching still helps with historical scoping, but it is a poor primary alert for a group that expects to replace domains. The webmail operations are harder to change because they are how the payload gets its persistence and data.
Why it matters to cloud defenders
Zimbra often sits outside the cloud team's formal boundary, especially when it is self-hosted. The identity and data it exposes do not respect that boundary. A mailbox can contain password reset links, cloud console alerts, signed documents, API credentials sent during support work, and conversations that make later social engineering credible. The Global Address List gives the attacker a map of people and aliases.
The application passcode is the sharper problem. Ulej uses CreateAppSpecificPasswordRequest with the application name ZimbraWeb, and it tries to set zimbraPrefImapEnabled to TRUE through ModifyPrefsRequest. That creates a route back into the mailbox through a protocol where Zimbra does not apply its normal two-factor authentication flow. Patching the browser-side vulnerability stops new exploitation, but it does not revoke a passcode already created during a compromised session.
This is where a mail-server incident becomes an identity incident. Stolen mail can support resets against Microsoft 365, AWS, Azure, GCP, GitHub or a corporate identity provider. A newly enabled IMAP path can preserve access after the browser session ends. Stolen scratch codes and autocomplete passwords widen the options further. Defenders need to scope the mailbox, the identities recoverable through it, and any cloud access that followed.
The campaign also exposes a logging split. Zimbra's own documentation identifies audit.log, mailbox.log and nginx.access.log as separate surfaces. DNS telemetry may live with a network or endpoint team. Identity-provider and cloud audit records sit elsewhere again. Looking at any one source leaves a plausible fragment: a preference change, an archive download, or a burst of DNS lookups. The sequence is what distinguishes compromise from routine mail use.
ATT&CK mapping
The entry is Phishing, T1566, followed by Exploitation for Client Execution, T1203; both labels come from the joint advisory's own mapping. The parent phishing technique is the honest choice rather than a delivery sub-technique, because the payload executes when the vulnerable web client renders the message body, and Unit 42 also reports an HTML-attachment variant of the same campaign. Both remain useful hunting labels, though T1098 supplies the strongest correlated detection point in this campaign.
The persistence step maps to T1098, Account Manipulation. Ulej changes an account preference to enable IMAP and creates an application-specific password. These are durable changes to the victim's existing account, not merely theft of the active session. T1098 is the listed technique because its concrete detection point is the strongest part of the chain.
Collection maps to T1114, Email Collection, with the archive requests showing the data payoff directly. The 1,521-request directory sweep maps to T1087, Account Discovery; the joint advisory applies the same label to the script's gather stages. Exfiltration maps to T1048.002 for the encrypted HTTPS channel and T1048.003 for DNS; the joint advisory applies exactly those labels to Flowerbed's two paths. These mappings complete the path from message view to mailbox theft without pretending that every stage has equal telemetry.
There is an important distinction from the older Zimbra CVE-2023-34192 research on a13e. That rule-bound article covers a ModSecurity alert on the /h/autoSaveDraft endpoint for a different stored XSS flaw. Laundry Bear's campaign uses CVE-2025-66376 in rendered email and leaves post-exploitation behaviours inside the victim's web session. Reusing the older endpoint rule would miss this path.
Detection guidance
Start with the account-change pair. Search Zimbra application telemetry for ModifyPrefsRequest setting zimbraPrefImapEnabled to TRUE and CreateAppSpecificPasswordRequest naming the application ZimbraWeb. Alert when both operations occur for one account in a short window, especially when the user has no established IMAP client. A legitimate user may enable IMAP or create an application password, but the exact pair without a help-desk ticket or prior IMAP use deserves review.
Zimbra documents SOAP TRACE logging to mailbox.log, which can expose the request names needed for this hunt. Treat TRACE as a targeted diagnostic setting rather than a permanent default: it is verbose and SOAP bodies can contain sensitive data. If a reverse proxy or WAF already records SOAP operation names safely, use that source instead. Do not add unrestricted body capture merely to build this alert.
Next, hunt for the collection burst in nginx.access.log or equivalent reverse-proxy telemetry. Filter authenticated requests to /home/~/ where the query includes fmt=tgz, meta=0 and date:-. Group by account, session, source IP and user agent. Repeated daily offsets over a short period are not normal interactive reading. One export might be a user action; dozens of date-offset exports from one browser session point to automated archive collection.
Add the SOAP discovery fan-out when those events are visible. The campaign sends SearchGalRequest in 20 batches, totalling 1,521 searches over two-character prefixes. A threshold should be based on each organisation's directory usage, but a sudden burst of hundreds of GAL searches from one session is a useful companion signal. GetScratchCodesRequest, GetOAuthConsumersRequest and GetDeviceStatusRequest strengthen the case when they occur beside the app-passcode creation.
The network leg catches successful or attempted exfiltration. Use DNS resolver or endpoint DNS telemetry to find one webmail workstation issuing many A queries to a newly observed domain, with long Base32-like labels split into chunks no longer than 60 characters. The campaign prefixes DNS exfiltration identifiers with d- and varies a data-type label. Join this to a recent Zimbra message view or the account-change pair rather than alerting on encoded-looking DNS alone, because security tools and content delivery systems can generate similar labels.
For HTTPS, look for a browser process or webmail workstation making direct outbound connections to a newly registered or first-seen VPS-hosted domain immediately after Zimbra activity. Connection count and upload bytes matter more than the current domain list. If TLS inspection is available and lawful, compare request paths with the structure in the joint advisory. Otherwise, retain destination, process, SNI, byte count and timing.
A practical correlation can score the chain rather than demand every stage:
- High severity when application-passcode creation or IMAP enablement is followed by mailbox archive requests from the same account.
- Raise confidence when the same session performs a large GAL search or requests scratch codes.
- Raise confidence again when the user's endpoint produces high-cardinality DNS or unusual HTTPS to a first-seen domain.
- Keep a lower-severity hunt for archive bursts alone, since missing SOAP detail should not make collection invisible.
Plan for incomplete telemetry. A workstation using encrypted DNS can hide the resolver pattern from network sensors, while direct HTTPS may blend with ordinary browsing. Zimbra SOAP TRACE may have been disabled, and a reverse proxy may record only the /service/soap/ path rather than the operation name. In that case, use the archive-download burst as the stable server-side anchor, then ask the endpoint or secure web gateway whether the same browser contacted a first-seen destination. Record the blind spot in the incident notes instead of treating absence as proof that exfiltration failed.
Retention matters because the three legs may age out at different speeds. Preserve the original message and its raw headers, not a forwarded copy. Keep the account's preference and application-passcode history, the relevant proxy rows, and endpoint DNS or connection events under one timeline. The malicious message proves delivery; the account changes show persistence; archive requests show collection; outbound traffic shows an exfiltration opportunity. Analysts can still reach a useful confidence judgement when one leg is missing, provided they state which evidence was unavailable.
The first triage question is whether the account owner intentionally changed mail-client settings. The second is whether archive requests and outbound network activity followed. A normal IMAP setup should not also export 90 daily mail archives and enumerate the directory. That difference gives analysts a defensible way to separate a user configuring a client from a script preparing long-term espionage access.
What to do now
Patch first. The joint advisory states that fixes for CVE-2025-66376 are present in ZCS 10.0.18 and 10.1.13. Confirm the deployed version rather than relying on a completed change ticket, and move unsupported branches to a supported release. If patching cannot happen immediately, the agencies advise avoiding the Classic Web Client and using another mail client until the server is fixed.
Then hunt backwards from the durable changes. Inventory application-specific passwords created for Zimbra accounts, identify those named ZimbraWeb, and compare creation times with IMAP preference changes. Revoke unexplained passcodes and active sessions. Reset affected passwords and two-factor recovery material. Disabling IMAP alone is insufficient if another persistence path or stolen credential remains.
Review proxy logs for the 90-day archive pattern and bulk GAL searches. Preserve audit.log, mailbox.log, nginx.access.log, DNS and endpoint network records before routine retention removes the overlap. Scope any account with matching activity as a data-loss case, because the script attempts immediate collection. Do not wait for a known Flowerbed domain to confirm it.
Finally, follow the identity dependencies. Identify cloud and SaaS accounts that use the mailbox for password recovery or receive administrative alerts. Search their audit logs for new sessions, changed recovery settings, added credentials, unusual API access, or bulk downloads after the first suspicious Zimbra event. The right incident boundary is not the Zimbra host. It is every identity and data store the stolen mailbox could unlock.