ESXi-Ransomware: wie Angreifer den Hypervisor erreichen und auf welche Härtung von ESXi und vCenter es ankommt

Wie ESXi-Ransomware funktioniert und wie Sie ESXi und vCenter härten

ESXi-Ransomware verschlüsselt virtuelle Maschinen vom Hypervisor aus statt innerhalb jedes Gastsystems. In den Fällen, die CISA, FBI und Mandiant beschreiben (siehe unten), drangen die Angreifer mit privilegierten Zugangsdaten ein und brauchten keinen Exploit für den Hypervisor: Sie meldeten sich an vCenter an, erlangten Root-Rechte auf den Hosts, starteten SSH, schalteten die VMs aus und verschlüsselten deren Dateien auf den Datastores, sodass alle VMs auf den betroffenen Hosts zugleich stillstanden.

Die Härtung, auf die es ankommt, unterbricht diesen Weg an jeder Stelle: Administratorrechte, die der produktive Verzeichnisdienst nicht vergeben kann, der Sperrmodus (Lockdown-Modus) mit gestopptem SSH und gestoppter ESXi Shell, ein mit Secure Boot und einem TPM erzwungenes execInstalledOnly, ein isoliertes Verwaltungsnetz, Patches aus Broadcoms Sicherheitshinweisen, Remote-Logging sowie Backups, deren Zugangsdaten außerhalb des Verzeichnisdienstes verwahrt werden. Die folgenden Einstellungen stammen aus Broadcoms Security Configuration Guide für vSphere 8.0, zuletzt aktualisiert am 16. September 2026. Broadcoms Dokumentation zu 9.0 vom 24. August 2026 beschreibt für ESX 9 dieselben Sperrmodi und dieselbe Durchsetzung von execInstalledOnly.

Der Angriffsweg in den Berichten von CISA, FBI und Mandiant

CISA, FBI und HHS schrieben im Oktober 2022, Akteure von Daixin Team hätten mit privilegierten Konten auf vCenter zugegriffen, für die ESXi-Server „Kontopasswörter zurückgesetzt“ und dann „SSH genutzt, um sich mit erreichbaren ESXi-Servern zu verbinden und Ransomware auszurollen“. Das Verschlüsselungsprogramm zielte auf Dateien unter /vmfs/volumes/, wo ESXi jeden eingebundenen Datastore bereitstellt, gemeinsam genutzte Datastores eingeschlossen. Am 29. Juli 2025 aktualisierten CISA, FBI und fünf Partnerbehörden ihre Warnmeldung zu Scattered Spider: Die Akteure suchen nach vCenter-Infrastruktur und Backups und „wurden dabei beobachtet, wie sie VMware-ESXi-Server verschlüsseln“. Nach Angaben vertrauenswürdiger Dritter haben sie bei jüngeren Sicherheitsvorfällen möglicherweise die Ransomware DragonForce eingesetzt.

Mandiants Bericht vom 23. Juli 2025 beschreibt eine Kampagne von UNC3944 aus der Mitte des Jahres 2025; die Aktivität dieses Akteurs überschneidet sich mit öffentlichen Berichten über Scattered Spider. Die Angreifer gaben sich zuerst als Mitarbeiter und dann als privilegierter Administrator aus und ließen sich vom Helpdesk beide Passwörter im Verzeichnisdienst zurücksetzen. Sie meldeten sich an vCenter an, öffneten die Konsole der vCenter-Appliance, starteten die Appliance über GRUB in eine Root-Shell neu und änderten das Root-Passwort der Appliance, um SSH-Zugriff zu ermöglichen. Außerdem kopierten sie die Verzeichnisdatenbank von der abgehängten virtuellen Festplatte eines Domänencontrollers. Von vCenter aus aktivierten sie dann SSH auf den ESXi-Hosts und setzten deren Root-Passwörter zurück. Über SSH kopierten sie das Verschlüsselungsprogramm in ein beschreibbares Verzeichnis wie /tmp, schalteten mit vim-cmd jede VM aus und verschlüsselten die VM-Dateien.

Härtungsmaßnahmen für ESXi und vCenter und was jede davon verhindert

Broadcom TechDocs, Security Configuration Guide für vSphere 8.0 (16. September 2026; Hardware-Maßnahmen 17. Juli 2026); VMSA-2024-0013; KB 369707; Mandiant, 23. Juli 2025 (Zeile zu Backups).

Das Assessment unserer Leistung Cyber-Resilienz umfasst Infrastruktur, Zugriffe und Backups und endet mit einer Risikokarte und einem priorisierten Maßnahmenplan. Schreiben Sie uns Ihre ESXi- und vCenter-Versionen und welche der Maßnahmen oben noch fehlen.

Hosts in der Domäne, ESX Admins und CVE-2024-37085

Tritt ein ESXi-Host der Domäne bei, erhält laut Broadcoms Dokumentation zu vSphere 8 die Verzeichnisgruppe ESX Admins „vollen administrativen Zugriff auf den Host, sofern sie existiert“; über die Mitgliedschaft in dieser Verzeichnisgruppe entscheidet also, wer den Verzeichnisdienst verwaltet. In VMSA-2024-0013 vom 25. Juni 2024 veröffentlichte Broadcom CVE-2024-37085: Mit ausreichenden Berechtigungen im Verzeichnisdienst konnte ein Angreifer vollen Zugriff auf einen Host in der Domäne erlangen, indem er die konfigurierte Verzeichnisgruppe, standardmäßig ESX Admins, nach ihrer Löschung neu anlegte. Die CISA nahm die Lücke am 30. Juli 2024 in ihren Katalog bekannter ausgenutzter Schwachstellen auf. Broadcom behob sie in ESXi 8.0 Update 3 und VCF 5.2 und plante für ESXi 7.0 oder VCF 4.x keinen Patch.

Auf älteren Builds ändert KB 369707 drei erweiterte Einstellungen, idealerweise bevor der Host der Domäne beitritt; die Änderungen greifen innerhalb einer Minute und ohne Neustart. Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd wechselt von true auf false und Config.HostAgent.plugins.vimsvc.authValidateInterval von 1440 auf 90. Config.HostAgent.plugins.hostsvc.esxAdminsGroup wechselt von „ESX Admins“ auf einen leeren Wert. Ab 8.0 Update 3 steht die Auto-Add-Einstellung standardmäßig auf false, eine Änderung, die Broadcoms KB 390063 auf „Sicherheitsbedenken“ zurückführt.

Der Fix schließt diesen Weg, doch wer den Verzeichnisdienst kontrolliert, kontrolliert weiterhin jede Host- oder vCenter-Rolle, die ihre Mitglieder aus Verzeichnisgruppen bezieht. In Broadcoms Baseline für vCenter heißt es: „Der vCenter Server muss Authentifizierung und Autorisierung für Administratoren trennen“; sie schlägt lokale SSO-Gruppen für die Autorisierung vor. Mandiant rät davon ab, ESXi-Hosts direkt an den Verzeichnisdienst anzubinden. Getrennte, personalisierte Administratorkonten vervollständigen das Konzept, wie unser Leitfaden zu Privileged Access Management erläutert.

ESXi-Sperrmodus (Lockdown-Modus), SSH und die ESXi Shell

Der Sperrmodus schaltet den direkten Zugriff auf einen Host ab, sodass Vorgänge über die Rollen und Berechtigungen von vCenter laufen; Broadcoms Baseline für ESXi 8 ist der normale Sperrmodus, und nach der Installation ist der Sperrmodus deaktiviert. Im normalen Sperrmodus können Exception Users mit Administratorrechten und die Konten in DCUI.Access weiterhin die DCUI nutzen, während der strenge Sperrmodus den DCUI-Dienst deaktiviert. Laut Broadcoms Tabelle zum Verhalten des Sperrmodus können dieselben Konten in beiden Sperrmodi SSH und die ESXi Shell nutzen, solange diese Dienste laufen. DCUI.Access enthält standardmäßig root, der Sperrmodus schließt SSH für root also nicht; die Baseline hält die Liste der Exception Users leer.

Broadcom warnt vor einem „möglichen Verlust des administrativen Zugriffs auf Hosts“ und verlangt an vCenter angebundene Hosts mit gesetzten Zugriffs- und Ausnahmelisten, bevor der Sperrmodus eingeschaltet wird. Weil sich der Sperrmodus aus dem vSphere Client deaktivieren lässt, hält er keinen Angreifer auf, der Administratorrechte in vCenter besitzt; er beschränkt den direkten Zugriff auf die Konten in Exception Users und DCUI.Access.

SSH und die ESXi Shell sind standardmäßig gestoppt, mit der Richtlinie „Start and stop manually“, und Broadcoms Dokumentation zu 9.0 weist Administratoren von ESX 9 an, sie „deaktiviert zu lassen, sofern Sie keine Fehlerbehebung oder Supporttätigkeiten durchführen“. Wird SSH gebraucht, setzt die Baseline UserVars.ESXiShellTimeOut auf 600 Sekunden, was begrenzt, wie lange die Dienste laufen, und UserVars.ESXiShellInteractiveTimeOut für inaktive Sitzungen auf 900 Sekunden.

execInstalledOnly, Secure Boot und VIB-Akzeptanzebenen

Broadcom schreibt, dass execInstalledOnly „hilft, Ihre Hosts vor Ransomware-Angriffen zu schützen“, indem es den VMkernel nur Binärdateien ausführen lässt, die als Teil eines gültigen VIB paketiert und signiert sind. Seit ESXi 8.0 ist diese Laufzeitoption standardmäßig aktiv, doch jeder mit Root-Rechten kann sie mit einem esxcli-Befehl auf /User/execInstalledOnly abschalten.

Broadcoms Baseline setzt außerdem die Boot-Option VMkernel.Boot.execInstalledOnly auf True (Standardwert nach der Installation: False), welche die Laufzeitoption übersteuert, und schaltet die Durchsetzung von Secure Boot ein. Mit TPM 2.0 „kann das TPM auch die Einstellung der Boot-Option execInstalledOnly in der Versiegelungsrichtlinie durchsetzen“, sobald die Durchsetzung von Secure Boot aktiv ist. KB 373898 setzt die Boot-Option mit esxcli system settings kernel set und -s execInstalledOnly -v TRUE und führt nach einem Neustart esxcli system settings encryption set mit --require-secure-boot=TRUE aus, danach mit --require-exec-installed-only=TRUE; esxcli system settings encryption get zeigt das Ergebnis.

Mandiant schrieb, dass ein erzwungenes execInstalledOnly das Verschlüsselungsprogramm in der Kampagne von UNC3944 „direkt blockiert hätte“. KB 373898 sagt außerdem, dass execInstalledOnly keine Skripte verhindert, die über Interpreter wie Python laufen, eine Einschränkung, die „bis einschließlich 8.x“ besteht. Broadcom warnt, dass Secure Boot mit per TPM erzwungener Verschlüsselung der Konfiguration die herkömmliche Wiederherstellung des Root-Passworts unbrauchbar macht; notieren Sie daher den Wiederherstellungsschlüssel und prüfen Sie vorher den Administratorzugang.

Die Akzeptanzebene „steuert, was ESXi zur Installation zulässt“, so Broadcom. Die Baseline verlangt PartnerSupported oder höher, was auch der Standard nach der Installation ist; auf dieser Ebene sind CommunitySupported-Pakete „unsigniert und lassen sich nicht installieren“.

vCenter-Härtung, Verwaltungsnetz und BMCs

vCenter verwaltet jeden registrierten Host, und in den oben beschriebenen Fällen reichten seine Administratorrechte bis zum Root-Zugriff auf den Hosts und auf der vCenter-Appliance. Broadcoms Baseline für das Systemdesign legt die Verwaltungsschnittstellen der Virtualisierung in ein eigenes Segment, frei von Workloads und nicht zugehörigen Systemen, das nur autorisierte vSphere-Administratoren von autorisierten Arbeitsplätzen aus erreichen. Die Baseline für vCenter beschränkt die Firewall der Appliance auf autorisierte Netze, während der Standard jede IP-Adresse akzeptiert, und lässt SSH auf der Appliance deaktiviert. Für BMCs verlangt die Hardware-Baseline, ungenutzte Funktionen und Zugriffswege zu deaktivieren und den Zugriff nur von den autorisierten Arbeitsplätzen des Virtualisierungsteams zuzulassen. Unser Leitfaden zu Netzwerksegmentierung und Mikrosegmentierung behandelt die Zonen und ihre Verkehrsflüsse.

VMSA-2026-0006 vom 29. Juli 2026 behob zwei kritische Lücken in vCenter, die „ein böswilliger Akteur mit Netzwerkzugriff auf vCenter“ ausnutzen konnte. Eine davon, CVE-2026-59310 im Syslog-Server von vCenter, nahm die CISA am 18. August 2026 in ihren Katalog bekannter ausgenutzter Schwachstellen auf. Die vCenter-Versionen mit den Korrekturen sind 9.1.0.0300, 9.0.2.0100, 8.0 U3k und 8.0 U2f. Derselbe Sicherheitshinweis behob CVE-2026-47876, eine kritische ESX-Lücke im VMXNET3-Adapter, über die ein Administrator innerhalb einer VM Code auf dem Host ausführen kann. Zu CVE-2025-22224, einer früheren Guest-to-Host-Lücke, behoben mit VMSA-2025-0004 vom 4. März 2025, lagen Broadcom Informationen vor, die auf eine Ausnutzung in freier Wildbahn hindeuteten.

Laut Broadcoms Baseline ist „zuerst vCenter Server zu aktualisieren“, danach ESXi. Für 7.0 verweist VMSA-2026-0006 Kunden mit einem Vertrag über Extended Support an den Broadcom-Support; die Termine für 8.x stehen in unserem Leitfaden zum Ende des allgemeinen Supports für vSphere 8.

Remote-Logs und Backup-Zugangsdaten außerhalb des Verzeichnisdienstes

Broadcoms Baseline für vCenter schreibt, dass zentralisierte Protokollierung „Manipulationen verhindert“. Die Baseline für ESXi setzt Syslog.global.logHost auf einen standortspezifischen Collector sowie Syslog.global.auditRecord.storageEnable und Syslog.global.auditRecord.remoteEnable auf True, damit Audit-Datensätze, die standardmäßig ausgeschaltet sind, auf dem Host gespeichert und an den Collector gesendet werden; vCenter hat eine eigene Einstellung für den Remote-Log-Server. Betreiben Sie den Collector außerhalb von vCenter und des produktiven Verzeichnisdienstes, und lassen Sie auf jedem Host NTP laufen, damit die Zeitstempel übereinstimmen.

In der von Mandiant beschriebenen Kampagne gab es die Backups schon nicht mehr, als die Verschlüsselung begann. Die Angreifer hatten sich mit gestohlenen Zugangsdaten eines Domänenadministrators am Backup-Server angemeldet oder ein von ihnen kontrolliertes Konto in die Sicherheitsgruppe Veeam Administrators im Verzeichnisdienst aufgenommen und dann jeden Job, jeden Snapshot und jedes Repository gelöscht. Mandiant rät zu einer eigenen, MFA-geschützten Sicherheitsdomäne für den Backup-Server und seine Repositories oder zu dedizierten Zugangsdaten, die nicht an den Verzeichnisdienst gebunden sind, zusammen mit unveränderlichen Repositories. Unser Leitfaden zum Veeam Hardened Repository behandelt die Seite der Repositories, der Leitfaden zu den ersten 72 Stunden der Wiederherstellung nach Ransomware die Reihenfolge der Arbeiten nach einem Angriff.

Checkliste zur ESXi-Härtung für einen Host

1. Gleichen Sie die Builds von Host und vCenter mit den Response Matrices der neuesten VMSAs ab; patchen Sie zuerst vCenter.
2. Führen Sie esxcli system settings encryption get aus und bestätigen Sie, dass die Durchsetzung von Secure Boot und von execInstalledOnly aktiv ist.
3. Prüfen Sie die Akzeptanzebene (PartnerSupported oder höher) und dass keine CommunitySupported-VIBs installiert sind.
4. Kontrollieren Sie, dass TSM-SSH und TSM gestoppt sind und auf „Start and stop manually“ stehen, mit Shell-Timeouts von 600 und 900 Sekunden.
5. Aktivieren Sie den normalen Sperrmodus, halten Sie die Liste der Exception Users leer oder dokumentieren Sie jeden Eintrag, und belassen Sie DCUI.Access bei root.
6. Führen Sie auf einem Host in der Domäne esxcli system permission list aus und entfernen Sie Einträge, die die Rolle Admin nicht haben sollten; vor 8.0 Update 3 wenden Sie KB 369707 an.
7. Richten Sie Syslog.global.logHost auf den entfernten Collector, setzen Sie Syslog.global.auditRecord.storageEnable und Syslog.global.auditRecord.remoteEnable auf True und starten Sie NTP mit dem Host.
8. Testen Sie, dass Verwaltungsschnittstelle und BMC nur aus dem Verwaltungsnetz und von den Arbeitsplätzen der Administratoren antworten.
9. Stellen Sie sicher, dass die VMs des Hosts in einem Backup liegen, dessen Administrator-Zugangsdaten außerhalb des produktiven Verzeichnisdienstes verwaltet werden, und notieren Sie den letzten Wiederherstellungstest.

Unser Engineering-Partner Vixen.UNO setzt solche Änderungen Schritt für Schritt in vereinbarten Wartungsfenstern um, mit Rollback-Plan. Nennen Sie uns, wie viele Hosts und vCenter-Instanzen Sie betreiben, und welche dieser Prüfungen heute fehlschlagen.

Was wir tun

Im Rahmen unserer Leistung Cyber-Resilienz auditiert unser Engineering-Partner Vixen.UNO Ihre Sicherheitslage über Infrastruktur, Zugriffe und Backups hinweg, und Sie erhalten eine Risikokarte und einen priorisierten Maßnahmenplan. Dieselbe Leistung richtet Netzwerksegmentierung, Multi-Faktor-Authentifizierung und Privileged Access Management ein, dazu Backup auf Veeam-Basis mit einem Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen, geprüft durch regelmäßige Testwiederherstellungen. Im Rahmen der VMware-Optimierung aktualisiert Vixen.UNO vSphere, vSAN, NSX und VCF in vereinbarten Wartungsfenstern, mit einem Rollback-Plan für jede Etappe. Eurokommerz hält den Vertrag; das erste Gespräch ist kostenlos, und der Preis des technischen Assessments steht vor Beginn fest.

FAQ