07. 02. 2023 Massimo Giaimo Blue Team, SEC4U

Ransomware Attack ESXi Servers with (to confirm) CVE-2021-21974

These days the landscape of cybercriminal activities seems to have as the only protagonists the Threat Actors who are carrying out an attack on publicly exposed VMware ESXi infrastructures.

The French National Computer Emergency Response Team (CERT) published a security advisory on the ESXiArgs ransomware on February 3, 2023.

Other important information regarding the attack was published by Bleeping Computer and OVH:

At the link https://blogs.vmware.com/security/2023/02/83330.html you can also find information released directly by VMware.

In particular, OVH has released the following observations regarding the behavior of the ransomware:

The compromise vector is confirmed to use an OpenSLP vulnerability that might be CVE-2021-21974 (still to be confirmed). The logs actually show the user dcui as being involved in the compromising process.
Encryption uses a public key deployed by the malware in /tmp/public.pem
The encryption process specifically targets virtual machines files (“.vmdk”, “.vmx”, “.vmxf”, “.vmsd”, “.vmsn”, “.vswp”, “.vmss”, “.nvram”,”*.vmem”)
The malware tries to shut down virtual machines by killing the VMX process to unlock the files. This function is not systematically working as expected, resulting in files remaining locked.
The malware creates an .args file to store arguments passed to the encryption binary (number of MB to skip, number of MB in encryption block, file size)
No data exfiltration occurred.

The facts

The Service Location Protocol (SLP) used by different versions of Vmware ESXI is vulnerable to a known CVE-2021-21974. The CVE enables remote code execution by an attacker on port 427 used by OpenSLP.

After executing the ransomware, the following message is displayed on the web administration interface and command line interface:

The Threat Actor, as can be seen from the note, requires 2.021404 bitcoins in order to obtain the decryption key. At the link https://gist.github.com/cablej/c79102960c4615396e8ffc712136744a it’s possible to have a fairly complete list of wallets used by the Threat Actor.

Contrary to what was initially indicated, the malware used by the Threat Actors was not Nevada, but ESXiArgs.

However, we are talking about a vulnerability (see other info about this vulnerability on NVD database) that is almost 2 years old and for which the fixes released by the vendor are available. Furthermore, it’s not yet certain that the exploited vulnerability is actually CVE-2021-21974, and subsequently there was also talk of the CVE-2020-3992 vulnerability.

Which versions of VMware ESXi are vulnerable?

ESXi versions 7.x prior to ESXi70U1c-17325551
ESXi versions 6.7.x prior to ESXi670-202102401-SG
ESXi versions 6.5.x prior to ESXi650-202102101-SG

How extensive is the attack?

It’s possible to get a good idea of the compromised surface using these queries within Shodan and Censys:

Shodan:

https://beta.shodan.io/search?query=html%3A%22We+hacked+your+company+successfully%22+title%3A%22How+to+Restore+Your+Files%22

Censys:

https://search.censys.io/search?resource=hosts&sort=RELEVANCE&per_page=25&virtual_hosts=EXCLUDE&q=services.http.response.body%3A+%22How+to+Restore+Your+Files%22+and+services.http.response.html_title%3A%22How+to+Restore+Your+Files%22

ZoomEye:

https://www.zoomeye.org/searchResult?q=yytf6btdhrikgywd6aluwbafjgm5oj3pan2lg3czvhs34obs3brid7ad

Recover your systems

Some really useful information for proceeding with the recovery of compromised servers has been posted at the link https://enes.dev/

Encryption script

At the link https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-support-topic-esxiargs-args-extension/page-14#entry5470686 the scripts used by the Threat Actor to encrypt the systems were shared:

Full script https://pastebin.com/y6wS2BXh

Script + encrypt binary https://we.tl/t-QMYhnF5evE

Useful tips to avoid compromise

Avoid exposing VMware ESXi administration web interfaces to the Internet and in general correctly segment access to these interfaces
Continuously install security patches
Disable the OpenSLP service

WurthPhoenix SOC monitoring

Our SOC Team is monitoring the situation and making available to the community the Indicators of Compromise that we find from time to time. You can view the IoCs at the link https://github.com/fastfire/IoC_Attack_ESXi_Feb_2023/blob/main/ip.md

These Solutions are Engineered by Humans

Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find security issues interesting, maybe you could start in a cybersecurity or similar position here at Würth Phoenix.