Over 2,500 ESXi servers around the world have now been hit by ransomware as part of a spray-and-pray campaign that began on Friday evening – with VMware affirming that it has “not found evidence that suggests an unknown vulnerability (0-day) is being used to propagate the ransomware used in these recent attacks.”
Florida's Supreme Court is among the organisations that have been hit. Numbers continue to rise.
Initial reports suggested that a vulnerability from early 2021 was being exploited. Some security researchers had been somewhat sceptical that not only were thousands of ESXi users not patching against severe remote code execution (RCE) vulnerabilities two years old but also directly exposing unpatched servers to the internet.
The campaign also began just days after security researchers published an exploit that lets remote and unauthenticated attackers take over VMware's log management tool vRealize Log Insight as root user by chaining three vulnerabiities that VMware disclosed on January 25, 2023. Two of the CVEs used (CVE-2022-31706, CVE-2022-31704) are remote code execution (RCE) bugs with critical CVSS ratings of 9.9.
There is no suggestion that this exploit is being used in the ESXi ransomware attacks.
SecurityScorecard’s Attack Surface IntelligenceASI tool detects some version of ESXi in use at 139,491 IP addresses worldwide. Not all of these will be vulnerable to the ongoing campaign. Shodan searches meanwhile suggest that 83,476 ESXI servers can be found online; the vast majority of these running version 6.7.
ESXi Servers exposed to the internet
VMware emphasised in a short blog on February 6 that “Most reports state that End of General Support (EOGS) and/or significantly out-of-date products are being targeted with known vulnerabilities”.
The ESXi ransomware campaign is targeting CVE-2021–21974, a VMware ESXi OpenSLP HeapOverflow leading to remote code execution that was first disclosed via the Zero Day Initiative (ZDI) by Lucas Leong.
Admins should ensure unpatched and exposed ESXi servers are firewalled, with no ports exposed. VMware’s earlier mitigation for the vulnerability urged users to 1: Login to the ESXi hosts using an SSH session (such as putty); 2: Stop the SLP service on the ESXi host with this command: /etc/init.d/slpd stop (nb The SLP service can only be stopped when the service is not in use; users can check thh operational state of SLP Daemon: esxcli system slp stats get 3: Run this command to disable the service: esxcli network firewall ruleset set -r CIMSLP -e 0
Leong published a short blog in March 2021 with an overview on how to exploit the vulnerability, noting that “Service Location Protocol (SLP) is a network service that listens on TCP and UDP port 427 on default installations of VMware ESXi. The implementation VMware uses is based on OpenSLP 1.0.1 [it] parses network input without authentication and runs as root, so a vulnerability in the ESXi SLP service may lead to pre-auth remote code execution as root. This vector could also be used as a virtual machine escape.”
(It was not immediately clear why it has taken this long to weaponise CVE-2021-21974 given that proof-of-concept exploits have circulated since at least May 2021 – among the reasons that some security researchers had speculated an ESXi zero day was being exploited – but it may be that someone has only just automated a script.)
One IT professional who used to run a co-location facility told The Stack that the cavalier approach to security among customers was not unusual. They said: “We had a provisioning tool that would install ESXi on a bare metal server with the root/ESXi12345 creds. Then we'd send you an email with the public IP (only public, you had your own VLAN, direct connections to the core layer) and creds. We basically never updated OS… rather passed that on to the customer to run updates [and few did].”
Xavier Bellekens, CEO of Lupovis said: "Over the course of the weekend, Lupovis has seen numerous new IPs scanning and exploiting the vulnerability, with attackers acting quick to catch organisations out before they have time to apply the patch. On Friday Lupovis saw three IPs scanning for vulnerable servers and by Monday morning this jumped to 40. On our decoys, we also saw the various IP touching most of our sectorial clusters which explains the diversity in targets in this campaign. Interestingly enough, it seems that most of the affected servers pointed to many different wallets, i.e. definitely looking at mudding their tracks. On Saturday we reported over 150 different wallets, by having a quick look, I have now seen reports of 350 new wallets to pay the ransom."
