CVE-2024-37085 Explained: VMware ESXi Active Directory Authentication Bypass
An authentication bypass in VMware ESXi that exploits Active Directory group naming conventions to grant full hypervisor administrative access to any AD group member. Exploited by at least five ransomware groups — including Black Basta, Akira, and Medusa — to encrypt virtual machine storage directly at the hypervisor layer.
CVE-2024-37085 is an authentication bypass in VMware ESXi affecting deployments integrated with Active Directory for authentication. The vulnerability stems from ESXi's automatic trust of an Active Directory group named 'ESX Admins': any domain user who is a member of a group with this exact name receives full hypervisor administrative privileges — regardless of whether the group was explicitly added to ESXi's administrator configuration, recently created by an attacker, or even if the group was deleted and recreated.
VMware (Broadcom) disclosed the vulnerability on June 25, 2024. Microsoft subsequently documented active exploitation by at least five ransomware groups: Black Basta, Akira, Medusa, RansomHub, and Scattered Spider. The attack pattern — compromise an Active Directory account, create or join an 'ESX Admins' group, gain full ESXi access, encrypt all VM storage — enables mass disruption across virtualised environments at a scale that individual endpoint ransomware cannot achieve.
How the ESX Admins Group Bypass Works
VMware ESXi supports Active Directory integration for authentication, allowing domain users and groups to be granted ESXi administrative roles. In the ESXi AD integration, there is a hardcoded privileged group name: 'ESX Admins.' ESXi treats any domain group with this exact name as having full administrative access to the hypervisor — this is a default behavior that predates explicit group configuration in the vCenter admin UI.
The vulnerability is that ESXi does not validate that the 'ESX Admins' group was explicitly added by an administrator. If any domain user or attacker creates an AD group named 'ESX Admins' (in any domain OU), all members of that group automatically receive full ESXi administrator access the next time ESXi refreshes its AD group membership cache.
This means an attacker who has gained any form of domain user account with sufficient AD privileges to create a new security group can escalate directly to ESXi hypervisor administrator — bypassing all ESXi-specific access controls. The attack requires no ESXi credentials, no vulnerability in ESXi's code execution path, and no network exploitation — it abuses a trust relationship between ESXi and Active Directory.
Gain domain user credentials with group creation privileges
Obtain credentials for an Active Directory account with permission to create security groups (typically any domain user in environments with default AD permissions, or via a compromised service account). This is achieved via phishing, credential stuffing, or lateral movement from an initial foothold.
Create 'ESX Admins' group in Active Directory
Create a new AD security group named exactly 'ESX Admins' in any organisational unit in the domain. Add the compromised user (or any attacker-controlled account) as a member of this group.
Wait for ESXi AD group membership refresh
ESXi refreshes its AD group membership cache periodically. Within the refresh interval, the 'ESX Admins' group membership is reflected and the attacker account receives full administrative privileges on all ESXi hosts in the domain.
Authenticate to ESXi as full administrator
Log in to the ESXi management interface (vSphere Client or direct ESXi web UI) using the compromised domain account. The attacker now has full hypervisor administrative access — equivalent to the root account on the ESXi host.
Encrypt VM datastores directly at the hypervisor layer
Use ESXi management APIs to power off running VMs and encrypt the VMDK files on the datastore directly. Because the encryption occurs at the hypervisor storage layer, guest VM security software does not observe or block the encryption. All VMs on the host become inaccessible simultaneously.
Ransomware Groups and the Hypervisor Targeting Strategy
Microsoft documented five distinct ransomware groups exploiting CVE-2024-37085 after the advisory. The common operational objective was the same: encrypt virtualised infrastructure at the hypervisor layer to achieve maximum disruption with minimum per-system effort.
Encrypting VM storage directly via ESXi admin access eliminates the need to deploy ransomware to individual guest VMs. Instead of running ransomware on 100 Windows VMs, an attacker with ESXi admin access encrypts 100 VMs simultaneously via a handful of storage commands on the hypervisor. The guest VMs — including their security software — never observe the attack. Recovery requires restoring VMs from backup, which is significantly more complex and time-consuming than recovering individual encrypted files.
Black Basta operators specifically used the group renaming technique: renaming an existing AD group to 'ESX Admins' rather than creating a new one, which avoids triggering alerts on new group creation. Akira and Medusa used the direct group creation approach. Scattered Spider used existing 'ESX Admins' group membership identified during their AD reconnaissance.
“Multiple ransomware operators are exploiting CVE-2024-37085 to gain full administrative access to ESXi hypervisors following domain compromise. The ability to encrypt dozens or hundreds of VMs simultaneously via hypervisor-layer storage commands represents a significant operational capability.”
— Microsoft Threat Intelligence, July 2024
Patching and Hardening Against CVE-2024-37085
The patch changes how ESXi handles the 'ESX Admins' group trust. Configuration hardening is also required to prevent exploitation via the remaining attack surface.
Upgrade ESXi to patched versions
Apply VMware ESXi 8.0 Update 3 or later, ESXi 7.0 Update 3q or later, or the VMware Cloud Foundation patches specified in VMSA-2024-0013. After patching, the automatic 'ESX Admins' group trust is removed — the group must be explicitly configured in ESXi settings to grant admin access.
Audit Active Directory for 'ESX Admins' group
Search your Active Directory for any group named 'ESX Admins' in any OU. If you did not intentionally create this group for ESXi management, its existence is an IOC. Identify its members and audit them for compromise. If the group was created by an attacker, escalation to ESXi admin may have already occurred.
Review ESXi host AD group assignments in vCenter
In vCenter > Hosts > Permissions, verify that only expected AD groups and users have administrative roles. Remove any unrecognised entries. After applying the patch, re-configure your intended ESXi admin group explicitly if you use AD integration for ESXi administration.
Consider disabling AD integration for ESXi
If Active Directory integration for ESXi authentication is not operationally required, disable it and manage ESXi hosts via local accounts with strong, unique credentials stored in a privileged access management (PAM) system. Removing the AD trust eliminates this entire attack class.
Harden ESXi management access
Restrict the ESXi management interface (port 443, vSphere Client) to only management network IP ranges. Enable ESXi Lockdown Mode where feasible to restrict which accounts can manage hosts directly. Monitor for unexpected ESXi authentication events from non-management workstations.
The bottom line
CVE-2024-37085 demonstrates that virtualisation infrastructure carries the same threat model as domain controllers and identity infrastructure — not the same as individual endpoints. An attacker with ESXi admin access does not need to touch individual VMs to destroy them. The hypervisor is the reality that all VMs share, and controlling it means controlling all of them simultaneously.
The CVSS 6.8 score is one of the more egregious underrepresentations of real-world risk in recent years. The vulnerability was exploited by five distinct ransomware groups for good reason — it converts partial domain compromise into total virtualisation infrastructure compromise with a few AD commands. Patch ESXi, audit your AD for 'ESX Admins' groups, and treat hypervisor administrative access as the crown jewel privilege it is.
Frequently asked questions
What is CVE-2024-37085?
CVE-2024-37085 is an authentication bypass in VMware ESXi. When ESXi is configured to use Active Directory for authentication, it automatically grants full administrative access to members of an AD group named 'ESX Admins' — even if that group was not explicitly configured in ESXi's admin settings, was recently created, or was deleted and recreated. An attacker who can create an AD group with this name and add users to it gains full ESXi hypervisor administrative access.
Why is the CVSS score 6.8 when ransomware groups are actively exploiting it?
The CVSS 6.8 score reflects that exploitation requires pre-existing domain user privileges (low privilege in AD) and an Active Directory-integrated ESXi environment — conditions that reduce the base score from the maximum. However, the CVSS score substantially underestimates real-world risk: full hypervisor administrative access across all VMs on a host, exploited by multiple ransomware groups, represents a devastating impact regardless of the score.
Which VMware ESXi versions are affected?
VMware ESXi 8.0 (prior to 8.0 Update 3), VMware ESXi 7.0 (prior to 7.0 Update 3q), and VMware Cloud Foundation 4.x and 5.x are affected when configured with Active Directory integration. The vulnerability only affects ESXi hosts joined to an Active Directory domain.
How were ransomware groups using CVE-2024-37085?
Microsoft documented ransomware operators using CVE-2024-37085 in three ways: (1) creating an 'ESX Admins' group in AD and adding their compromised user to it, (2) renaming an existing AD group to 'ESX Admins', or (3) leveraging an existing 'ESX Admins' group. After gaining ESXi admin access, they used ESXi storage commands to encrypt VM disk files (.vmdk) directly on the datastore, achieving mass VM outage without installing ransomware on individual guest VMs.
How do I fix CVE-2024-37085?
Upgrade ESXi to 8.0 Update 3+ or 7.0 Update 3q+. Additionally: (1) Verify that no AD group named 'ESX Admins' exists in your domain unless you intentionally created and secured it, (2) review ESXi host AD group assignments in vCenter, (3) consider disabling AD integration for ESXi if it is not required and use local admin accounts with strong credentials instead.
Sources & references
- NVD
- Broadcom VMware Security Advisory VMSA-2024-0013
- Microsoft Threat Intelligence — Ransomware operators exploit ESXi hypervisor vulnerability CVE-2024-37085
- CISA Known Exploited Vulnerabilities Catalog
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.