## https://sploitus.com/exploit?id=9D028B99-E871-5E38-828C-41A8B82DBA9B
# CVE-2024-37085
CVE-2024-37085 VMware ESXi RCE Vulnerability
## CVE description
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.
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).
We have identified three methods for exploiting this vulnerability and created the PoC based around this:
- Adding the âESX Adminsâ group to the domain and adding a user to it â This method is actively exploited in the wild by the abovementioned threat actors. In this method, if the âESX Adminsâ group doesnât exist, any domain user with the ability to create a group can escalate privileges to full administrative access to domain-joined ESXi hypervisors by creating such a group, and then adding themselves, or other users in their control, to the group.
- Renaming any group in the domain to âESX Adminsâ and adding a user to the group or use an existing group member â This method is similar to the first, but in this case the threat actor needs a user that has the capability to rename some arbitrary groups and rename one of them to âESX Adminsâ. The threat actor can then add a user or use a user that already exists in the group, to escalate privileges to full administrative access. This method was not observed in the wild by Microsoft.
- ESXi hypervisor privileges refresh â Even if the network administrator assigns any other group in the domain to be the management group for the ESXi hypervisor, the full administrative privileges to members of the âESX Adminsâ group are not immediately removed and threat actors still could abuse it. This method was not observed in the wild by Microsoft.
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.
## Who is vulnerable?
Over 1.2 million services:
Hunter:/product.name="VMWare ESXi"
Shodan: product:"VMware ESXi"
Fofa: app="vmware-ESXi"
## CVE-2024-37085 download exploit
As mentioned at the beginning, CVE-2024-37085 was given such a high CVSS score because it is remote code execution. This means it can go unnoticed by the user and potentially by the security team as well. Such a powerfull tool should not be fully public, there is strictly only a few copies available so a REAL researcher can use it: https:// shorturl[.]at/wzXB0
This should attract attention to importance of cyber security, it can be tempting to ignore, or palm it off to the IT team. But both of these options can leave you susceptible to real and damaging risks. Do NOT resell or leak this PoC or you can be at risk of breaking the law.
## Patching
There are currently no updates that can guarantee this exploit doesn't function.
## Detection
- Validate the group âESX Adminsâ exists in the domain and is hardened.
- Manually deny access by this group by changing settings in the ESXi hypervisor itself. If full admin access for the Active Directory ESX admins group is not desired, you can disable this behavior using the advanced host setting: âConfig.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAddâ.
- Change the admin group to a different group in the ESXi hypervisor.
- Add custom detections in XDR/SIEM for the new group name.
- Configure sending ESXi logs to a SIEM system and monitor suspicious full administrative access.
## Mitigation
- Credential hygiene
- Install software updates
- Improve critical assets posture
- Identify vulnerable assets
## Disclamer
This project is intended for educational purposes only and cannot be used for law violation or personal gain.
The authors of this project is not responsible for any damages caused by direct or indirect use of the information or functionality provided by those script.