dahnutz/zimbra-cve-2026-73570-irDetection-first incident-response toolkit for Zimbra administrators investigating CVE-2026-73570. Searches logs for exploit indicators, examines persistence locations, and collects timestamped evidence bundles without altering host state.
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.
Service status change: records, including the original localhost form, inline encoded-shell attempts, and staged file-write variants.Zimbra.jsp.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.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.
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:
| Code | Meaning |
|---|---|
| 0 | No medium/high/critical findings (not proof of safety) |
| 1 | One or more medium findings |
| 2 | One or more high or critical findings |
| 64 | Invalid usage |
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.
Indicators are separated into:
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 payloads were retrieved and analyzed; the repository does not claim present availability.
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.
Later rejected attempts and separately retrieved payloads add three branches for defenders to hunt: rotating zedi Perl IRC-bot variants using 103.114.163.234 on ports 80, 8080, or 8443; a da.sh loader that stages an UPX-packed XMRig-compatible miner plus configuration under /dev/shm/.ss; and an October 5 direct-ELF delivery attempt referencing a separately retrieved static PowerBot v0.6 build configured for 103.114.163.234:587, channel #ide, and process title /usr/bin/httpd -FOREGROUND. These payload capabilities do not establish execution on the monitored host. Exact hashes, paths, URLs, C2 sockets, and the configured wallet are in the IOC feeds; the public mining pool named by the configuration is dual-use and is not classified as malicious.
The October 11 sample update adds two ezo variants, including a modular Perl IRC shell with default C2 85.137.173.242:587 and [kworker/2:51S] masquerading, plus a revised miner loader using /dev/shm/.bbd. The IOC notes also document the new attempt-derived reverse-shell callback and the observed increase in command-bearing SMTP records.
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.
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.
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.