Mass Zimbra Collaboration Suite Exploitation: 270+ Servers Breached via Unauthenticated RCE — Detection and Remediation Guide

Threat actors have breached more than 270 Zimbra Collaboration Suite (ZCS) instances in an ongoing, active exploitation campaign abusing an unauthenticated remote code execution vulnerability. This is not a theoretical exposure — attackers are already inside internet-facing mail infrastructure, dropping webshells and establishing persistence on servers that typically hold an organization's most sensitive communications.

Email servers sit at the intersection of identity, credential material, and confidential business communication. A compromised Zimbra host gives an adversary access to mailboxes, address books, calendar data, and — critically — a beachhead inside the network perimeter that outbound traffic monitoring frequently trusts. If you operate ZCS with any surface reachable from the internet, the correct posture right now is assume breach until proven otherwise.

What We Know About the Campaign

The attacks exploit a high-severity unauthenticated code execution vulnerability in Zimbra Collaboration Suite. The critical word is unauthenticated — no valid credentials, no user interaction, and no prior access are required. Any ZCS instance with the vulnerable component reachable from the internet is a target, and the observed victim count (270+ confirmed breached servers, with scanning and exploitation ongoing) indicates automated, indiscriminate mass exploitation rather than a targeted operation.

This pattern matches the modern exploitation lifecycle defenders see repeatedly: a vulnerability is disclosed or weaponized, working exploit logic circulates, and within days automated scanners sweep the entire IPv4 space for exposed Zimbra ports. Organizations that patch late — or that believe their Zimbra server is "too small to be a target" — are the ones filling the victim count.

Technical Analysis

Affected Platform

• Product: Zimbra Collaboration Suite (ZCS), Network Edition and Open Source Edition
• Attack surface: Internet-exposed Zimbra web services, typically TCP 443/8443/7071, and in some deployment patterns the mail-handling components themselves
• Exposure prerequisite: The vulnerable service reachable from an untrusted network. No authentication is required for exploitation.

How the Attack Works (Defender's View)

While exact exploitation mechanics vary with the specific flaw being abused, the observable attack chain in these Zimbra campaigns follows a consistent and highly detectable pattern:

1. Reconnaissance and exploit delivery — Attackers send crafted HTTP requests to the Zimbra web service. These requests often arrive from VPS/hosting-provider IP space, in bursts, and may target non-standard URI paths or specific service endpoints rather than the normal webmail login flow.
2. Code execution in the Zimbra process context — Successful exploitation executes attacker-controlled commands as the zimbra user (the service account under which ZCS runs). This is the pivotal detection moment: the Zimbra Java service or its associated components spawning shells, wget, curl, python, or bash.
3. Webshell deployment — The most common post-exploitation action is writing a JSP or PHP webshell into the Zimbra webroot, typically under paths like /opt/zimbra/jetty/webapps/zimbra/public/ or /opt/zimbra/jetty-distribution-*/webapps/. This converts a one-shot exploit into durable access.
4. Second-stage tooling and persistence — Operators then fetch additional payloads via curl/wget to external infrastructure, enumerate the host, and in some cases pivot into the internal network or begin harvesting mailbox content and credentials.

Exploitation Status

• Active, confirmed exploitation in the wild — 270+ servers already breached
• Ongoing campaign — Exploitation is continuing as of reporting; unpatched exposed instances are being compromised continuously
• Defender urgency: Critical. Treat as a zero-day-style incident even where a patch exists, because internet exposure plus unauthenticated RCE plus automated scanning equals near-certain compromise of unpatched hosts.

Post-Exploitation Artifacts to Hunt

Based on the observed behavior in this campaign class, prioritize these forensic artifacts on any Zimbra host:

• Newly created or modified .jsp, .jspx, or .php files in Zimbra webroot directories — especially files with recent timestamps, obfuscated content, or names mimicking legitimate Zimbra files
• Child processes spawned by the Zimbra Java process (/opt/zimbra/common/lib/jvm/java/bin/java) — sh, bash, curl, wget, python, nc, base64
• Outbound connections from the Zimbra host to non-standard destinations, particularly hosting/VPS providers and IP addresses with no business relationship to your mail flow
• Suspicious entries in /opt/zimbra/log/nginx.access.log and /opt/zimbra/log/mailbox.log — requests with encoded payloads, unusual URI patterns, or spikes of requests from single source IPs
• New files in /tmp, /dev/shm, or the Zimbra user's home directory; unexpected cron entries or systemd units

Detection & Response

This is a technical threat with active exploitation. The detections below are built around the highest-fidelity behaviors in the kill chain: the Zimbra service spawning a shell, and webshells appearing in the webroot. Tune threshold-based network detections to your baseline before deploying broadly.

Sigma Rules

---
title: Zimbra Service Spawning Shell or Downloader Process
id: 3f8a2b41-9c6d-4e12-a7f5-8d1c2b3e4f5a
status: experimental
description: Detects the Zimbra Java service process spawning shells, downloaders, or scripting interpreters — a high-fidelity indicator of post-exploitation following unauthenticated RCE against Zimbra Collaboration Suite.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - '/opt/zimbra/common/lib/jvm/'
      - '/opt/zimbra/lib/jars/'
      - 'zimbra'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate Zimbra administrative scripts (zmcontrol, zmmailboxdctl) — correlate with change windows
  - Backup or monitoring agents invoking zimbra CLI tooling
level: critical
---
title: Webshell File Created in Zimbra Webroot
id: 7c1d9e52-4a3b-4f08-b2e6-1a5c7d9e2f4b
status: experimental
description: Detects creation of JSP/PHP script files inside Zimbra web application directories — the dominant persistence mechanism observed in Zimbra mass-exploitation campaigns.
references:
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/opt/zimbra/jetty/webapps/'
      - '/opt/zimbra/jetty-distribution-'
  selection_ext:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.php'
  condition: selection_path and selection_ext
falsepositives:
  - Zimbra patch installation or version upgrades (correlate with maintenance windows and package manager logs)
level: high
---
title: Suspicious Encoded or Obfuscated HTTP Request to Zimbra Service
id: 9e4f6a13-2b7c-4d91-c8a3-5e6f1a2b8d3c
status: experimental
description: Detects HTTP requests to Zimbra services containing heavy encoding, command-injection metacharacters, or base64 — consistent with exploit delivery attempts against unauthenticated RCE flaws.
references:
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains:
      - '%2Fbin%2F'
      - '/bin/sh'
      - 'base64'
      - 'wget+'
      - 'curl+'
      - '|sh'
      - '%7Csh'
      - 'cmd='
  filter_normal:
    cs-uri-stem|contains:
      - '/service/soap/'
      - '/zimbra/'
  condition: selection and not filter_normal
falsepositives:
  - Vulnerability scanners and authorized penetration tests — allowlist known scanner IPs
level: high

KQL — Microsoft Sentinel / Defender

Zimbra hosts are Linux, so hunt via Syslog/CEF ingestion and any EDR coverage on the mail servers. The first query hunts the highest-fidelity signal — the Zimbra service spawning command interpreters. The second hunts webshell-stage outbound connections.

// Hunt 1: Zimbra service spawning shells or downloaders (Syslog/auditd process events)
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has_any ("zimbra", "jetty", "mailboxd")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl ", "wget ", "python", "base64 -d", "nc -")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, HostIP
| order by TimeGenerated desc
;
// Hunt 2: Outbound connections from Zimbra hosts to rare external destinations (webshell/payload retrieval)
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFolderPath has "zimbra"
    or DeviceName has_any ("zimbra", "mail", "zcs")  // scope to your mail server naming convention
| where RemotePort !in (25, 587, 465, 993, 995, 143, 110, 389, 636)  // exclude normal mail/LDAP flows
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DeviceName, RemoteIP, RemotePort, InitiatingProcessCommandLine
| where ConnectionCount < 50  // rare connections are more interesting in this context
| order by FirstSeen asc

Velociraptor VQL — Webshell and Post-Exploitation Hunt

Deploy this artifact across Zimbra hosts to surface recently created script files in webroot paths and suspicious processes running under the zimbra user context.

-- Zimbra webshell and post-exploitation hunt
-- Finds recently created/modified script files in Zimbra webroots
-- and suspicious processes executing in the zimbra context

LET webshells = SELECT FullPath, Mtime, Atime, Size
FROM glob(globs=['/opt/zimbra/jetty*/webapps/**/*.jsp',
                 '/opt/zimbra/jetty*/webapps/**/*.php',
                 '/opt/zimbra/jetty*/webapps/**/*.jspx'])
WHERE Mtime > now() - 2592000  -- modified in last 30 days
ORDER BY Mtime DESC;

LET suspicious_procs = SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Username =~ 'zimbra'
  AND Name =~ '(?i)(sh|bash|curl|wget|python|perl|nc|ncat|socat)$';

SELECT * FROM webshells
UNION ALL
SELECT FullPath=NULL, Mtime=NULL, Atime=NULL, Size=NULL FROM suspicious_procs;

For a cleaner two-panel hunt, run the two LET blocks as separate artifacts — one for webroot file triage, one for live process inspection. Sort webshell results by Mtime and diff against your last known-good Zimbra patch date; anything newer than your last legitimate maintenance window is a lead.

Triage and Verification Script

Run this on any Zimbra host to quickly assess compromise indicators before (or while) patching. It does not remediate — it surfaces evidence.

#!/bin/bash
# Zimbra compromise triage — run as root. Read-only; does not modify the system.
echo "=== Zimbra version ==="
su - zimbra -c 'zmcontrol -v' 2>/dev/null || zmcontrol -v

echo -e "\n=== Recently modified script files in Zimbra webroots (last 30 days) ==="
find /opt/zimbra/jetty*/webapps -type f \( -name "*.jsp" -o -name "*.php" -o -name "*.jspx" \) -mtime -30 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' 2>/dev/null | sort -r | head -50

echo -e "\n=== Suspicious files in /tmp and /dev/shm ==="
find /tmp /dev/shm -type f -mtime -30 -user zimbra -printf '%TY-%Tm-%Td %TH:%TM  %p\n' 2>/dev/null | head -30

echo -e "\n=== Zimbra user crontab (look for unauthorized entries) ==="
crontab -u zimbra -l 2>/dev/null

echo -e "\n=== Processes running as zimbra that should not be ==="
ps -u zimbra -o pid,comm,args 2>/dev/null | grep -E '(sh|bash|curl|wget|python|perl|nc|ncat|socat)' | grep -v grep

echo -e "\n=== Recent outbound connections from zimbra processes ==="
ss -tunp 2>/dev/null | grep -i zimbra | grep -v -E ':(25|587|465|993|995|143|110|389|636)\s'

echo -e "\n=== Access log anomalies: encoded payloads / command injection patterns ==="
grep -E '(%2Fbin%2F|/bin/sh|base64|wget\+|curl\+|\|sh|cmd=)' /opt/zimbra/log/nginx.access.log 2>/dev/null | tail -20

echo -e "\n=== Triage complete. Preserve logs before remediation: ==="
echo "tar czf /root/zimbra-ir-$(date +%F).tar.gz /opt/zimbra/log /var/log/zimbra.log"

Remediation

1. Patch immediately. Apply the current Zimbra security patch for your ZCS version per the official Zimbra Security Center advisories (https://wiki.zimbra.com/wiki/Security_Center) and the Zimbra release notes for your major version (8.8.15, 9.x, or 10.x). Verify the exact patched build number against the advisory — do not assume your package manager pulled the security release.
2. Assume compromise on previously exposed hosts. Patching does not evict an attacker who already dropped a webshell. For every Zimbra instance that was internet-exposed and unpatched during the campaign window, run the triage script above and hunt for webshells before and after patching. A clean patch on a breached host is not remediation.
3. Restrict the attack surface. Zimbra admin consoles (port 7071) must never be internet-reachable — restrict to management networks or VPN. Where business requirements allow, place webmail behind a WAF or reverse proxy with request inspection, and geo-fence or IP-allowlist access where feasible.
4. Preserve forensic evidence. Before rebuilding, archive /opt/zimbra/log/, /var/log/zimbra.log, webroot directory listings with timestamps, and process/network captures. If you find webshells, treat this as an incident: identify dwell time, determine whether mailbox data or credentials were accessed, and assess downstream notification obligations (relevant for HIPAA/PCI-scope environments where mail servers touch regulated data).
5. Rebuild rather than clean when in doubt. A compromised mail server with confirmed attacker code execution warrants a rebuild from known-good media with restored data, not file-level cleanup. Attackers with RCE on a mail host have too many persistence options (cron, systemd, modified Zimbra binaries, injected admin users) for surgical cleaning to be reliable.
6. Rotate credentials after confirmed compromise. Zimbra stores and handles authentication material. Reset admin credentials, service account secrets, LDAP bind credentials, and force password resets for mailboxes where evidence suggests access.
7. Add detection coverage going forward. Deploy the Sigma rules above via your EDR/Sysmon-for-Linux/auditd pipeline, ingest Zimbra host logs into your SIEM, and alert on any new script file appearing in Zimbra webroots outside of a change window.
8. Monitor for follow-on activity. Breached mail servers are frequently used for phishing infrastructure, spam relaying, and internal reconnaissance. Watch outbound SMTP volume anomalies and authentication logs for 60–90 days post-incident.

The pattern here is one defenders see on repeat: a high-severity unauthenticated flaw in edge-facing collaboration infrastructure, automated mass exploitation, and a victim count that climbs daily while organizations debate patch windows. Email infrastructure is not a system you patch on a monthly cycle when active exploitation is confirmed. Patch now, hunt before you patch, and treat every exposed unpatched instance as a breach investigation.

Related Resources

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