Zimbra BEC Research: 50+ Vulnerabilities Let Attackers Rewrite Mailboxes — Detection and Hardening Guide

Business Email Compromise has always been a patient crime. The classic playbook — breach a mailbox, sit quietly, map the approval chain, then strike at the wire-transfer moment — is something most mature SOCs have built detections around. Rapid7's newly announced collaborative research with Zimbra breaks that model in a way that should concern every organization running Zimbra Collaboration Suite on-premises or in hybrid deployments.

According to Rapid7's disclosure, the research uncovered more than 50 vulnerabilities in the Zimbra platform. The critical shift: several of these flaws don't just grant attackers read access to a mailbox — they let adversaries impersonate senders without credentials, control what a victim actually sees in their inbox, and alter shared documents and calendar entries. That last point deserves emphasis. An attacker who can rewrite a shared quote, an invoice attachment, or a calendar invite inside the victim's own collaboration environment isn't conducting observation-stage BEC. They're rewriting ground truth. Fraud detection controls that rely on "the user saw it in their own inbox" or "the document came from our own system" collapse under this model.

This post is written from the defender's chair. Rapid7 has indicated this is the first installment of a series, with technical details to follow — which means your window to get ahead of weaponization is right now, before public PoCs and mass scanning begin. If you operate Zimbra, treat this as a pre-disclosure hardening exercise.

Why This Matters More Than a Typical Mail Server CVE Drop

I've led IR engagements on Zimbra compromises over the years, and the platform has a consistent exploitation profile: internet-facing by design, a large and historically buggy attack surface (the /service/ endpoint family, the Classic and Modern web clients, zimlets, the admin console on TCP/7071), and post-exploitation tradecraft that is well-documented — JSP web shells dropped into the Jetty webapps tree, malicious zimlets for persistence, and Sieve filter abuse for mail exfiltration. Any new class of vulnerabilities that enables credential-less impersonation dramatically lowers the bar: the attacker no longer needs to phish a password or steal a session token to send a perfectly legitimate-looking internal email from the CFO.

Three defensive implications stand out:

1. Sender trust is broken. If an attacker can send as an internal user without authenticating as them, SPF/DKIM/DMARC on inbound mail won't help you — the message may never traverse your perimeter gateway, or it may be generated server-side with valid alignment.
2. Inbox visibility manipulation defeats user awareness. An attacker who can hide the victim's copy of a thread (or selectively show messages) can run a fraud conversation in a mailbox the victim believes is quiet. Your "did you receive anything unusual?" interview during IR becomes unreliable.
3. Document and calendar tampering is a fraud multiplier. Altering a shared invoice or inserting a fake meeting with updated wire instructions bypasses every attachment-sandboxing control you own, because the content lives inside a trusted system.

Technical Analysis: What We Can Reasonably Infer

Rapid7 has not yet published the individual vulnerability write-ups — that material is promised in upcoming installments of the series. What we can do now, as practitioners, is reason about the behavioral classes described and build detection coverage for the post-exploitation tradecraft those classes imply.

Affected platform

• Product: Zimbra Collaboration Suite (ZCS), Network Edition and Open Source Edition
• Deployment model: On-premises and self-hosted cloud instances are the primary risk population. Internet-exposed webmail (443), and particularly internet-exposed admin consoles (7071), are high-priority.
• Status: Coordinated research disclosure; specific CVE identifiers and fixed versions have not yet been enumerated in the public announcement. Track Rapid7's blog series and Zimbra's security advisories for the CVE list as it drops. Zimbra has a well-established pattern of mass exploitation within days of PoC publication (historical precedent: CVE-2022-27925, CVE-2023-37580), so assume that timeline applies here.

Attack chain — defender's view

Based on the described capabilities, a realistic chain looks like this:

1. Initial access: Exploitation of a Zimbra web-facing component (historically the /service/ endpoints, webmail handlers, or zimlet upload paths). Exploitation frequently does not require valid credentials — several disclosed flaws are described as allowing sender impersonation without them.
2. Execution/persistence: A JSP web shell written into the Jetty webapps directory (/opt/zimbra/jetty_base/webapps/zimbra/ or .../zimbraAdmin/), or a malicious zimlet deployed for session persistence. The Zimbra java process (Jetty) spawning shells or writing unexpected files is the single highest-fidelity host signal.
3. Mail-layer manipulation: Server-side Sieve filter creation via zmmailbox to forward, redirect, or hide messages; manipulation of folder visibility; sending mail as arbitrary internal users.
4. Fraud execution: Altered shared documents, tampered calendar invites with updated payment instructions, and BEC threads that the victim's own UI conceals from them.

Exploitation status

As of this writing, no public PoC or confirmed in-the-wild exploitation of these specific newly disclosed flaws has been reported, and no related entries have been added to CISA's Known Exploited Vulnerabilities catalog. That is a "not yet," not a "never." Zimbra exploitation historically follows disclosure within days, and the platform is a known target of both financially motivated actors and state-aligned groups. Build your detections now.

Detection & Response

The detection content below targets the observable post-exploitation behaviors of Zimbra compromise — the tradecraft that has been consistent across every Zimbra campaign I've responded to and that this new vulnerability class will almost certainly reuse. These rules assume you are shipping Zimbra host logs (audit.log, mailbox.log, nginx access/proxy logs, auth logs) into your SIEM, and running Sysmon-equivalent process telemetry or auditd on the Zimbra hosts. If you are not ingesting Zimbra logs today, that is gap number one — fix it this week.

SIGMA Rules

---
title: Zimbra Jetty Process Spawning Shell or Downloader
id: 3f8a1c42-7b9d-4e21-a6f3-9c1d2e5b8a01
status: experimental
description: Detects the Zimbra Jetty java process spawning shells, interpreters, or download tools — a hallmark of Zimbra web shell deployment following exploitation of the web-facing service endpoints.
references:
  - https://www.rapid7.com/blog/post/ve-business-email-compromise-rewriting-reality-zimbra-cve
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - '/opt/zimbra/'
      - 'jetty'
      - 'zmmailboxd'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/perl'
      - '/python'
      - '/python3'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Rare — Zimbra maintenance scripts run via cron as the zimbra user, not spawned from the Jetty daemon
level: critical
---
title: Web Shell or Unexpected File Written to Zimbra Webapps Directory
id: 6d2e9b14-3a7f-4c58-b921-4e6a0d3c7f22
status: experimental
description: Detects creation of JSP or executable content inside Zimbra Jetty webapps directories. New .jsp files appearing outside of a Zimbra patch/upgrade window are a strong indicator of web shell deployment.
references:
  - https://www.rapid7.com/blog/post/ve-business-email-compromise-rewriting-reality-zimbra-cve
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|contains:
      - '/opt/zimbra/jetty_base/webapps/zimbra/'
      - '/opt/zimbra/jetty_base/webapps/zimbraAdmin/'
      - '/opt/zimbra/jetty/webapps/zimbra/'
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.war'
  filter_paths:
    TargetFilename|contains:
      - '/opt/zimbra/jetty_base/webapps/zimbra/WEB-INF/'
      - '/opt/zimbra/jetty_base/webapps/zimbraAdmin/WEB-INF/'
  condition: selection and not filter_paths
falsepositives:
  - Zimbra patch or upgrade activity — suppress during documented maintenance windows only
level: high
---
title: Suspicious Zimbra Sieve Filter Creation for Mail Forwarding or Hiding
id: 9b4c7e06-2d1a-4f83-a3d5-8e2c6b1a4f77
status: experimental
description: Detects creation of Sieve mail filter rules containing forward/redirect actions or external addresses via zmmailbox — a standard BEC persistence and exfiltration technique also consistent with inbox-visibility manipulation described in the Rapid7 Zimbra research.
references:
  - https://www.rapid7.com/blog/post/ve-business-email-compromise-rewriting-reality-zimbra-cve
  - https://attack.mitre.org/techniques/T1114/003/
  - https://attack.mitre.org/techniques/T1098/002/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.collection
  - attack.t1114.003
  - attack.persistence
  - attack.t1098.002
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains:
      - 'zmmailbox'
      - 'addFilterRule'
      - 'afr'
  selection_action:
    CommandLine|contains:
      - 'redirect'
      - 'forward'
      - 'keep'
      - 'fileinto'
      - 'discard'
  condition: selection and selection_action
falsepositives:
  - Legitimate administrator bulk filter management — baseline admin usage and alert on deviation or execution tied to non-admin source hosts
level: high

A note on the third rule: addFilterRule alone is legitimate admin tooling. The value is in baselining — if your admins create filters twice a quarter from one jump host, any other execution is worth a page. The BEC-specific signal you're really hunting is a redirect/forward action pointing at a domain that isn't yours, or discard/fileinto rules designed to hide reply threads from the mailbox owner — the inbox-visibility manipulation this research highlights.

KQL Hunt — Microsoft Sentinel

This query assumes Zimbra syslog and mailbox/audit logs are ingested into Sentinel via the Syslog or CEF connector. It hunts for mail-rule manipulation and anomalous authentication patterns in Zimbra's own logging.

let ExternalDomains = dynamic(["gmail.com","outlook.com","proton.me","protonmail.com","yandex.","mail.ru","hotmail.com"]);
Syslog
| where TimeGenerated > ago(7d)
| where Computer has "zimbra" or ProcessName in ("zmmailbox","slogger","zmlogger")
| extend Msg = tostring(SyslogMessage)
| where Msg has_any ("addFilterRule","modifyFilterRules","redirect","forward")
    or (Msg has "filter" and Msg has_any (ExternalDomains))
| extend ExtractedTarget = extract(@"(?:redirect|forward)[^;@]*@([a-zA-Z0-9.-]+)", 1, Msg)
| extend Suspicious = iff(ExtractedTarget has_any (ExternalDomains) or (ExtractedTarget != "" and ExtractedTarget !endswith ".yourdomain.com"), "True", "Review")
| project TimeGenerated, Computer, ProcessName, Msg, ExtractedTarget, Suspicious, HostIP
| sort by TimeGenerated desc

Follow-on hunt for anomalous webmail/admin authentication — credential-less impersonation may manifest as sent mail with no corresponding successful auth for that user:

let AuthEvents =
    Syslog
    | where TimeGenerated > ago(7d)
    | where SyslogMessage has "mailbox.log" or ProcessName has "mailboxd" or SyslogMessage has "oip="
    | where SyslogMessage has_any ("auth -","AuthRequest","soap=AuthRequest")
    | extend AuthUser = extract(@"name=([^;\]]+)", 1, tostring(SyslogMessage)),
             SrcIP = extract(@"oip=([0-9a-fA-F:.]+)", 1, tostring(SyslogMessage));
let SentEvents =
    Syslog
    | where TimeGenerated > ago(7d)
    | where SyslogMessage has_any ("SendMsgRequest","s=smtp","lmtp")
    | extend Sender = extract(@"(?:from|name)=<?([^;>,\]]+)", 1, tostring(SyslogMessage));
SentEvents
| where isnotempty(Sender)
| join kind=leftanti (AuthEvents | where isnotempty(AuthUser) | summarize by AuthUser) on $left.Sender == $right.AuthUser
| project TimeGenerated, Computer, Sender, SyslogMessage
| sort by TimeGenerated desc

The second query is deliberately a hunt, not an alert — there will be edge cases (shared mailboxes, delegated sending, postfix-originated mail). Analysts should treat hits as triage leads: mail sent by a user with no corresponding webmail/ActiveSync/EWS authentication in the lookback window is exactly what credential-less sender impersonation looks like in telemetry.

Velociraptor VQL — Web Shell and Persistence Sweep

Deploy this as a hunt across your Zimbra server fleet to identify recently written web content and unexpected listeners:

-- Zimbra compromise sweep: recent webapp writes, suspicious files, unexpected listeners
LET webapps = SELECT FullPath, Mtime, Size,
       parse_file_with_regex(
           filename=FullPath,
           regex="(?i)(cmd|shell|exec|password|cmdshell|chopper|antsword|behinder)") AS SuspiciousContentHit
FROM glob(globs=[
    "/opt/zimbra/jetty_base/webapps/zimbra/**/*.jsp",
    "/opt/zimbra/jetty_base/webapps/zimbraAdmin/**/*.jsp",
    "/opt/zimbra/jetty/webapps/zimbra/**/*.jsp"
])
WHERE Mtime > now() - 60 * 24 * 3600
ORDER BY Mtime DESC

LET listeners = SELECT Pid, Name, Laddr, Lport, Raddr, Rport, Status
FROM netstat()
WHERE Status = "LISTEN"
  AND Name !~ "(?i)(java|nginx|postfix|master|mysqld|slapd|memcached|opendkim|cbpolicyd|amavis|clamd|sshd|systemd|zmswatch|zmconfigd|named|unbound)"

SELECT * FROM webapps
UNION ALL
SELECT NULL AS FullPath, NULL AS Mtime, NULL AS Size,
       format(format="LISTENER pid=%v name=%v %v:%v", args=[Pid, Name, Laddr, Lport]) AS SuspiciousContentHit
FROM listeners

Tune the listener allowlist to your actual Zimbra role layout (mailbox vs. MTA vs. proxy nodes run different service mixes). The 60-day JSP recency window catches shells planted since the last patch cycle; tighten it to your last known-good upgrade date for a sharper sweep.

Remediation and Hardening

With individual CVEs and fixed versions still pending publication, your actions fall into two phases.

Phase 1 — Now (pre-CVE-detail)

1. Track the disclosures. Monitor the Rapid7 research series and Zimbra Security Center. Zimbra historically releases patches alongside or shortly after research disclosure — when the CVE list and fixed versions drop, treat them as emergency-change candidates. Zimbra flaws routinely reach mass exploitation within days of PoC release.
2. Reduce attack surface immediately:
   • Restrict TCP/7071 (admin console) to a dedicated admin network or VPN. It should never be internet-reachable.
   • Place Zimbra behind a reverse proxy or WAF with strict URI filtering on /service/, /zimbraAdmin/, and zimlet upload paths.
   • Disable unused zimlets and audit deployed ones (zmzimletctl listZimlets). Malicious zimlets are a known persistence vector.
   • Enforce Zimbra's two-factor authentication for all accounts, and prioritize admin accounts.
3. Hunt retroactively. Run the VQL sweep and KQL hunts above across the last 90 days. Given the nature of this research, you should assume the vulnerability details — or close variants — may already be known to sophisticated actors. Look for JSP writes outside maintenance windows, filter-rule anomalies, and send-without-auth events.
4. Out-of-band verification for payments. This is the control that survives inbox rewriting: require wire-transfer and payment-instruction changes to be confirmed via a separate channel (voice call to a known number, not one from the email thread). No email-layer control compensates for an attacker who controls what the user sees.
5. Audit existing Sieve filters fleet-wide for external redirects and visibility-hiding rules (discard, fileinto obscure folders). Export with zmmailbox -z -m <user> gfrl and diff against baseline.

Phase 2 — When CVEs and patches land

Apply the vendor patches on an emergency timeline, verify version and build post-upgrade, and re-run the web shell sweep (patching does not remove an already-planted shell). If CISA adds any of the disclosed CVEs to the KEV catalog, federal civilian agencies will carry a BOD 22-01 remediation deadline — and every private organization should treat that deadline as their own.

Verification script

Run this on each Zimbra node to snapshot patch level, surface unexpected webapp content, enumerate filters with external redirects, and confirm admin-port exposure:

#!/bin/bash
# Zimbra compromise posture check — run as root or via sudo -u zimbra where noted
echo "=== Zimbra Version ==="
sudo -u zimbra /opt/zimbra/bin/zmcontrol -v

echo "=== Recently modified JSPs in webapps (last 60 days) ==="
find /opt/zimbra/jetty*/webapps/ -name '*.jsp' -mtime -60 -ls 2>/dev/null

echo "=== Deployed zimlets ==="
sudo -u zimbra /opt/zimbra/bin/zmzimletctl listZimlets 2>/dev/null | grep -iv "com_zimbra_"

echo "=== Sieve filters with external redirects/forwards (spot check all users) ==="
for u in $(sudo -u zimbra /opt/zimbra/bin/zmprov -l gaa); do
  rules=$(sudo -u zimbra /opt/zimbra/bin/zmmailbox -z -m "$u" gfrl 2>/dev/null)
  if echo "$rules" | grep -Eiq 'redirect|forward|discard'; then
    echo "--- REVIEW: $u ---"
    echo "$rules" | grep -Ei 'redirect|forward|discard|fileinto'
  fi
done

echo "=== Admin port 7071 binding ==="
ss -tlnp | grep 7071

echo "=== Listening services (compare against expected role baseline) ==="
ss -tlnp | grep -Ei 'java|nginx|master' | head -50

echo "=== Cron for zimbra user (persistence check) ==="
crontab -u zimbra -l 2>/dev/null

Review the filter output manually — a redirect to a free-mail provider or an unfamiliar domain in any mailbox is an IR ticket, not a configuration note. Likewise, any JSP modified outside a documented patch window warrants forensic triage before you assume benign intent.

The Bottom Line

The most dangerous sentence in Rapid7's summary is the easiest to skim past: attackers can "actively rewrite" the environment. Traditional BEC defense assumes the mailbox is a reliable record. This research demonstrates that on a vulnerable Zimbra stack, it isn't — the sender can be fabricated, the thread can be hidden from its owner, and the shared document can be altered in place. Your controls must therefore shift weight toward host-level detection (process and file telemetry on the Zimbra servers themselves), out-of-band business process verification, and rapid patch posture the moment the CVE list publishes. The organizations that hunt and harden this month will be the ones that don't become the case studies in Rapid7's follow-up posts.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub