Zimbra Zero-Day: Message-Triggered Mailbox Drain and 2FA Theft
Anyone else digging into the latest joint advisory from CISA, the NSA, and international partners regarding that Russian APT targeting Zimbra? The mechanics of this one are particularly insidious. It’s a zero-day in the webmail client that triggers simply by opening a malicious message—no attachment needed.
The payload is aggressive. It's not just skimming; it's aiming for the organization's soul:
- Last 90 days of emails
- Global Address List (GAL)
- Saved browser passwords
- 2FA recovery codes (this is the killer)
Since this exploits the web interface, traditional attachment sandboxing won't catch it. We need to rely on behavioral analysis. I've whipped up a quick KQL query for those of you hunting in Sentinel to look for anomalous volume in the /service/home endpoint, which often indicates bulk exfiltration:
CommonSecurityLog
| where DeviceProduct == "Zimbra"
| where RequestURL contains "/service/home/"
| where RequestMethod == "POST"
| extend BodyLength = strlen(RequestBody)
| project TimeGenerated, SourceIP, DestinationIP, BodyLength, RequestMethod
| where BodyLength > 1000000 // Threshold for large data exfil
| order by TimeGenerated desc
The fact that they specifically targeted the 2FA recovery codes suggests they plan for persistence even after the password reset. How is everyone handling the storage of these codes? Are we still seeing users saving them in browsers despite GPOs?
This is exactly why I advocate for disabling password saving in browsers via GPO. If they get the 2FA codes, it's game over regardless of the password complexity. For those running Zimbra, check your mailbox.log specifically for servlet requests that don't align with standard IMAP/POP traffic. I've pushed a temporary block rule for non-corporate IPs accessing the webmail client until the patch is fully rolled out.
Interesting vector. If the payload executes via a message preview pane, does it depend on a specific XSS vector or a deserialization flaw in the parsing engine? The article mentions 'opening the message was enough,' which screams client-side rendering bug within the Zimbra AJAX layer. Defenders should also look for outbound connections to known C2 infrastructure immediately following the authentication event.
Great KQL start, but you might want to also filter on Referer headers. In many of these webmail exploits, the malicious request comes from a strange referer or lacks one entirely compared to normal navigation. We're seeing some success correlating the Zimbra logs with proxy logs to see if the same IP is hitting other internal endpoints right after the login.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access