Critical Security Vulnerability in ESXi Hypervisors Targeted by Multiple Ransomware Operators
Microsoft researchers have discovered a security vulnerability that multiple ransomware operators are exploiting to gain full administrative privileges on domain-joined ESXi hypervisors. ESXi hypervisors host virtual machines that may contain critical servers within a network. In a ransomware attack, having full administrative access to an ESXi hypervisor allows a threat actor to encrypt the file system, disrupting the functionality of hosted servers. Additionally, the attacker could access hosted virtual machines, potentially exfiltrate data, or move laterally within the network.
Identified as CVE-2024-37085, this vulnerability involves a domain group that grants full administrative access to the ESXi hypervisor by default, without proper validation. Microsoft reported the findings to VMware through the Coordinated Vulnerability Disclosure (CVD) process via Microsoft Security Vulnerability Research (MSVR), and VMware has since released a security update. Microsoft strongly advises ESXi server administrators to apply the VMware updates and follow the mitigation and protection guidelines outlined in our blog. We also thank VMware for their cooperation in addressing this issue.
This blog provides an analysis of CVE-2024-37085 and details an attack leveraging this vulnerability, demonstrating the importance of collaboration between researchers, vendors, and the security community.
Analysis of CVE-2024-37085 Vulnerability
Microsoft security researchers identified a new post-attack technique used by ransomware operators such as Storm-0506, Storm-1175, Octo Tempest, and Manatee Tempest in multiple attacks. This technique has frequently led to the deployment of Akira and Black Basta ransomware. The technique involves running commands that create a group named “ESX Admins” in the domain and adding a user to it:
The researchers found that the attackers were exploiting a vulnerability that allowed them to gain full administrative access on the ESXi hypervisor. This finding was reported to VMware earlier this year as part of a vulnerability disclosure.
Further analysis revealed that VMware ESXi hypervisors joined to an Active Directory domain grant full administrative access to any member of a domain group named “ESX Admins” by default. This group does not exist in Active Directory by default, but if created, members are granted full admin access. Notably, this access is granted based on the group name rather than a security identifier (SID).
Microsoft researchers identified three methods to exploit this vulnerability:
- Adding the “ESX Admins” group and a user
Any domain user with the ability to create groups can create the “ESX Admins” group and add themselves or other users to it, gaining full admin access on the ESXi hypervisor. - Renaming an existing group to “ESX Admins”
Attackers can rename an existing group to “ESX Admins” if they have the necessary permissions and add users to this group to elevate privileges. - Privilege retention on ESXi hypervisor
Even if the domain group assigned admin privileges is changed, “ESX Admins” retains full admin privileges until manually revoked.
These methods allow attackers to encrypt the file system of the hypervisor, access hosted virtual machines, and move laterally within the network. This vulnerability highlights the risks posed by improperly configured domain and hypervisor security.
Ransomware Operators Targeting ESXi Hypervisors
Ransomware actors have increasingly targeted ESXi hypervisors to facilitate mass encryption with minimal effort. ESXi hypervisors are often overlooked by security products, and ransomware operators can encrypt all hosted virtual machines, creating a widespread impact on the targeted organization. Actors such as Storm-0506, Storm-1175, Octo Tempest, and Manatee Tempest have supported or sold ESXi encryptors such as Akira, Black Basta, Babuk, Lockbit, and Kuiper.
The prevalence of these attacks has doubled over the past three years, according to Microsoft Incident Response (IR) data.
Leave a Reply
You must be logged in to post a comment.