Inhalt
In diesem Blog-Beitrag werden wir die neue Ransomware-Variante “ESXiArgs” analysieren, die sich auf eine große Anzahl veralteter, dem Internet ausgesetzter ESXi-Server auf der ganzen Welt ausgebreitet hat.
Angriffsvektoren
In der Vergangenheit wurde Ransomware, die auf ESXi-Hypervisor abzielte, größtenteils von manuell als spätere Phase eines allgemeinen Ransomware-Angriffs ausgeführt, bei dem zunächst andere Assets (Clients, Server) verschlüsselt wurden. Für den Zugriff auf diese Virtualisierungssysteme müssen in der Regel zunächst Anmeldeinformationen beschafft und die Konfigurationsoptionen geändert werden, um einen Fernzugriff auf den Hypervisor zu ermöglichen, bei dem die Ransomware von den Angreifern durch einen “Hands-on-Keyboard”-Angriff ausgeführt wird.
Dies änderte sich zum Ende des Jahres 2022, als Juniper Threat Labs erstmals eine neuartige Backdoor entdeckte, die auf ESXi-Hypervisor abzielte. Einige Wochen später war dieses Backdoor-Skript die erste Komponente einer automatisierten Ransomware-Kampagne mit dem Namen “ESXiArgs” (nach den Zielsystemen und der Dateierweiterung .args). Die Verbreitung von ESXiArgs Ransomware stieg ab dem 2. Februar 2023 sprunghaft an, als die automatisierte Ausnutzung der Sicherheitslücke CVE-2021-21974 viele ESXi-Installationen mit Internetanschluss betraf, die z. B. bei OVH, Hetzner und anderen Hostern weltweit gehostet wurden. Das OpenSLP (Service Location Protocol) auf Port 427/tcp wird durch einen Heap-Overflow ausgenutzt, der zur Remote Code Execution auf dem ESXi-System führt. Öffentliche Exploitation-Tools sind seit Juni 2021 verfügbar. Laut der vom CERT-FR herausgegebenen Warnung betrifft die Schwachstelle ungepatchte Systeme mit den folgenden ESXi-Versionen:
- ESXi 7.x vor Patch ESXi70U1c-17325551
- ESXi 6.7.x vor Patch ESXi670-202102401-SG
- ESXi 6.5.x vor Patch ESXi650-202102101-SG
Zum Zeitpunkt der Erstellung dieses Blogartikels sind fast 2500 aus dem Internet erreichbare ESXi-Systeme von der ESXiArgs-Ransomware betroffen, wie die Suchmaschine Censys zeigt (basierend auf der Ransomnote, die auf der ESXi-Webschnittstelle vorhanden ist).
Abbildung 1: Censys Suche nach betroffenen Systemen
Analyse von ESXiArgs Ransomware
Abbildung 2: Erpresserschreiben auf einem betroffenen System
Nach der anfänglichen Ausnutzung von CVE-2021-21974 setzen die Angreifer das Backdoor-Skript “vmtools.py” ein, das zuvor von Juniper Threat Labs analysiert worden war. Die Web Shell besteht aus einem HTTP-Server auf Port 8008, der Postanfragen mit einer bestimmten Befehlsstruktur annimmt. Bei Anfragen mit der Aktion “local” werden Befehle auf dem Hypervisor-System ausgeführt und an die Web Shell ausgegeben. Mit der Aktion “remote” können die Angreifer eine Reverse Shell zur angegebenen Host-IP und Port öffnen.
Abbildung 3: vmtools.py Skript – verwendet für die Web Shell
Sobald die Persistenz auf dem Hypervisor erreicht ist, übertragen die Angreifer die Ransomware-Komponenten über eine Archivdatei namens “archieve.zip” auf das System. Diese enthält das Erpresserschreiben für das Web-Interface und die SSH-Message of the Day sowie ein Bash-Skript und eine ELF-Binärdatei für die Dateiverschlüsselung.
ESXiArgs Ransomware ist in einem Bash-Skript implementiert, während die mitgelieferte ELF-Binärdatei nur für den Verschlüsselungsprozess verwendet wird.
Betrachten wir zunächst das Skript:
Zunächst sammelt ESXiArgs eine Liste der Festplatten- und Auslagerungsdateien für die konfigurierten VMs auf dem Hypervisor und benennt diese um. Im Gegensatz zu vielen anderen ESXi-Ransomware-Implementierungen verwendet ESXiArgs keine Dienstprogramme wie “esxcli”, “vmware-cmd” oder “vim-cmd”, um laufende VMs herunterzufahren und diese anschließend zu verschlüsseln, sondern beendet lediglich den vmx-Prozess. Diese Aktion kann möglicherweise zu Fehlern oder zur Beschädigung von VM-Daten führen.
Abbildung 4: Umbenennen der Konfigurationsdateien und Beenden des vmx Prozesses
Beim Verschlüsseln von VM-Daten durchläuft ESXiArgs eine Liste von Volumes und versucht, VM-Speicher- und Konfigurationsdateien mit Hilfe von blockweiser Verschlüsselung zu verschlüsseln. Die Information, welche Datei verschlüsselt werden soll, wird als Argument an das “encrypt”-Binary übergeben, das wir in Kürze analysieren werden.
Abbildung 5: Datei-Verschlüsselungsroutine
Nach der Verschlüsselung der VM-Dateien legt die Ransomware zwei Ransomnotes ab: Die erste überschreibt die vSphere-Web-Oberfläche (siehe Abbildung 2) und die zweite überschreibt die SSH-Nachricht des Tages, die bei der Anmeldung angezeigt wird.
Um ihre Spuren zu verwischen und die weiteren Ermittlungen zu erschweren, löscht ESXiArgs die Log-Dateien auf dem System.
Abbildung 6: Hinterlassen des Erpresserschreibens und Löschen der Log-Dateien
Schließlich entfernt ESXiArgs seine Persistenz (z. B. über /etc/rc.local.d/local.sh) und löscht alle Artefakte, die für den Verschlüsselungsprozess verwendet wurden, um als Anti-Analyse-Maßnahme zu dienen.
Abbildung 7: Löschung von Artefakten und Entfernen der Persistenz
Die ESXiArgs “encrypt”-Binärdatei ist eine 64bit LSB ELF-Datei mit noch intakten Debug-Informationen. Da es nur die eigentliche Dateiverschlüsselung durchführt, ist es mit einer Dateigröße von 48 KB relativ klein.
Abbildung 8: Informationen zu der “encrypt” Binärdatei
Die Binärdatei verfügt über einen Verwendungsdialog und erfordert die Übergabe des öffentlichen RSA-Schlüssels, des Dateipfads und der Werte für die unterbrochene Verschlüsselung als Argumente.
Abbildung 9: Hilfe-Menü für die “encrypt” Binärdatei
Die Dateiverschlüsselung erfolgt durch eine Kombination aus asymmetrischen RSA- und symmetrischen Sosemanuk-Algorithmen. Sosemanuk ist Teil des eSTREAM-Portfolios und kommt relativ selten in Ransomware zum Einsatz. Aufgrund der in der Binärdatei enthaltenen Debug-Informationen vermuten wir, dass die Bedrohungsakteure ihre Implementierung auf dieses Github repository gestützt haben könnten.
Abbildung 10: Sosemanuk and RSA Verschlüsselungsroutinen
Wiederherstellungs-Optionen
Vor einer versuchten Wiederherstellung virtueller Maschinen sollte der ESXi-Hypervisor gesichert und ein Backup erstellt werden. In einigen Fällen kann es vorkommen, dass die Verschlüsselung die VM-Daten nicht korrekt verschlüsselt hat und daher einige Daten wiederhergestellt werden können. Enes Sonmez & Ahmet Aykac vom YoreGroup Tech Team haben hier einen Wiederherstellungs-Workflow dokumentiert, der den Opfern helfen könnte, ihre VMs zeitnah wiederherzustellen. Es scheint jedoch, dass dieser Prozess nur für VM mit “Thin Provisioned”-Speicher gilt.
Update (2023-02-08): CISA hat ein Wiederherstellungsskript für betroffene Hypervisors veröffentlicht, Sie finden es auf GitHub.
Schutzmaßnahmen für Ihren Hypervisor
1 – Halten Sie Ihren Hypervisor auf dem neuesten Stand: Betroffene ESXi-Versionen sollten sofort auf den neuesten Patch aktualisiert werden. Versionen, die das End-of-Life der Herstellerunterstützung erreicht haben, sollten außer Betrieb genommen und auf eine neuere Version migriert werden.
2 – Machen Sie Ihren Hypervisor nicht aus dem Internet erreichbar: Dazu gehören alle Verwaltungsschnittstellen (LAN, IPMI), aber auch Protokolle und Funktionen wie SSH, OpenSLP, SNMP und vSphere (die alle standardmäßig deaktiviert sein sollten). Der Netzwerkzugriff auf den Hypervisor sollte durch eine Firewall eingeschränkt werden.
3 – Erstellen Sie Backups Ihres Hypervisors: Wie bei jedem anderen System, das von Ransomware betroffen ist, ist die Erstellung von Backups ein wichtiger Schritt zur zeitnahen Wiederherstellung des Dienstes. Dazu gehören virtuelle Festplattendateien ebenso wie VMware-Konfigurationsdaten für die VMs.
4 – Verwenden Sie Syslog, um Logs aufzubewahren: ESXiArgs und viele andere Hypervisor-spezifische Ransomware zielen auf die Löschung von Protokolldateien auf dem System ab, um weitere Untersuchungen zu verhindern. Daher ist es wichtig, diese Protokolle sicher zu exportieren und zu speichern.
5 – Deaktivieren Sie die Ausführung von unsignierter Software: Die Konfigurationsoption execInstalledOnly schränkt den ESXi Hypervisor so ein, dass nur sogenannte vSphere Installable Bundles (VIB) ausgeführt werden, zu denen ESXi-Softwarekomponenten oder von VMware genehmigte Anwendungen von Drittanbietern gehören. Unsignierte Ransomware-Binärdateien können daher nicht auf dem System ausgeführt werden. Es ist wichtig zu verstehen, dass diese Konfigurationsoption über UEFI SecureBoot (das ein unterstütztes Hardware-TPM erfordert) persistiert werden sollte, um sich gegen Ransomware zu schützen. Weitere Informationen über diese Funktion finden Sie hier.
6 – Überprüfen Sie die Benutzerauthentifizierung: Die Benutzerauthentifizierung sollte nicht über Active Directory erfolgen, um im Falle einer Kompromittierung des Domänencontrollers eine Ausbreitung auf den Hypervisor zu verhindern. Lokale Benutzerkonten sollten auf eine Kennwortrichtlinie, begrenzte Authentifizierungsversuche und vorübergehende Sperren beschränkt werden, wenn die Authentifizierung fehlschlägt.
Yara Regel
Yara Regeln für die Python, Bash and Binärdateien zu ESXiArgs Ransomware finden Sie in unserem Github repository.
Indicators of Compromise
Samples
Die Ransomware-Artefakte wurden von einem betroffenen Benutzer des BleepingComputer Forums bezogen.
11b1b2375d9d840912cfd1f0d0d04d93ed0cddb0ae4ddb550a5b62cd044d6b66 encrypt
10c3b6b03a9bf105d264a8e7f30dcab0a6c59a414529b0af0a6bd9f1d2984459 encrypt.sh
773d147a031d8ef06ee8ec20b614a4fd9733668efeb2b05aa03e36baaf082878 vmtools.py
Dateinamen
vmtools.py
encrypt
/tmp/tmpy_8th_nb
nohup.out
public.pem
archieve.zip
motd
MITRE ATT&CK Mapping
| Tactic | Technique | Description | Observable |
| Reconnaissance | Active Scanning: Vulnerability Scanning (T1595.002) | Threat Actors behind ESXiArgs are actively scanning for vulnerable ESXi Servers | CVE-2021-21974 artifacts |
| Initial Access | Exploit Public-Facing Application
(T1190) |
Explotation of OpenSLP | CVE-2021-21974 artifacts |
| Execution | Command and Scripting Interpreter: Python (T1059.006) | Backdoor/Web Shell implemented in Python | vmtools.py |
| Persistence | Boot or Logon Initialization Scripts: RC Scripts (T1037.004) | Persisting the Python backdoor | /etc/rc.local.d/local.sh |
| Command and Control | Non-Standard Port (T1571) | Web Shell implemented in vmtools.py | HTTP Post Server on Port 8008 |
| Command and Control | Non-Standard Port (T1571) | Reverse Shell implemented in vmtools.py | Reverse Shell via specified port; default fallback: 427 |
| Execution | Command and Scripting Interpreter: Unix Shell (T1059.004) | Ransomware functionality is implemented in Bash | encrypt.sh |
| Impact | Data Encrypted for Impact (T1486) | VM data is encrypted via RSA+Sosemanuk | encrypt binary |
| Impact | Service Stop (T1489) | Ending a process to power down VMs | Killing the vmx process in encrypt.sh |
| Impact | Defacement: External Defacement (T1491.002) | Defacement of the vSphere Web Interface | Overwriting index.html with the Ransomnote |
| Impact | Defacement: Internal Defacement (T1491.001) | Defacement of the SSH MOTD | Overwriting motd with the Ransomnote |
| Defense Evasion | Indicator Removal: Clear Linux or Mac System Logs (T1070.002) | Log file deletion | Deleting all .log files |
