Es war ein schöner Tag dieser Freitag, der 03. Februar 2023, aber wie es Freitage im Cybersicherheits-Umfeld leider so an sich haben, sollte sich das schnell ändern.

Da dieser Vorfall inzwischen schon etwas weiter in der Vergangenheit liegt, ist Ruhe um ihn eingekehrt. Allerdings gibt es doch so manch interessanten Aspekt, der - zumindest mir bekannt - so noch nicht berichtet wurde.

Was mehr oder weniger allgemein bekannt ist …

Nach ersten Meldungen auf Twitter, dass hier etwas ganz und gar nicht Normales mit VMware ESXi Servern passiert, trafen in einem öffentlich zugänglichen Support-Forum [1] fast zeitgleich erste detailliertere Berichte über die Vorgänge von besorgten, hilfesuchenden System-Administratoren ein.

Quelle: https://twitter.com/mmarcha/status/1621481244922941440

Quelle: https://twitter.com/f2rv/status/1621483813523128322

Es war kein Zugriff auf die Server mehr möglich und die Systemverwalter wurden anstatt der gewohnten Nachricht auf der Login-Seite von einem Erpresserschreiben begrüßt. Die Systeme seien verschlüsselt und nur durch Bezahlung einer nicht unerheblichen Summe in Bitcoin an die Erpresser wieder in Betrieb zu nehmen.

Soweit nicht ungewöhnlich für solch geartete Vorfälle, auch wenn das Ausmaß der - über eine auch bis jetzt weiterhin nicht geklärte Schwachstelle (vermutet wird CVE-2021-21974 [2]) - kompromittierten Systeme noch nicht voll ersichtlich war. Da es sich bei ESXi-Servern um Virtualisierungs-Hosts handelt, auf denen teilweise zig Server- und Client-Systeme gleichzeitig laufen, konnte ein erheblicher Schaden vermutet werden.

Eine Suche auf Censys.io ergab ungefähr 3.800 betroffene Host-Systeme [3]. Wobei hier zu bedenken ist, dass diese Zahl auf den damals auffindbaren Hosts mit öffentlicher HTTP(S)-Schnittstelle und damit erkennbarer Erpressungsmeldung basiert.

Da die verwendete Webshell, die bereits im Dezember 2022 in einem Artikel von Juniper beschrieben wurde [4], auch Reverse-Shell-Eigenschaften (aktive Verbindung vom Host nach außen) hat, ist es möglich, dass hier weitaus mehr Systeme betroffen waren.

Die Verschlüsselung passierte in zwei (vielleicht sogar drei und einer vierten sehr frühen - mehr dazu später) Wellen, da im ersten Anlauf bekannt wurde, dass der verwendete Verschlüsselungsalgorithmus eine Schwachstelle besitzt und somit erlaubte, auch ohne Bezahlung der Erpresser, die Daten zu entschlüsseln.

Viele der Erpressten konnten die Webshell auf ihren Systemen nicht mehr auffinden, da das Verschlüsselungsscript diese nach erfolgreicher Ausführung gelöscht hatte, um Spuren zu verwischen. Allerdings wurde die Webshell weiter im Arbeitsspeicher ausgeführt - auch auf Systemen, wo sie durch den Administrator proaktiv gelöscht, aber kein Neustart durchgeführt beziehungsweise der Prozess nicht aktiv beendet wurde. Ein eingespielter Patch für CVE-2021-21974 [2] brachte bei bereits vorhandener Webshell ebenso keine Abhilfe, genauso wie ein Blockieren des Service Location Protocol (SLP) Ports für Zugriffe von außen. Die zweite Welle (rund um den 09. Februar 2023) mit nicht verwundbarem Verschlüsslungsmechanismus und Erpresserschreiben ohne Bitcoin-Adresse (zur schlechteren Verfolgbarkeit der Erpresser) konnte, während Administratoren bereits versuchten ihre Systeme wiederherzustellen, fast ungehindert ihren Lauf nehmen.

Info: Erpresserschreiben 03. Februar 2023 (mit Bitcoin-Adresse)

Info: Erpresserschreiben 09. Februar 2023 (ohne Bitcoin-Adresse)

Basierend auf Daten von Shodan.io dürfte es noch eine kleinere dritte Welle um den 15. Februar gegeben haben.

Die meisten weiteren bekannten Details sind in den Artikeln von BleepingComputer [5][6] und deren Support-Forum [1] ersichtlich.

Was nicht allgemein bekannt ist …

Wie sich zeigen sollte, war die Kompromittierung schon Monate beziehungsweise vielleicht Jahre zuvor geschehen und die ersten Opfer im Oktober 2022 (eines davon bereits im April 2021) hatten potentiell politische Relevanz.

Es ist weiter ungeklärt, wann genau die Webshell auf Systeme eingebracht wurde, da die Akteure bedacht darauf waren, die Zeitstempel der von ihnen erzeugten Dateien zu fälschen (Timestomping) und diese nach Abschluss der Verschlüsselung zu löschen. Bei der Untersuchung eines im Februar 2023 betroffenen Hosts konnten schwache Hinweise darauf gefunden werden, dass eine Kompromittierung bereits im Juli 2022 stattgefunden hat. Dies basiert auf einer Crash-Dump Datei des betroffenen rhttpproxy Services, welcher benutzt wurde, um über endpoints.conf am betroffenen System den Zugriffspunkt für die Webshell zu konfigurieren.

Da auf diesem Host das Verschlüsselungsscript fehlerhaft beendet wurde, blieben wertvolle Informationen erhalten.

Der Zugriff auf die Webshell erfolgte in diesem Fall von den IP-Adressen:

• 139[.]99[.]69[.]73
• 84[.]22[.]102[.]83

Von den zehn im Oktober 2022 betroffenen Hosts konnte mittels Censys.io, Shodan.io, Zoomeye.org und passive DNS festgestellt werden, dass zumindest acht davon im betroffenen Zeitraum eine ukrainische Top-Level-Domain inne hatten und damit eine politische Motivation potentiell ableitbar ist.

Quelle: https://trends.shodan.io/search?query=title%3A"How+to+Restore+Your+Files"#facet/ip

• 51[.]83[.]141[.]52 - novaposhtaglobal[.]ua - OVH SAS (SSL DC=vdc)
• 54[.]36[.]48[.]148 - esxi04.dentsuaegis.com[.]ua - OVH SAS
• 51[.]83[.]140[.]71 - novaposhtaglobal[.]ua - OVH SAS (SSL DC=vdc)
• 159[.]69[.]163[.]148 - dc2.vites.kiev[.]ua - Hetzner Online GmbH
• 51[.]77[.]43[.]28 - vdc.npint.com[.]ua - OVH SAS
• 51[.]83[.]237[.]4 - vdc.npint.com[.]ua - OVH SAS
• 136[.]243[.]76[.]47 - sb91.binco.com[.]ua - Hetzner Online GmbH
• 176[.]31[.]238[.]112 - ns342609.ip-176-31-238[.]eu - OVH SAS
• 51[.]83[.]184[.]96 - novaposhtaglobal[.]ua - OVH SAS (SSL DC=vdc)
• 95[.]217[.]75[.]225 - static.225.75.217.95.clients.your-server[.]de - Hetzner Online GmbH

Einer dieser zehn Hosts mit ukrainischer Top-Level-Domain (51[.]83[.]141[.]52) zeigte bereits im April 2021 ein entsprechendes Erpresserschreiben und wurde sogar viermal Opfer “dieser” Kampagne im April 2021, Oktober 2022, 03. Februar 2023 und 09. Februar 2023.

Eine erste Kompromittierung im April 2021 passt auch gut zur potentiell ausgenutzten Schwachstelle CVE-2021-21974 [2], die am 23. Februar 2021 in einem Advisory durch VMware [7] beschrieben und in einem Artikel der Zero Day Initiative [8] am 02. März 2021 detailliert erklärt wurde. Auch wenn der erste Proof-of-Concept Exploit [9] erst am 24. Mai veröffentlicht wurde.

Ableitbare Maßnahmen …

• Schnelles Patchen alleine reicht nicht. Eine weiterführende Untersuchung der Systeme ist gegebenenfalls notwendig.
• Management-Schnittstellen haben im öffentlichen Internet nichts verloren. Diese sollten ausschließlich über VPN oder ähnliche Lösungen erreichbar sein.
• Eingesetzte Endpoint Detection and Response (EDR) Lösungen sollten auch “Nischenprodukte” abdecken können.
• Aktives Suchen - “Hunting” - nach Unregelmäßigkeiten in allen im Unternehmen verwendeten Technologien.

[1] https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-support-topic-esxiargs-args-extension/
[2] https://nvd.nist.gov/vuln/detail/CVE-2021-21974
[3] https://gist.github.com/cablej/bdc2ee2c84915d0b68eec9d4d4747e19
[4] https://blogs.juniper.net/en-us/threat-research/a-custom-python-backdoor-for-vmware-esxi-servers
[5] https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/
[6] https://www.bleepingcomputer.com/news/security/new-esxiargs-ransomware-version-prevents-vmware-esxi-recovery/
[7] https://www.vmware.com/security/advisories/VMSA-2021-0002.html
[8] https://www.zerodayinitiative.com/blog/2021/3/1/cve-2020-3992-amp-cve-2021-21974-pre-auth-remote-code-execution-in-vmware-esxi
[9] https://straightblast.medium.com/my-poc-walkthrough-for-cve-2021-21974-a266bcad14b9

Eine Attribuierung zu bekannten Gruppen oder staatlichen Akteuren ist mit den vorhandenen Indicator of Compromise (IOCs) und Tacticts, Techniques und Procedure (TTPs) nicht durchführbar und liegt auch nicht im Interesse und direktem Aufgabenbereich von CERT.at.