Angreifer nutzen Zimbra-Lücke CVE-2026-73570 für Web-Shells und Diebstahl von Authentifizierungsgeheimnissen

Im Zentrum steht CVE-2026-73570 (CVSS-Wert 8.9), eine nicht authentifizierte Befehlsinjektion auf Betriebssystemebene, die zu Remote Code Execution führen kann. Voraussetzung ist, dass SNMP-Benachrichtigungen aktiviert sind und das optionale Paket zimbra-snmp installiert ist. Die Ausnutzung lässt sich über eine speziell präparierte SMTP-Anfrage, also eine E-Mail, gegen exponierte Zimbra-Server auslösen — ohne Authentifizierung und ohne Zutun eines Nutzers. Zimbra hat die Lücke im Juli 2026 mit Version 10.1.20 behoben.

Auf aktive Ausnutzung hatte zuerst das polnische CERT Polska im August 2026 hingewiesen. Die Behörde empfahl, die Datei “/var/log/zimbra.log” auf auffällige Neustarts von Zimbra-Diensten zu prüfen und nach Dateien in temporären Verzeichnissen sowie im Zimbra-Verzeichnis “webapps” zu suchen. Noch im selben Monat nahm die US-Cybersicherheitsbehörde CISA die Schwachstelle in ihren Katalog bekannter ausgenutzter Schwachstellen (KEV) auf und verpflichtete Bundesbehörden, die Korrekturen bis zum 24. August 2026 einzuspielen.

Die von Microsoft anhand von Telemetriedaten dokumentierte Angriffsaktivität fällt nach eigenen Angaben in das Intervall zwischen dem 20. Juli 2026, als Version 10.1.20 erschien, und dem 13. August 2026, als die Lücke öffentlich bekannt wurde. Zwischen dem 28. Juli und dem 7. August 2026 sondierten zwei unterschiedliche Out-of-Band-Scanning-Werkzeuge den Injektionspfad, um die Befehlsausführung zu bestätigen, ohne eine Folgeschadsoftware nachzuladen.

“Nach erfolgreicher Ausnutzung umfasste die beobachtete Aktivität das Ausbringen von JSP-Web-Shells und Reverse Shells, Rechteausweitung, persistente Werkzeuge für Fernzugriff und speicherbasierte Ausführung”, so Microsoft. “Die Bedrohungsakteure griffen zudem auf E-Mails zu und sammelten Authentifizierungs- und Mailbox-Daten, wobei die Erstellung von Archiven und anschließende Übertragungsaktivität beobachtet wurde.” Nicht jeder Host zeigte dabei alle Stufen der Angriffskette.

Die Angreifer führten Befehle unter dem Dienstkonto “zimbra” aus und verteilten aus Redundanzgründen mehrere JSP-Web-Shells über Jetty- und mailboxd-Anwendungspfade. Schadcode wurde direkt per wget oder curl geladen und ausgeführt, zusätzlich kamen interaktive Reverse Shells zum Einsatz. “Andere Ausführungsketten nutzten cron, systemd oder memfd_create, um wiederkehrende oder speicherbasierte Ausführung aufrechtzuerhalten”, erklärte Microsoft. “In einigen Fällen aktivierten die Angreifer vorübergehend Schreibzugriff auf ein öffentliches Verzeichnis, um die Web-Shell abzulegen, und stellten anschließend die Verzeichnisrechte wieder her, was die Sichtbarkeit der Änderung bei einfachen Rechteprüfungen einschränkte.”

Zu den weiteren Schritten der Angreifer zählen:

• Kartierung der Zimbra-Installation mit zmprov, um Mailbox- und MTA-Knoten zu identifizieren
• Prüfung, ob eine Zimbra-SSH-Identität vorhanden ist, um die Bewegung zwischen Zimbra-Hosts zu erleichtern
• Rechteausweitung durch Änderung der Konfigurationsdatei “/etc/pam.d/sudo”, wodurch das Dienstkonto “zimbra” uneingeschränkten und passwortlosen sudo-Zugriff erhält
• Anlegen eines systemd-Dienstes namens “zimlog.service” als zweiter Persistenzmechanismus mit Ausführung beim Systemstart
• Abgriff zentraler Dienst- und Authentifizierungsgeheimnisse über den Befehl “zmlocalconfig -s” statt einzelner Mailbox-Passwörter; die gewonnenen Zugangsdaten dienen authentifizierten LDAP-Abfragen nach hochwertigen Attributen wie zimbraPreAuthKey, zimbraAuthTokenKey und zimbraTwoFactorAuthSecret
• Nutzung der vorhandenen SSH-Identität unter “/opt/zimbra/.ssh/zimbra_identity” zur seitlichen Bewegung auf weitere vertrauenswürdige Knoten im Cluster; per Rsync wurden JSP-Web-Shells und Hilfsskripte zwischen Knoten übertragen
• Einsatz einer OpenSSL-verschlüsselten Reverse Shell zu angreiferkontrollierter Infrastruktur für Befehlsausführung, Nachladen von Schadsoftware und Abfluss von Befehlsausgaben

In mindestens einer Kampagne kam ein schlanker Shell-Downloader für eine in Go geschriebene Binärdatei namens Zimdown2 zum Einsatz, die ihrerseits als Installer für den Fernzugriffs-Agenten Zimclient2 fungiert. Zimclient2 bietet interaktiven Shell-Zugriff, bidirektionale Dateioperationen und SOCKS5-Proxying. “Er unterstützte WebSocket-, TLS- und reine TCP-Transporte und bot damit widerstandsfähigen Fernzugriff sowie mögliches Netzwerk-Pivoting über kompromittierte Zimbra-Server”, so Microsoft. Belegt seien mehrere Persistenzmechanismen: systemd-Dienste, OpenRC, cron, Shell-Startdateien, autorisierte SSH-Schlüssel und das Anlegen lokaler Konten.

Hinzu kommen Zimbra-spezifische Schadprogramme. Ein Go-basiertes Programm versucht, Zugangsdaten des Zimbra-Dienstkontos aus “/opt/zimbra/conf/localconfig.xml” auszulesen, um damit MySQL- und LDAP-Verbindungszeichenfolgen zur Zimbra-MySQL-Instanz aufzubauen und den Inhalt folgender Datenbanktabellen zu exportieren:

• mailbox
• mailbox_metadata
• mobile_devices
• out_of_office
• alle Tabellen im Namensraum zimbra.*

Das Implantat sammelt zudem Artefakte zu Zugangsdaten, Zertifikaten, LDAP-Geheimnissen, Mail-Regeln und Konfiguration und legt sie bereit. Die eingesammelten Dateien werden in ein ZIP-Archiv gepackt, um sie an einen entfernten Endpunkt zu übertragen.

“Auf einem kompromittierten Zimbra-Server archivierte der Akteur aktuelle Mailbox-Backup-Inhalte nach /opt/zimbra/final.tar.gz”, berichtete Microsoft. “Anschließend lud der Akteur AzCopy von hxxps://aka[.]ms/downloadazcopy-v10-linux herunter und rief es mit einer vom Operator bereitgestellten Azure-Blob-SAS-URL auf, die auf wsweb03[.]blob[.]core[.]windows[.]net/log/windows.log zeigte.” Diese Aktivität zeige das Einsammeln von Mailbox-Daten, das lokale Bereitstellen eines Archivs und einen Exfiltrationsversuch mit Cloud-Speicher-Werkzeugen; die verfügbaren Belege bestätigten nicht, dass die Übertragung erfolgreich abgeschlossen wurde.

Organisationen wird empfohlen, die Updates unverzüglich einzuspielen. Ist ein Patchen nicht möglich, sollten das Paket zimbra-snmp deinstalliert, SNMP-Benachrichtigungen deaktiviert und SNMP- sowie SMTP-Zugriff auf vertrauenswürdige Hosts beschränkt werden. Weitere Maßnahmen sind das Rotieren der Zimbra-Authentifizierungsgeheimnisse und das Durchsuchen des Servers nach redundanter Web-Shell-Persistenz.