PW-029HygieneTrusts, management planes and other systems

ESX Admins group open to accounts outside Tier Zero (CVE-2024-37085)

ESXi hosts joined to the domain make any group named ESX Admins their administrators, and accounts outside Tier Zero are in it, control it, or could create it.

Category: Hygiene
Severity: High, Medium or Low.
Typical owner: AD / identity team, with the virtualization team
Data needed: Any collection: the group, its members and who can change it, plus signs of ESXi or vCenter in the directory (computers running ESXi, objects named like vCenter). Whether a host is joined to the domain can't be seen in the directory.

MITRE ATT&CKT1078.002 T1486

Most useful toDefensive engineers Identity and access engineers Offensive operators

On this page

In plain language

An ESXi host joined to Active Directory gives full administrator rights to every member of a domain group named ESX Admins. It looks the group up by name, not by its SID (CVE-2024-37085). So whoever is in that group, can change it, or can create a group with that name, administers the hosts.

An ESXi administrator controls every virtual machine on the host. They can copy a virtual domain controller's disk and read every password hash, or encrypt all the virtual machines at once. Ransomware groups have used exactly this. The fix is to keep the group's membership to Tier Zero, or to set the hosts to use a different, protected group.

What Pathwarden flags

ESXi hosts joined to Active Directory make every member of a domain group named ESX Admins a full ESXi administrator by default. The host looks the group up by name, not by SID (CVE-2024-37085). The finding has two forms:

The group exists, and accounts and groups outside Tier Zero are members of it or can change it (add members, take ownership, change its permissions).
- High when the directory shows signs of ESXi or vCenter: a computer whose operating system is ESXi or VMware's, or objects named like ESX, vCenter, VCSA or vSphere.
- Low otherwise, for review.
The group doesn't exist, but the directory shows signs of ESXi or vCenter (Medium). Anyone who can create a group, or rename a group they control, can make a new ESX Admins group and become ESXi administrator. Without ESXi evidence, a missing group is not reported.

Pathwarden infers this from the directory only. It can't see whether a host is joined to the domain, or how its settings are.

How attackers use it

An ESXi administrator controls every virtual machine on the host: it can snapshot a virtual domain controller, copy its disk and read NTDS.dit with every password hash, or encrypt all the virtual machines at once. Ransomware operators have used this path (Microsoft Threat Intelligence, July 2024): create "ESX Admins", add themselves, and take over the hosts.

Find it with Pathwarden

Data needed: Any collection: the group, its members and who can change it, plus signs of ESXi or vCenter in the directory (computers running ESXi, objects named like vCenter). Whether a host is joined to the domain can't be seen in the directory.

In the web UI or the HTML report, open the Findings tab and expand PW-029: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell

# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-029
# the step-by-step guide on this page, offline
pathwarden guide PW-029
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-029

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

Ask the virtualization team which ESXi hosts are joined to the domain, and which group they grant administration to (the advanced settings Config.HostAgent.plugins.hostsvc.esxAdminsGroup and Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd on each host).
Check the members of the group. Someone in it may need ESXi access for their work; give them that access through a group only Tier Zero admins control.

How to fix it

Option A: Turn the automatic grant off (recommended)

Update the ESXi hosts. ESXi 8.0 Update 3 turns the automatic grant off by default.
On older hosts, set Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd to false (vSphere Client: Host > Configure > System > Advanced System Settings), and set esxAdminsGroup to a group only Tier Zero admins control.
Remove the ESX Admins permission from each host if it was already granted (Host > Permissions).

Option B: Keep the group, locked down

Remove the members outside Tier Zero from ESX Admins.
Remove the rights others hold on it, so that only Tier Zero admins can change it.
If the group was missing, create it, empty, with the same protection.

Option C: No ESXi host uses it

Accept the finding as a risk with the reason, so the review is recorded.

PowerShell

Import-Module ActiveDirectory

# The group, its members and who can change it
$g = Get-ADGroup -Filter "Name -eq 'ESX Admins'" -Properties nTSecurityDescriptor
if ($g) {
    Get-ADGroupMember $g -Recursive | Select-Object Name, ObjectClass
    $g.nTSecurityDescriptor.Access |
        Where-Object { $_.ActiveDirectoryRights -match 'GenericAll|WriteProperty|WriteDacl|WriteOwner' } |
        Select-Object IdentityReference, ActiveDirectoryRights, IsInherited
} else { 'No ESX Admins group' }

# On each ESXi host (PowerCLI): the settings
# Get-VMHost | Get-AdvancedSetting -Name 'Config.HostAgent.plugins.hostsvc.esxAdmins*'

Verify the fix

Collect again (or use Retest on the finding). The finding is gone when nobody outside Tier Zero is in the group or can change it, and when the group exists wherever the directory shows ESXi.

Roll back

Put the members back, or restore the rights on the group. To undo Option A, set esxAdminsGroupAutoAdd back to true on the hosts.

References

https://www.microsoft.com/en-us/security/blog/2024/07/29/ransomware-operators-exploit-esxi-hypervisor-vulnerability-for-mass-encryption/microsoft.com
Broadcom VMSA-2024-0013: VMware ESXi updates, including CVE-2024-37085 (ESX Admins)support.broadcom.com
Microsoft: Enterprise access modellearn.microsoft.com
MITRE ATT&CK T1078.002: Valid Accounts: Domain Accountsattack.mitre.org
MITRE ATT&CK T1486: Data Encrypted for Impactattack.mitre.org