RansomExx Ransomware-Gruppe zielt auf VMWare ESXi-Schwachstellen

[English]Hinweis für Administratoren von VMWare ESXi-Systemen. Die RansomExx-Ransomware-Gang scheint in mehreren Vorfälle involviert, bei denen Schwachstellen in VMWare ESXi-Instanzen ausgenutzt wurden, um virtuelle Maschinen anzugreifen und deren virtuelle Festplatten zu verschlüsseln.


Anzeige

Ich bin über den nachfolgenden Tweet von Catalin Cimpanu auf das Thema aufmerksam geworden. Die Details hat er in diesem ZDNet-Artikel zusammen getragen.

RansomExx Ransomware incidents

Laut Sicherheitsforschern gibt es Hinweise, dass die Angreifer die beiden Schwachstellen CVE-2019-5544 und CVE-2020-3992 in der Virtualisierungslösung VMware ESXi nutzten, um die Festplatten zu verschlüsseln. Beide Schwachstellen betreffen das Service Location Protocol (SLP), , welches mehreren Geräten im selben Netzwerk ermöglicht, sich gegenseitig zu erkennen. Das Protokoll wird ebenfalls in VMware ESXi verwendet.

Laut ZDNet ermöglichen die Schwachstellen einem Angreifer böswillige SLP-Anfragen an ein ESXi-Gerät im selben Netzwerk zu senden und die Kontrolle darüber zu übernehmen. Das klappt selbst dann, wenn es dem Angreifer nicht gelungen ist, den VMWare vCenter-Server zu kompromittieren, an den sich die ESXi-Instanzen normalerweise anmelden.

Ein erster Angriff wurde im Oktober 2020 auf reddit.com im Beitrag Witnessed my first ESXi ransomware. Crypts VMs at datastore level gemeldet:

I always had thought it wasn’t possible, but here it is.

A customer’s environment went entirely offline and all VMs were powered off by the reports we were getting. Some started to think it was a SAN issue since it was so massive and didn’t spare any VMs.

Then, we saw 200 VMs abruptly shutdown and then all files on the datastore get encrypted (vmdk, vmx, logs, the works). The ransom note was left at datastore level.

The attack was directed, using a RaaS (Ransomware as a Service) code, because all files were encrypted with the company name on the extension of the crypted files. The ransom note also mentions the company name directly.

There was a Windows 2012R2 server outside VMware which seems to be the ground zero. Since it had access to the ESXi management URL, the mess may have started there.

Start locking your ESXi management access guys, things will get rough. this customer didn’t segregate ESXi management from the VMs.

​EDIT: Post-mortem posted here

Im Post-mortem-Artikel findet sich die Information, dass drei Benutzer in der Firma einen Mail-Anhang mit einem Trojaner angeklickt und somit installiert haben. Damit war der Schädling im gleichen Netzwerk und konnte die virtuellen Laufwerke der VMware ESXi-Maschinen angreifen und verschlüsseln. Weitere Details lassen sich ggf. dem ZDNet-Artikel entnehmen. Wichtig ist, die VMware ESXi-Installationen mit den verfügbaren Sicherheitsupdates zu versehen, um gegen diese Art Angriffe gefeit zu sein.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


Dieser Beitrag wurde unter Sicherheit, Virtualisierung abgelegt und mit Sicherheit, Virtualisierung verschlagwortet. Setze ein Lesezeichen auf den Permalink.

4 Antworten zu RansomExx Ransomware-Gruppe zielt auf VMWare ESXi-Schwachstellen

  1. Gabriel sagt:

    Ganz Ehrlich,
    da fühlt man sich als Admin VMware/Sys Admin doch irgendwie echt unwohl.
    Selbst wenn man sich alle Mühe gibt… das Szenario wird wohl nicht allzu selten sein.

    • 1ST1 sagt:

      Naja, dazu müssen die ESXi-Server erstmal für den Angriff erreichbar sein. Es wird doch wohl jede ESXi-Umgebung in einem separaten VLAN sein, mit Firewall davor, oder?

  2. Niels sagt:

    Wenn du dich mal in den Bereich Unternehmen kleiner 50 Mitarbeiter begibst, meist betreut von „externen IT Profis“ die primär einen effektiven Vertriebskanal haben, dann wirst du feststellen das VLANs dort generell nicht vorhanden sind.
    ESXi werden dort auch nie upgedatet, sondern laufen auf dem Stand der Erstinstallation.

    So zumindest meine Erfahrung der letzten Jahre.

  3. Thomas sagt:

    Wenn ich das richtig sehe gab es für CVE-2020-3992 auch keinen fix mehr für 6.0 da aus dem Support aber 6.0 müsste ja auch betroffen sein?
    Für die andere (CVE-2019-5544) gab es damals für 6.0 ja noch nen Patch (da noch im Support)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.