Zimbra CVE-2026-73570 Community IR Toolkit

Detection-first, evidence-preserving incident-response helpers for Zimbra administrators investigating suspected exploitation of CVE-2026-73570.

[!CAUTION] This is an independent community project, not a vendor compromise oracle. The checker is read-only and reports evidence by severity; it cannot prove that a host is clean. If root compromise is confirmed or credibly suspected, treat the host as untrusted: preserve evidence, contain it, rotate secrets from a clean system, and rebuild on a supported platform.

What this repository does

• Searches local Zimbra/mail logs for command-bearing Service status change: records, including the original localhost form and staged file-write variants.
• Examines Zimbra SNMP/swatch state, known JSP persistence locations, unexpected recent JSPs, and possible copies of Zimbra.jsp.
• Reports GSocket/gs-dbus, fixed and randomized process masquerading, IRC/PowerBots, wrapped or volatile ELF, cron, rc.local, SSH-key, sudo, temporary-file, and live outbound-connection evidence.
• Collects a private, timestamped evidence bundle without mailbox content or automatic cleanup.
• Publishes incident-derived indicators with explicit evidence class, confidence, and status.

It does not exploit, fetch payloads, contact IOC infrastructure, remove artifacts, submit data, inspect mailbox content, or replace forensic analysis. An absence of findings can mean missing/rotated logs, inactive persistence, insufficient permissions, an unrecognized variant, or collection after attacker cleanup.

Quick start

Run on the Zimbra host from a trusted administrative session. Prefer collecting evidence before extensive investigation because live-system work can change volatile state and access times.

sudo ./scripts/check-zimbra-73570.sh
sudo ./scripts/check-zimbra-73570.sh --since-days 30 --json /secure/case/check-report.json
sudo ./scripts/collect-evidence.sh --output /secure/case

The checker exit codes are:

Checker output uses INFO, MEDIUM, HIGH, and CRITICAL categories. It deliberately does not collapse nuanced evidence into a single COMPROMISED flag. A JSON report is written only when --json is requested. File checks can be tested against an isolated fixture with --root; live process and network checks are then skipped.

The collector creates a mode-0700 directory and a compressed archive beside it, records collection metadata, and writes SHA-256 manifests. It reads suspicious files only to hash them and does not quarantine, truncate, chmod, delete, or execute them. The resulting bundle can contain sensitive hostnames, usernames, log excerpts, configuration, IP addresses, and public keys: keep it encrypted, access-controlled, and out of this repository.

Evidence model

Indicators are separated into:

• confirmed-on-host — observed in the sanitized incident evidence from the affected host; this proves an observation, not necessarily successful execution or attribution.
• confirmed-from-retrieved-payload — present in payload content retrieved during the incident; this does not prove that the payload ran or that infrastructure remains active.
• exploitation-attempt-only — observed in exploit/source request evidence; this does not by itself establish command execution.

See IOCS.md, iocs.csv, and iocs.json. No malware samples or victim-specific evidence are included. Repository tooling never contacts IOC infrastructure. URL records remain historical/unverified even when separately supplied samples allowed offline analysis; the repository does not claim present availability.

Incident-derived analytical chain

The sanitized evidence supports this working chain:

SMTP command-injection attempt
  -> execution as zimbra
  -> JSP persistence
  -> system inventory/recon
  -> GSocket deployment
  -> gs-dbus / [kcached]
  -> Perl IRC bot
  -> possible root escalation or persistence

This is an incident-derived chain, not universal CVE behavior. In the sanitized evidence set, download/execution as the service account, an interactive shell, a root-launched attacker-controlled Nginx configuration, root gs-dbus/[kcached] processes, and hourly root persistence are directly corroborated. The exact privilege-escalation mechanics, JSP deployment timeline, every payload branch, operator identity, and attribution remain evidence-dependent gaps. See docs/triage.md.

Response guidance

• Triage: interpret findings and preserve uncertainty.
• Persistence: locations, process masquerading, and validation.
• Containment: safe isolation and secret-handling priorities.
• Recovery: rebuild-first guidance for root compromise.

Do not publish live victim evidence or malware samples. After internal validation and authorization, defensive indicator packages may be shared with Shadowserver. URLhaus submissions should be limited to URLs independently verified as active malware-delivery URLs; historical or unverified URLs should not be submitted as active.

Validation

All tests use static fixtures and perform no network activity:

make validate

This checks Bash syntax, IOC schema/CSV/JSON consistency, fixture detection, machine-readable output, and repository hygiene. shellcheck is used when installed.

Support and contributions

Review CONTRIBUTING.md before proposing indicators or detection changes. Report security issues privately as described in SECURITY.md. Licensed under Apache-2.0; see LICENSE.