Starting around Feb. 3, 2023, thousands of servers running older versions of VMware’s ESXi hypervisor were attacked in an aggressive, automated ransomware campaign. Ransomware groups have targeted VMware’s software before, but this attack was the largest mass attack against ESXi to date. The attack is continuing, although the number of infected servers is falling. The ransomware strain was dubbed ESXiArgs by the research community, as it targets ESXi virtual machines and creates files with the .args extension which contain parameters needed for the encryption process. It is unclear who is responsible for the attack and if some of the well-known ransomware groups may be involved.
Characteristics of this attack stand out from other ransomware attacks: it is automated, it appears to have not involved the exfiltration of data and the group doesn’t have a data leak site. The lack of data exfiltration and a data leak site is highly likely due to the scale of the operation, which likely made it extremely difficult for the threat actors to exfiltrate the sheer amount of data in such a short time frame. For defenders, there is a clear lesson: running out-of-date software directly exposed to the internet is extremely risky. The attack should also serve as a warning that the design and implementation of virtualized systems increases attack surface and in turn opportunities for attackers. What follows is a guide to what was attacked, why it was vulnerable and the subsequent impact.
ESXi Hypervisor: Gateway to Data
VMware’s ESXi is called a “bare metal” hypervisor because the underlying hardware on which it is installed doesn’t need an operating system. ESXi allows the hardware to be utilized for multiple virtual machines (VMs), which saves on hardware costs. ESXi is a fruitful target for attackers since it may be connected to several VMs and the storage for them. Security experts warn ransomware actors have built specific binaries to target these systems. Groups joining this trend include HelloKitty, Black Basta, Cheerscrypt and GwisinLocker.
Over the last few years, several vulnerabilities have been identified in ESXi, including CVE-2021-21974. The vulnerability is a heap overflow vulnerability within Open Service Location Protocol (OpenSLP), which is a network discovery tool. The vulnerability is remotely exploitable over port 427, and has a Common Vulnerability Scoring System Version 3.0 (CVSSv3) base score of 8.8. It’s suspected that it may be the vulnerability exploited in this attack. VMware said that “significantly out-of-date products” were targeted with vulnerabilities that had been addressed. It affects ESXi versions 7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG and 6.5 before ESXi650-202102101-SG. Due to other vulnerabilities in OpenSLP, VMware disabled OpenSLP starting in 2021 in ESXi versions 7.0 U2c and ESXi 8.0, which is the current version. A proof-of-concept (PoC) exploit for CVE-2021-21974 was published by Johnny Yu on May 25, 2021. The same day, Intel 471 analysts observed several threat actors discussing the PoC code and whether it might work for an attack.
The Targets
The infected ESXi servers were accessible from the internet, which means if CVE-2021-21974 was used, the servers were easy targets. Some of the highest infection numbers originated from machines on OVH Groupe SAS’ network in France. OVH wrote it had no “logical access” to its customers’ machines to remediate. OVH sent warning emails on the day of the attack to customers who had vulnerable machines and also blocked access to port 427 from the internet.
Those affected appear to be recovering now, in part due to advice from Turkish security researchers Enes Sonmez and Ahmet Aykac of the YoreGroup Tech Team. Sonmez and Aykac found that the ransomware in some cases encrypted the virtual machine disk file (.vmdk), which points to the actual data that is contained in the server-flat.vmdk file. The .vmdk can be rebuilt, but recovery of the server-flat.vmdk file is problematic if there’s no backup.
The success rate of their procedure appeared to be about 60%. Unsuccessful recovery attempts appear to be associated with multiple snapshots of the impacted VMs. The U.S. Cybersecurity and Infrastructure Agency (CISA) released its own script based on the work of Sonmez and Aykac to help victims recover files.
Because the infected ESXi machines were facing the internet, it meant generally good visibility on the numbers of machines infected. The ransomware replaced the hypervisor’s message of the day (MOTD) file with a plaintext version of the ransom note and on ESXi’s INDEX.HTML page. The ransom notes could be collected, as well as the associated bitcoin address supplied for payment, using specific queries on device search engines such as Censys and Shodan (credit: Twitter user @fastfire, who put together these resources). “Ransomwhere,” a crowdsourced ransomware payments tracker, collected 2,803 bitcoin payment addresses that appeared in ransom notes and noted that four payments were made totaling US $88,000 as of Feb. 6, 2023.
Censys and Shodan return different figures for the number of infected machines, presumably because some networks block scanning. As of Feb. 6, 2023, the 11 most-impacted countries according to Shodan in descending order were France with 223 impacted instances, the U.S. with 222 impacted instances, Germany with 110 impacted instances, Canada with 78 impacted instances, the Netherlands with 38 impacted instances, the U.K. with 36 impacted instances, Finland with 22 impacted instances, Poland with 20 impacted instances, Turkey with 11 impacted instances, and Austria and Ukraine with six impacted instances each. The number of impacted hosts in the U.S. increased dramatically since Feb. 5, 2023. The Shodan search engine revealed the most-targeted hosting providers were Cloud South, Hetzner Online, Joe’s Datacenter LLC, LeaseWeb, Online SAS, OVHcloud, Scaleway, WorldStream and Zenlayer.
Ransomware Analysis
The ESXiArgs ransomware appears to be based on the Babuk aka Babyk Locker ESXi version. It’s not the first time ESXi has been targeted by a Linux-based version of ransomware based on Babuk. Cheerscrypt, which Trend Micro notes was discovered around May 2022, was also similar to the ESXi version of Babuk. Babuk appeared in early 2021, but its source code was leaked in September 2021, allowing anyone to create their own variants. The ESXiArgs ransomware utilizes the Sosemanuk stream cipher previously observed in the Babuk and other strains based on leaked Babuk source code. But the perpetrators running the ESXiArgs ransomware campaign apparently modified the code to use Rivest–Shamir–Adleman (RSA) encryption instead of Curve25519 cryptography that Babuk originally used. The technical data derived from the ESXiArgs does not point to the possible identification of its developer.
Assessment
Several characteristics of the ESXiArgs ransomware attack make it stand out:
The attack was automated. Ransomware attacks eight to 10 years ago tended to be automated, but as ransomware gangs shifted to targeting companies and organizations, automation gave way to hands-on keyboard exploitation, which was required for a more thorough infection of larger networks. However, automating an attack such as this one does take skill.
The scale of the campaign and the large volume of data stored on the impacted VMware ESXi hypervisors suggest it’s unlikely the attackers could exfiltrate much data in such a short period of time. Ransomware groups usually exfiltrate sensitive data prior to encryption. If a victim doesn’t pay for a decryption key, a gang will threaten to release the data on a data leak site. The lack of exfiltration could mean the attack was rushed or they simply did not have the time to exfiltrate the sheer large amounts of data they had access to. There are no signs the ESXiArgs group has set up a data leak site – another notable difference from many current ransomware attacks. It’s also a sign that the ESXiArgs group is not affiliated with a ransomware-as-a-service (RaaS) gang, which usually offers a leak site.
Ransoms are set at just over two bitcoins (US $47,000), and victims are given three days to pay. Ransomware negotiation specialist Coveware calculated the median ransom payment for the fourth quarter of 2022 was US $185,972. The median value varies from quarter to quarter, but the amount sought in this case seems to align with a trend that victims are less responsive to demands for very large ransoms.
The low payment rate Ransomwhere reported suggests victims may be recovering their data or backups.
The scenario under which the attacks took place begs questions. Why weren’t the old ESXi instances updated or patched? It’s unclear, but it could be for many of the same reasons software just doesn’t get patched: an underestimation of the risk, internal political conflicts, time and effort. From a defender standpoint, leaving ESXi exposed to the internet is risky even with an up-to-date, patched version. It’s extremely risky to deploy out-of-date ESXi instances directly to the internet with a known exploit circulating for more than a year. VMware has an easy-to-use graphical user interface (GUI) tool within vCenter to patch ESXi. It has also published a Ransomware Resource Guide. Luckily for victims, it doesn’t appear this attack was widely debilitating, but this round with threat actors was easily avoidable. It should serve as a warning, however, that VMware is and will continue to be an alluring target for ransomware gangs.
Special thanks to Melissa Palmer, an independent security consultant, VMware certified design expert and ransomware resiliency architect, for her help with this post.
