zimbra-cve-2026-73570-ir

Erkennungsorientiertes Incident-Response-Toolkit für Zimbra-Administratoren, die CVE-2026-73570 untersuchen. Durchsucht Protokolle nach Exploit-Indikatoren, untersucht Persistenzorte und sammelt zeitgestempelte Beweisbündel, ohne den Host-Zustand zu verändern.

Es nutzt nicht Exploits aus, ruft keine Payloads ab, kontaktiert keine IOC-Infrastruktur, entfernt keine Artefakte, übermittelt keine Daten, prüft keine Mailbox-Inhalte und ersetzt keine forensische Analyse. Das Fehlen von Befunden kann fehlende/rotierte Logs, inaktive Persistenz, unzureichende Berechtigungen, eine unerkannte Variante oder eine Sammlung nach der Bereinigung durch Angreifer bedeuten.

Schnellstart

Führen Sie dies auf dem Zimbra-Host aus einer vertrauenswürdigen administrativen Sitzung aus. Bevorzugen Sie die Beweissammlung vor umfangreichen Untersuchungen, da Arbeiten am Live-System den flüchtigen Zustand und Zugriffszeiten verändern können.

Die Exit-Codes des Checkers sind:

Die Checker-Ausgabe verwendet die Kategorien INFO, MEDIUM, HIGH und CRITICAL. Sie kollabiert bewusst keine nuancierten Beweise in ein einzelnes COMPROMISED-Flag. Ein JSON-Bericht wird nur geschrieben, wenn --json angefordert wird. Dateiprüfungen können mit --root gegen eine isolierte Testumgebung getestet werden; Live-Prozess- und Netzwerkprüfungen werden dann übersprungen.

Der Collector erstellt ein Verzeichnis mit Modus 0700 und ein komprimiertes Archiv daneben, zeichnet Sammlungsmetadaten auf und schreibt SHA-256-Manifeste. Er liest verdächtige Dateien nur, um sie zu hashen, und quarantänisiert, kürzt, chmoddet, löscht oder führt sie nicht aus. Das resultierende Bündel kann sensible Hostnamen, Benutzernamen, Logauszüge, Konfigurationen, IP-Adressen und öffentliche Schlüssel enthalten: Bewahren Sie es verschlüsselt, zugriffskontrolliert und außerhalb dieses Repositorys auf.

Beweismodell

Indikatoren werden unterteilt in:

• confirmed-on-host — beobachtet in den bereinigten Vorfallbeweisen vom betroffenen Host; dies beweist eine Beobachtung, nicht unbedingt eine erfolgreiche Ausführung oder Zuordnung.
• confirmed-from-retrieved-payload — vorhanden im Payload-Inhalt, der während des Vorfalls abgerufen wurde; dies beweist nicht, dass die Payload ausgeführt wurde oder dass die Infrastruktur weiterhin aktiv ist.
• exploitation-attempt-only — beobachtet in Exploit-/Quellcode-Anforderungsbeweisen; dies begründet für sich genommen keine Befehlsausführung.

Siehe IOCS.md, iocs.csv und iocs.json. Es sind keine Malware-Proben oder opferspezifische Beweise enthalten. Während der Entwicklung wurde keine Payload-URL kontaktiert; der URL-Status ist historisch/unverifiziert, sofern nicht eine vertrauenswürdige dritte Partei unabhängig etwas anderes feststellt.

Aus Vorfällen abgeleitete Analyse-Kette

Die bereinigten Beweise stützen diese Arbeitskette:

Dies ist eine aus Vorfällen abgeleitete Kette, kein universelles CVE-Verhalten. Im bereinigten Beweissatz werden Download/Ausführung als Dienstkonto, eine interaktive Shell, eine von Root gestartete angreiferkontrollierte Nginx-Konfiguration, Root-gs-dbus/[kcached]-Prozesse und stündliche Root-Persistenz direkt bestätigt. Die genauen Mechaniken der Privilegieneskalation, der JSP-Bereitstellungszeitplan, jeder Payload-Zweig, die Identität der Betreiber und die Zuordnung bleiben beweisabhängige Lücken. Siehe docs/triage.md.

Reaktionsleitfaden

• Triage: Befunde interpretieren und Unsicherheit bewahren.
• Persistenz: Orte, Prozess-Maskerade und Validierung.
• Eindämmung: Sichere Isolierung und Prioritäten beim Umgang mit Geheimnissen.
• Wiederherstellung: Rebuild-first-Leitfaden für Root-Kompromittierung.

Veröffentlichen Sie keine Live-Opferbeweise oder Malware-Proben. Nach interner Validierung und Autorisierung können defensive Indikatorpakete mit Shadowserver geteilt werden. URLhaus-Einreichungen sollten auf URLs beschränkt werden, die unabhängig als aktive Malware-Zustellungs-URLs verifiziert wurden; historische oder unverifizierte URLs sollten nicht als aktiv eingereicht werden.

Validierung

Alle Tests verwenden statische Testumgebungen und führen keine Netzwerkaktivität durch:

Dies prüft Bash-Syntax, IOC-Schema/CSV/JSON-Konsistenz, Erkennung der Testumgebungen, maschinenlesbare Ausgabe und Repository-Hygiene. shellcheck wird verwendet, wenn es installiert ist.

Unterstützung und Beiträge

Lesen Sie CONTRIBUTING.md, bevor Sie Indikatoren oder Erkennungsänderungen vorschlagen. Melden Sie Sicherheitsprobleme privat, wie in SECURITY.md beschrieben. Lizenziert unter Apache-2.0; siehe LICENSE.