Microsoft Threat Intelligence beobachtete die Ausnutzung der Schwachstelle CVE-2026-73570 im SNMP-Benachrichtigungspfad innerhalb der Zimbra Collaboration Suite. Die Schwachstelle ermöglicht die Ausführung von Systembefehlen aus der Ferne ohne Authentifizierung oder Benutzerinteraktion, wenn das optionale Paket zimbra-snmp installiert und SNMP-Benachrichtigungen auf einem über das Internet erreichbaren Zimbra-Server aktiviert sind.
Microsoft zufolge beginnt die Ausnutzung mit einer speziell gestalteten SMTP-Nachricht. Dabei kann ein vom Angreifer kontrollierter Wert die Verarbeitung von SNMP-Benachrichtigungen erreichen und anschließend in einen Shell-Aufruf eingefügt werden, der mit der Überwachung des Dienststatus verbunden ist. Dadurch kann der Angreifer Befehle mit den Berechtigungen des Dienstkontos zimbra ausführen.
Ausnutzung begann vor der öffentlichen Bekanntgabe
Zimbra veröffentlichte die Fehlerbehebung am 20. Juli 2026 in Version 10.1.20, während die Schwachstelle am 13. August öffentlich bekannt gegeben wurde. Zwischen dem 28. Juli und dem 7. August beobachtete Microsoft externe Scan- und Testwerkzeuge, die über denselben Pfad die Möglichkeit zur Befehlsausführung überprüften, noch bevor die Schwachstelle öffentlich bekannt gegeben wurde.
Bei den Tests wurden HTTP-Anfragen, DNS- und ICMP-Abfragen sowie Befehle wie curl, wget, ping, nslookup und id verwendet, um die Befehlsausführung und den externen Zugriff auf den Server nachzuweisen, ohne dass stets eine vollständige Payload heruntergeladen werden musste.
Von der Befehlsausführung zur Kontrolle des Servers
Nach dem ersten Zugriff platzierten die Angreifer Hintertüren im JSP-Format in den Pfaden der Zimbra-Anwendungen, erstellten Reverse-Shell-Sitzungen und führten Prozesse im Hintergrund aus. Microsoft beobachtete außerdem die Verwendung von cron, systemd und memfd_create, um die Ausführung dauerhaft aufrechtzuerhalten oder eine Payload aus dem Speicher zu starten.
In einer Angriffskette wurden Komponenten, die zur Verwendung von sudo berechtigt waren, sowie ein mit PAM verbundener Pfad ausgenutzt, um die Berechtigungen des Kontos zimbra auf root zu erweitern. Die Angreifer installierten außerdem einen systemd-Dienst namens zimlog.service, dessen Name eine legitime Zimbra-Komponente nachahmt, um die Payload beim Systemstart auszuführen.
Die Aktivitäten beschränkten sich nicht auf den ersten Server. Die in Zimbra vorhandene SSH-Identität und das Programm rsync wurden verwendet, um Dateien und Hintertüren auf weitere Knoten innerhalb des Mail-Clusters zu übertragen. Dadurch wurde der Zugriffsbereich erweitert und die Abhängigkeit von einem einzigen Angriffspunkt verringert.
Zielgerichteter Zugriff auf Authentifizierungs- und E-Mail-Daten
Die Angreifer sammelten Werte aus den lokalen Zimbra-Einstellungen, darunter Zugangsdaten für LDAP-, MySQL-, Postfix-, Amavis- und Replikationsdienste. Außerdem zielten sie auf Schlüssel wie zimbraPreAuthKey, zimbraAuthTokenKey und zimbraTwoFactorAuthSecret.
Die Analyse von Microsoft weist darauf hin, dass einige Werkzeuge versuchten, E-Mail-Datenbanken, Gerätedaten und Einstellungen für Abwesenheitsnotizen sowie Zertifikate, private Schlüssel und Postfix-Konfigurationsdateien auszulesen. In einem Vorfall wurden aktuelle Sicherungskopien von Postfächern in einem Archiv gesammelt. Anschließend wurde AzCopy verwendet, um sie zu Azure Blob Storage zu übertragen. Die verfügbaren Beweise bestätigen nicht, dass der Transfer vollständig abgeschlossen wurde.
Was sollten Betreiber tun?
Die wichtigste Empfehlung lautet, alle Zimbra-Server auf Version 10.1.20 oder höher zu aktualisieren. Wenn eine sofortige Behebung nicht möglich ist, empfiehlt Microsoft, das optionale Paket zimbra-snmp zu entfernen, SNMP-Benachrichtigungen zu deaktivieren und den Zugriff auf SNMP und SMTP ausschließlich auf vertrauenswürdige Hosts zu beschränken.
Warnungen zu Reverse Shells auf aus dem Internet erreichbaren Mailservern sollten außerdem als Vorfälle hoher Priorität behandelt werden. Es sollte nicht genügen, nach den Namen bekannter Schadsoftware zu suchen, da einige der schwerwiegendsten Ergebnisse die Verwendung einer normalen interaktiven Shell ohne eine bestimmte Schadsoftwarefamilie umfassten. Zu den Reaktionsmaßnahmen gehören die Rotation von Zimbra-Geheimnissen und Authentifizierungsschlüsseln, die Überprüfung von systemd-Diensten sowie PAM- und sudo-Komponenten und die Suche nach unerwarteten JSP-Dateien und Spuren generierter Servlets auf allen Mailknoten.
Diese Untersuchung zeigt, dass das praktische Risiko nicht auf die Ausführung eines einzelnen Befehls beschränkt ist. Eine einzige Schwachstelle auf einem exponierten Mailserver kann sich zu einem Ausgangspunkt für das Sammeln von Geheimnissen, das Einschleusen dauerhafter Zugriffsmöglichkeiten, die Bewegung innerhalb des Clusters und den Versuch entwickeln, E-Mail-Daten zu extrahieren. Umgekehrt belegen Indikatoren wie das Erstellen eines Archivs oder das Ausführen eines Cloud-Übertragungswerkzeugs allein noch nicht den Erfolg eines Datendiebstahls. Dafür müssen Prozess-, Datei- und Kommunikationsprotokolle miteinander verknüpft werden, um festzustellen, was tatsächlich geschehen ist.