VMware vCenter RCE: Globale Ausnutzung von CVE-2026-59310

Die kritische Directory-Traversal-Schwachstelle CVE-2026-59310 (CVSS 9.8) in Broadcom VMware vCenter Server wird im Rahmen einer groß angelegten Kampagne aktiv ausgenutzt, von der nach Angaben des deutschen Unternehmens QUIRSO 361 eindeutige Opfer-IP-Adressen in 47 Ländern betroffen sind. Die Schwachstelle ermöglicht das Ausführen beliebigen Codes mit Root-Rechten auf der vCenter Server Appliance ohne vorherige Authentifizierung. Broadcom hat am 29. Juli 2026 einen Patch veröffentlicht, die Ausnutzung begann jedoch bereits fünf Tage nach der öffentlichen Offenlegung. Alle Organisationen, die VMware vCenter einsetzen, müssen den Patch umgehend einspielen und ihre Systeme auf Anzeichen einer Kompromittierung überprüfen.

Technische Details der Schwachstellen

Nach Angaben der NVD handelt es sich bei CVE-2026-59310 um eine Schwachstelle des Typs directory traversal in VMware vCenter Server. Die Ausnutzung verschafft einem Angreifer unmittelbare Codeausführung im Kontext von root auf der vCenter Server Appliance – ohne zuvor ein nicht privilegiertes Konto kompromittieren und anschließend die Rechte eskalieren zu müssen. Alle über den Cron-Daemon aufgezeichneten Befehle wurden bereits mit Superuser-Rechten ausgeführt.

Parallel dazu wurde auf einem der kompromittierten Systeme die Ausnutzung von CVE-2026-59309 beobachtet – einer Schwachstelle zur Umgehung der Authentifizierung in vCenter, nach der ebenfalls aktiv gescannt wird. Die Spuren der Ausnutzung von CVE-2026-59309 datieren vom 1. August 2026 und umfassen die Anlage eines administrativen Kontos, ohne dass Anmeldeereignisse für ein legitimes Konto protokolliert wurden. Dabei überschneiden sich laut QUIRSO die Aktivitäten zu den beiden Schwachstellen auf einem System nicht – der über CVE-2026-59309 angelegte Account „vcenter_admin“ wurde in den weiteren Angriffsphasen nicht verwendet.

Betroffene Produkte sind VMware vCenter Server, vCenter Server Appliance, VMware Cloud Foundation (einschließlich Version 9.0) sowie ESXi-Hosts.

Angriffsmechanismus und Tooling

Laut der Untersuchung von QUIRSO begann die Exploit-Kette für CVE-2026-59310 mit einem Missbrauch des Remote-Syslog-Mechanismus in der vCenter Server Appliance, um Dateien im Verzeichnis /etc/cron.d abzulegen – einem privilegierten Speicherort für automatische Ausführung. Das erste beobachtete Artefakt ist eine fehlerhaft formatierte Cron-Datei zz-poc59310-syslog.log, deren Name direkt auf die CVE-ID verweist und auf einen Ursprung in einem öffentlichen proof-of-concept schließen lässt.

Im Anschluss wurde über Befehle wie curl oder wget der Backdoor linuxFile (auch bekannt als systemlog oder linux_x86) nachgeladen. Dieses Implantat ermöglicht die entfernte Ausführung von Befehlen über einen WebSocket-Kanal: Es verbindet sich mit einem Steuerserver, empfängt Anweisungen, führt sie über /bin/sh aus und übermittelt die Ergebnisse zurück. Die Adresse des C2-Servers ist mittels XOR verschleiert und wird zur Laufzeit dekodiert. Trotz der Verwendung des unverschlüsselten Transports ws:// sind die Kommunikationsinhalte durch eine eigene Kryptografie auf Anwendungsebene geschützt. Das Implantat unterstützt automatisches Wiederverbinden und Persistenz über systemd und cron.

Persistenz und laterale Bewegung

Die Angreifer legten drei Cron-Jobs an, die sich als legitime VMware-Services tarnen:

• vmware-vpxd-stats-* – fügt den SSH-Schlüssel des Angreifers in die Datei authorized_keys für den Fernzugriff ein
• vmware-perf-collect-* – legt den JSP-Webshell vmware-perf-update.jsp ab
• vmware-perf-sync-* – legt denselben Webshell ab und führt ein Base64-kodiertes Skript zur Entwendung von Anmeldedaten und zum Anlegen des Kontos „adminuser“ mit Aufnahme in die Gruppe vSphere SSO Administrators aus

Zur Entwendung der Zugangsdaten wurde das Skript /tmp/.vmware-perf-upd.sh eingesetzt, das vmdir-Passwörter über eine Abfrage der Registry HKEY_THIS_MACHINE\services\vmdir oder, falls dies scheiterte, über das Python-Modul vmafd mittels der Aufrufe GetMachineName(), GetMachinePassword() und GetDomainName() ausliest. Die erbeuteten Zugangsdaten wurden für privilegierte Verzeichnisänderungen genutzt, einschließlich des Hinzufügens von Konten zur Administratorgruppe.

Zusätzlich wurde die Datei /etc/sudoers.d/vmware-perf angelegt, die dem Servicekonto perfcharts uneingeschränkten, passwortlosen sudo-Zugriff auf root gewährt. Auf ESXi-Hosts wurden lokale Konten (z. B. „adminuser“) erstellt, die anschließend zur Verteilung der Ransomware genutzt wurden.

Endphase: Ransomware als Rauchvorhang

Der Angriff endete mit dem Ausbringen einer Ransomware auf ESXi-Hosts, die Dateien mit der Endung .babyk verschlüsselt – ein Merkmal einer von Babuk abgeleiteten Familie. Nach Einschätzung von QUIRSO war die Verteilung der Ransomware vermutlich nicht das Hauptziel der Kampagne. Die Forschenden werten sie vielmehr als Rauchvorhang, der Verteidiger ablenken und die ESXi-Logs durch Verschlüsselung zerstören soll, wodurch Analysten die Telemetrie für die Untersuchung entzogen wird. Die Analyse von QUIRSO beschränkte sich auf ein einziges kompromittiertes System, sodass das Ausmaß der Ransomware-Verteilung bei weiteren Opfern unbekannt bleibt.

Bedrohungskontext und Attribution

QUIRSO geht mit mittlerer Zuversicht davon aus, dass die Kampagne von einem chinesischsprachigen Akteur durchgeführt wird, der vermutlich in der Zeitzone UTC+08:00 operiert. Diese Einschätzung stützt sich auf eine Kombination indirekter Hinweise: chinesischsprachige Artefakte in Skripten, Wiederverwendung von Materialien aus chinesischen Security-Publikationen, Nutzung chinesischsprachiger Management-Werkzeuge, eine Opferauswahl, die das chinesische Festland ausschließt, sowie Aktivitätsmuster, die mit Arbeitszeiten in UTC+08:00 vereinbar sind. Es ist zu betonen, dass diese Attribution nicht durch unabhängige Quellen bestätigt ist und ausschließlich auf der Untersuchung eines einzelnen Unternehmens beruht.

Geografische Verteilung der Opfer: Deutschland (55), USA (41), Türkei (38), Iran (26), Frankreich (25) – die übrigen verteilen sich auf 42 weitere Länder. Ein operativer Fehler der Angreifer: Der Server 5.34.176.100:5244 exponierte ein Set von Reverse-SSH-Werkzeugen über ein frei einsehbares AList-Verzeichnislisting.

Indikatoren einer Kompromittierung

Auf Basis der Untersuchungsdaten wurden folgende IOC erfasst:

• IP-Adressen: 146.59.252[.]178, 5.34.177[.]38, 185.144.28[.]120, 192.255.141[.]13, 5.34.176[.]100
• Domain: intel.se9ly9upbhay[.]shop
• C2-Adresse: ws://intel.se9ly9upbhay[.]shop:8080/ws
• Ports: 9861, 3232, 8080, 5244
• Artefakte auf dem Datenträger:zz-poc59310-syslog.log in /etc/cron.d, vmware-perf-update.jsp, /tmp/.vmware-perf-upd.sh, /etc/sudoers.d/vmware-perf
• Konten: vcenter_admin, adminuser, vcadmin
• User-Agent: GoodMoodle-VCFleet/1.0

Empfehlungen für die Reaktion

1. Installieren Sie umgehend den Patch für CVE-2026-59310 und CVE-2026-59309, der von Broadcom am 29. Juli 2026 veröffentlicht wurde. Ist ein Update in den nächsten Stunden nicht möglich, isolieren Sie vCenter vom Internet.
2. Prüfen Sie auf IOC: Scannen Sie /etc/cron.d auf ungewöhnliche Dateien und kontrollieren Sie, ob die Konten vcenter_admin, adminuser und vcadmin in vSphere SSO sowie lokal auf ESXi-Hosts vorhanden sind.
3. sudoers-Audit: Überprüfen Sie /etc/sudoers.d/ auf die Datei vmware-perf oder andere nicht legitime Konfigurationen.
4. Überprüfen Sie authorized_keys: Stellen Sie sicher, dass sich keine fremden SSH-Schlüssel in den Autorisierungsdateien der vCenter Server Appliance befinden.
5. Überprüfen Sie systemd-Services: Suchen Sie nach ungewöhnlichen Units, die mit den Binärdateien systemlog oder linux_x86 verknüpft sind.
6. Blockieren Sie die Netzwerk-IOC am Perimeter: die oben aufgeführten IP-Adressen und die genannte Domain.
7. Rotation der Zugangsdaten: Ändern Sie die Passwörter aller administrativen vCenter- und vmdir-Konten, insbesondere wenn das System nach dem 29. Juli 2026 aus dem Internet erreichbar war.

Das fünftägige Fenster zwischen der öffentlichen Offenlegung von CVE-2026-59310 und dem Beginn der massenhaften Ausnutzung bestätigt, dass kritische Schwachstellen in Virtualisierungs-Infrastrukturkomponenten innerhalb von Stunden und nicht erst nach Tagen dringend gepatcht werden müssen. Organisationen, die VMware vCenter mit Internetzugang betreiben, sollten von einer potenziellen Kompromittierung ausgehen und auf Basis der genannten Indikatoren ein vollständiges Audit durchführen – und sich nicht auf die Installation des Updates beschränken.