Viele Ransomware- oder Ransomware-as-a-Service (RaaS)- Gruppen besitzen inzwischen die Fähigkeit, virtuelle Maschinen direkt auf Hypervisor-Ebene zu verschlüsseln. Das heisst, es sind nicht einzelne Clients, Workstations oder Server auf Windows Betriebsystem-Ebene, sondern alle Maschinen, die virtualisiert - auf zum Beispiel VMware ESXi oder Microsoft Hyper-V - laufen, gleichzeitig betroffen. Die Cybersecurityfirma Crowdstrike hat dieser Thematik zwei interessante Blog-Posts gewidmet [1][2].
Ein kleiner aber wichtiger Aspekt der im letzten Blog-Post beschrieben wird, ist virtuelle Maschinen (VM) bei einem Verdacht auf einen Ransomwarevorfall nicht - und ich wiederhole - NICHT zu rebooten oder herunterzufahren. Das hat folgenden Grund: Solange die VMs laufen, sind einige relevante Dateien auf der Hypervisorebene gesperrt und es kann kein externer Schreibzugriff und somit keine Verschlüsselung durch Ransomware erfolgen. Beim Herunterfahren oder auch Reboot der VMs wird diese Sperre aufgehoben und die Verschlüsselung findet umfänglich statt. Ein Problem ist, dass viele Ransomwaregruppen diesen Reboot automatisch über die Ransomware einleiten. Man sollte diesen Gruppen aber nicht proaktiv helfen, die eigene Infrastruktur zu verschlüsseln, sondern Mittel etablieren, gezielt Hypervisor-Hosts und VMs im Unternehmensnetzwerk zu isolieren.
Ein Grund Hypervisor-Hosts nicht durchzustarten ist, dass Ransomware meist in temporären Verzeichnissen des Hosts abgelegt wird und ein Restart diese Verzeichnisse leert und daher die Möglichkeit unterbindet die Ransomware auf potentielle Fehler der Verschlüsselung zu untersuchen. Will man hier wirklich hart eingreifen, ist die direkte Unterbrechung der Stromzufuhr durch Steckerziehen einem Herunterfahren definitiv vorzuziehen.

Nun aber zu diesbezüglich etwas positiveren Themen ...

Da die Verschlüsselung durch Ransomware fast ausschließlich über direkt am Hypervisor-Host ausgeführte, schadhafte Software ausgeführt wird, kann man durch Unterbindung der Möglichkeit der Ausführung viel erreichen.
Hier kann man sich bei VMware einer Policy-Einstellung namens execInstalledOnly bedienen. Wird diese aktiviert, kann ausschließlich über VMware nativ installierte Software ausgeführt werden, was die Ausführung von Ransomware (Linux Binaries) auf dem Host verhindern sollte [3]. Leider hilft diese Maßnahme nicht gegen Python-basierte Ransomware Scripts (Python ist auf ESXi standarmäßig verfügbar), reduziert aber die allgemeine Angriffsfläche.
Bei Microsoft Hyper-V Servern sollte eine rigide Application Allowlist (früher Whitelist) etabliert werden, was auf Grund von einer recht überschaubaren Menge an Standardsoftware auf diesen Systemen ein geringer Aufwand sein sollte. Die Einstellungen diesbezüglich benötigen keine Zusatzsoftware [4].

 Die hier beschrieben Maßnahmen sind in keinster Weise als umfassender Schutz vor Ransomware auf Hypervisoren zu verstehen, sondern stellen ausschließlich exemplarisch Möglichkeiten dar.

[1] https://www.crowdstrike.com/blog/carbon-spider-sprite-spider-target-esxi-servers-with-ransomware/
[2] https://www.crowdstrike.com/blog/hypervisor-jackpotting-ecrime-actors-increase-targeting-of-esxi-servers/
[3] https://www.truesec.com/hub/blog/secure-your-vmware-esxi-hosts-against-ransomware
[4] https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control