Microsoft researchers have uncovered a vulnerability in ESXi hypervisors being exploited by several ransomware operators to obtain full administrative permissions on domain-joined ESXi hypervisors. ESXi is a bare-metal hypervisor that is installed directly onto a physical server and provides direct access and control of underlying resources. ESXi hypervisors host virtual machines that may include critical servers in a network. In a ransomware attack, having full administrative permission on an ESXi hypervisor can mean that the threat actor can encrypt the file system, which may affect the ability of the hosted servers to run and function. It also allows the threat actor to access hosted VMs and possibly to exfiltrate data or move laterally within the network.
The vulnerability, identified as CVE-2024-37085, involves a domain group whose members are granted full administrative access to the ESXi hypervisor by default without proper validation. Microsoft disclosed the findings to VMware through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR), and VMWare released a security update. Microsoft recommends ESXi server administrators to apply the updates released by VMware to protect their servers from related attacks, and to follow the mitigation and protection guidance we provide in this blog post. We thank VMWare for their collaboration in addressing this issue.
This blog post presents analysis of the CVE-2024-37085, as well as details of an attack that was observed by Microsoft to exploit the vulnerability. We’re sharing this research to emphasize the importance of collaboration among researchers, vendors, and the security community to continuously advance defenses for the larger ecosystem. As part of Microsoft’s commitment to improve security for all, we will continue to share intelligence and work with the security community to help protect users and organizations across platforms.
Microsoft security researchers identified a new post-compromise technique utilized by ransomware operators like Storm-0506, Storm-1175, Octo Tempest, and Manatee Tempest in numerous attacks. In several cases, the use of this technique has led to Akira and Black Basta ransomware deployments. The technique includes running the following commands, which results in the creation of a group named “ESX Admins” in the domain and adding a user to it:
net group “ESX Admins” /domain /add
net group “ESX Admins” username /domain /add
While investigating the attacks and the described behavior, Microsoft researchers discovered that the threat actors’ purpose for using this command was to utilize a vulnerability in domain-joined ESXi hypervisors that allows the threat actor to elevate their privileges to full administrative access on the ESXi hypervisor. This finding was reported as part of a vulnerability disclosure to VMware earlier this year.
Further analysis of the vulnerability revealed that VMware ESXi hypervisors joined to an Active Directory domain consider any member of a domain group named “ESX Admins” to have full administrative access by default. This group is not a built-in group in Active Directory and does not exist by default. ESXi hypervisors do not validate that such a group exists when the server is joined to a domain and still treats any members of a group with this name with full administrative access, even if the group did not originally exist. Additionally, the membership in the group is determined by name and not by security identifier (SID).
Microsoft researchers identified three methods for exploiting this vulnerability:
Successful exploitation leads to full administrative access to the ESXi hypervisors, allowing threat actors to encrypt the file system of the hypervisor, which could affect the ability of the hosted servers to run and function. It also allows the threat actor to access hosted VMs and possibly to exfiltrate data or move laterally within the network.
Over the last year, we have seen ransomware actors targeting ESXi hypervisors to facilitate mass encryption impact in few clicks, demonstrating that ransomware operators are constantly innovating their attack techniques to increase impact on the organizations they target.
ESXi is a popular product in many corporate networks, and in recent years, we have observed ESXi hypervisors become a favored target for threat actors. These hypervisors could be convenient targets if ransomware operators want to stay under the SOC’s radar because of the following factors:
Therefore, many ransomware threat actors like Storm-0506, Storm-1175, Octo Tempest, Manatee Tempest, and others support or sell ESXi encryptors like Akira, Black Basta, Babuk, Lockbit, and Kuiper (Figure 1). The number of Microsoft Incident Response (Microsoft IR) engagements that involved the targeting and impacting ESXi hypervisors have more than doubled in the last three years.
Earlier this year, an engineering firm in North America was affected by a Black Basta ransomware deployment by Storm-0506. During this attack, the threat actor used the CVE-2024-37085 vulnerability to gain elevated privileges to the ESXi hypervisors within the organization.
The threat actor gained initial access to the organization via Qakbot infection, followed by the exploitation of a Windows CLFS vulnerability (CVE-2023-28252) to elevate their privileges on affected devices. The threat actor then used Cobalt Strike and Pypykatz (a Python version of Mimikatz) to steal the credentials of two domain administrators and to move laterally to four domain controllers.
On the compromised domain controllers, the threat actor installed persistence mechanisms using custom tools and a SystemBC implant. The actor was also observed attempting to brute force Remote Desktop Protocol (RDP) connections to multiple devices as another method for lateral movement, and then again installing Cobalt Strike and SystemBC. The threat actor then tried to tamper with Microsoft Defender Antivirus using various tools to avoid detection.
Microsoft observed that the threat actor created the “ESX Admins” group in the domain and added a new user account to it, following these actions, Microsoft observed that this attack resulted in encrypting of the ESXi file system and losing functionality of the hosted virtual machines on the ESXi hypervisor. The actor was also observed to use PsExec to encrypt devices that are not hosted on the ESXi hypervisor. Microsoft Defender Antivirus and automatic attack disruption in Microsoft Defender for Endpoint were able to stop these encryption attempts in devices that had the unified agent for Defender for Endpoint installed.
Microsoft recommends organizations that use domain-joined ESXi hypervisors to apply the security update released by VMware to address CVE-2024-37085. The following guidelines will also help organizations protect their network from attacks:
Microsoft Defender for Endpoint
The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:
The following alerts might also indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.
Microsoft Defender for Identity
The following Microsoft Defender for Identity alerts can indicate associated threat activity:
Microsoft customers can use the following reports in Microsoft Defender Threat Intelligence to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments:
Microsoft Defender XDR customers can run the following queries to find related activity in their networks
This query identifies ESXi hypervisors in the organization:
DeviceInfo | where OSDistribution =~ "ESXi" | summarize arg_max(Timestamp, *) by DeviceId
This query identifies ESX Admins group changes in the Active directory:
IdentityDirectoryEvents | where Timestamp >= ago(30d) | where AdditionalFields has ('esx admins')
The following queries are for assessing the already discovered ESXi with the Microsoft Defender Vulnerability Management information:
DeviceInfo | where OSDistribution =~ "ESXi" | summarize arg_max(Timestamp, *) by DeviceId | join kind=inner (DeviceTvmSoftwareVulnerabilities) on DeviceId DeviceInfo | where OSDistribution =~ "ESXi" | summarize arg_max(Timestamp, *) by DeviceId | join kind=inner (DeviceTvmSecureConfigurationAssessment) on DeviceId
Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.
Microsoft Sentinel also has a range of hunting queries available in Sentinel GitHub repo or as part of Sentinel solutions that customers can use to detect the activity detailed in this blog in addition to Microsoft Defender detections. These hunting queries include the following:
Qakbot:
Cobalt Strike:
Danielle Kuznets Nohi, Edan Zwick, Meitar Pinto, Charles-Edouard Bettan, Vaibhav Deshmukh
Microsoft Threat Intelligence Community
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.