ESXi handed out admin to a group named 'ESX Admins' and never checked who made it

The design decision behind CVE-2024-37085 is the kind you’d flag in a code review and assume someone would never ship. When a VMware ESXi host is joined to Active Directory, it grants full administrative rights to any member of a domain group named “ESX Admins.” It identifies that group by name. It does not verify that the group was created by an administrator, that it’s the group the org intended, or that it should exist at all. The host just trusts the string.

So if the “ESX Admins” group doesn’t already exist in the domain, as Microsoft’s threat intelligence team documented, any domain user with permission to create a group, a permission that’s far more common than it should be, creates one called “ESX Admins,” adds themselves, and becomes a full administrator on every domain-joined ESXi host in the environment. Alternatively, rename an existing group you control to “ESX Admins.” That’s the whole exploit. There’s no memory corruption, no payload, no race. It’s a logic flaw in how the hypervisor decides who’s in charge.

Why this one is a crisis, not a finding

ESXi is the box ransomware crews most want. A hypervisor doesn’t run one workload; it runs all of them. Encrypt the ESXi host’s datastore and you’ve encrypted every virtual machine on it simultaneously, which is why ransomware operators maintain dedicated Linux ESXi-targeting variants. CVE-2024-37085 is a clean path from “a foothold in the domain” to “administrative control of the hypervisor layer,” and that’s exactly the pivot these crews are built around.

The exploitation wasn’t theoretical or limited. Microsoft observed it used by multiple named groups, including Storm-0506, Storm-1175, Octo Tempest, and Manatee Tempest, deploying Linux variants of Akira, Black Basta, Babuk, and LockBit to encrypt ESXi-hosted VMs. CISA added it to the Known Exploited Vulnerabilities catalog on July 30, 2024, with an August 20 deadline and the ransomware flag set. The NVD scores it 7.2; VMware scores it 6.8. Both numbers are reasonable for the mechanics and both undersell the operational reality, because the asset at risk is the layer everything else runs on.

The PR:H in the CVSS vector, privileges required is high, is doing the same misleading work it does in a lot of these entries. On paper it means the attacker needs Active Directory permissions. In practice the permission required is “can create a group” or “can manage some existing group,” which in a large, old, loosely-governed AD is not a high bar at all. The bug effectively converts a low-value domain account into hypervisor admin, and most domain compromises start with exactly that kind of account.

The part that should bother you most

VMware fixed CVE-2024-37085 in ESXi 8.0 Update 3, released June 25, 2024, per VMware’s advisory VMSA-2024-0013. ESXi 7.0 did not get a fix, and none is planned.

That matters because ESXi 7.0 is everywhere. Plenty of production virtualization estates are still on the 7.x line, often because the hardware compatibility list or the upgrade path to 8.0 is a project nobody has scheduled. For those hosts, a KEV-listed, ransomware-associated, actively-exploited auth bypass has no vendor patch. The required action becomes mitigation and configuration, not “install the update,” and the clock CISA put on it still runs.

What to do

• Patch what you can. Get domain-joined ESXi 8.0 hosts to Update 3 or later. That’s the real fix and it should be prioritized like the perimeter exposure it functionally is.
• For ESXi 7.0 and anything you can’t immediately patch, change the admin group away from the default. VMware’s guidance is to not rely on the default “ESX Admins” name. Configure the host’s admin group to a specific, managed AD group, and make sure that group genuinely exists and is tightly controlled, so an attacker can’t conjure the privileged group out of thin air.
• Question whether ESXi needs AD integration at all. The entire vulnerability lives in the AD-join feature. Hosts that authenticate locally or through vCenter rather than direct AD membership aren’t exposed to this specific bypass. If AD integration on the hypervisors isn’t earning its keep, removing it removes the attack surface.
• Lock down who can create and rename AD groups. This bug, and a surprising number of others, depend on ordinary accounts being able to create groups. Audit that permission. It’s broader than most orgs realize.
• Monitor for the group itself. Alert on creation of, or membership changes to, any group named “ESX Admins,” and on renames that produce that name. Splunk and others published detections for exactly this pattern. A new “ESX Admins” group appearing in your domain is either your VMware admin or your incident.
• Treat the hypervisor as crown-jewel infrastructure in your segmentation. The management network for ESXi and vCenter should be isolated from general user access. The fewer accounts that can even reach the hosts, the less an AD-level trick like this buys an attacker.

The reframe is uncomfortable but worth saying. This wasn’t an exotic vulnerability; it was a trust assumption that should never have shipped, in the layer that holds your entire virtual estate, and the older version of the product that many shops still run is simply not getting fixed. When the vendor’s answer for a live, ransomware-exploited bug is “upgrade to the version we still support,” the upgrade you’ve been deferring just became a security control with a deadline. We track the KEV entries that hit virtualization and management infrastructure first, because those are the hosts that turn one compromised account into every system you run going dark at once.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NVD CVE-2024-37085 — 2024-06-25
• Microsoft: Ransomware operators exploit ESXi hypervisor vulnerability for mass encryption — 2024-07-29
• VMware/Broadcom VMSA-2024-0013 — 2024-06-25
• Rapid7: VMware ESXi CVE-2024-37085 targeted in ransomware campaigns — 2024-07-30
• Help Net Security: VMware ESXi auth bypass zero-day exploited by ransomware operators — 2024-07-30