CVE-2024-37085

What it actually does

VMware ESXi can incorrectly grant full administrative access to an ESXi host joined to Active Directory when an attacker with sufficient Active Directory permissions recreates or controls the configured ESXi administrator group, commonly named "ESX Admins" by default. The flaw is an authentication/authorization bypass in the ESXi Active Directory integration path: possession of the matching AD group can be treated as host-level administrator authority, allowing complete control of the hypervisor, including virtual machine operations, datastore access, host configuration changes, account changes, and service enablement such as SSH or shell access.

Why it matters to the business

Successful exploitation gives an attacker administrative control of virtualization hosts, which can rapidly affect many critical servers at once. Because this vulnerability is listed in CISA KEV, has observed in-the-wild exploitation, and is associated with ransomware activity targeting vSphere/ESXi environments, it should be treated as urgent even though the attacker needs elevated Active Directory permissions first. Business consequences can include mass virtual machine shutdown, encryption or deletion of VM files, backup disruption, prolonged outage of core applications, and broad incident response across identity, virtualization, backup, and recovery teams. CISA’s KEV remediation due date was 2024-08-20, so any remaining exposure is materially overdue.

How an attack unfolds

An attacker first obtains an Active Directory account with enough privilege to create or manipulate groups in the domain or organizational unit used by ESXi for authentication. They identify ESXi hosts that are joined to Active Directory and determine the configured administrator group name, often the default "ESX Admins". If the group was deleted or does not currently exist, the attacker recreates it; if they can control it, they add their account or a controlled account to the group. Due to the vulnerable ESXi behavior, the host may grant that group full administrator rights. The attacker then authenticates directly to the ESXi host through the host client, API, SSH if enabled, or other management interfaces and gains full host control. In ransomware-driven intrusions, that access is commonly used to disable defenses, stop or power off VMs, tamper with snapshots and backups, access datastores, and encrypt or destroy virtual machine files to maximize operational disruption.

How to fix it

Apply the latest VMware/Broadcom security updates for all affected ESXi and VMware Cloud Foundation deployments according to the vendor advisory for CVE-2024-37085. Where exact fixed versions are not centrally tracked, validate directly against the current Broadcom VMware security advisory and upgrade to a non-vulnerable supported build. As an immediate mitigation, audit ESXi Active Directory integration and remove reliance on the default "ESX Admins" behavior. Restrict or disable AD-based ESXi host authentication where not required, explicitly configure least-privilege host permissions, and ensure no unintended AD group with the configured ESXi admin name exists. Remove unauthorized members from the configured ESXi admin group, protect the group from deletion/recreation abuse, and limit who can create groups or modify memberships in the relevant AD scope. Restrict direct ESXi management access to dedicated administrative networks, enforce MFA where supported through management workflows, and monitor for direct host logins instead of vCenter-mediated access. Confirm backups are offline or immutable and that ESXi recovery procedures are tested.

How to confirm the fix worked

Confirm each ESXi host and VMware Cloud Foundation component is running a vendor-supported fixed build or later. Review host identity settings to determine whether the host is joined to Active Directory and which AD group is configured for administrative access. Verify that the configured admin group exists only where intended, has tightly controlled ownership, has no unauthorized members, and cannot be recreated or modified by non-administrative users. Attempt validation from a controlled test account that is not explicitly authorized for ESXi administration; it should not receive host administrator privileges simply because of group recreation or default group naming behavior. Check that direct ESXi management interfaces are restricted to approved networks and that SSH/shell are disabled unless explicitly required. Review vCenter and ESXi permission views to ensure host-level Administrator assignments are intentional and documented.

Typical attack path

1. Compromise or obtain an Active Directory account with rights to create, recreate, or modify the ESXi administrator group.
2. Identify ESXi hosts joined to Active Directory and determine the configured admin group name, commonly "ESX Admins".
3. Create or recreate the configured AD group, or modify its membership if it already exists.
4. Add the attacker-controlled user account to that group.
5. Authenticate to the ESXi host using AD credentials through the ESXi Host Client, API, SSH, or another management path.
6. Use the granted administrator privileges to change host settings, enable remote access, browse datastores, manage VMs, and create persistence.
7. For ransomware operations, shut down VMs, delete or tamper with snapshots/backups, and encrypt VM files or datastores.

How to detect it

Investigate both Active Directory and VMware management telemetry. In Active Directory security logs, look for creation, deletion, recreation, ownership changes, and membership changes involving the configured ESXi administrator group, especially the default "ESX Admins". Relevant Windows security events include group creation, group deletion, member added, member removed, and group changed events for global, local, or universal security groups. Correlate those events with ESXi/vCenter login events from the same accounts, especially direct logins to ESXi hosts rather than normal vCenter workflows. Review ESXi host logs such as hostd.log, auth.log, shell.log, syslog.log, and vobd.log for successful AD logins, SSH/shell enablement, permission changes, and administrative activity. Review vCenter events and tasks for unusual host configuration changes, VM power operations, snapshot removals, datastore browsing, file deletion, and account or permission changes. For ransomware-related activity, look for bursts of VM shutdowns, snapshot deletion, backup job disruption, encryption-like high-volume datastore writes, unexpected file extensions on VM-related files, and management activity outside normal administrative windows. If threat hunting finds the ESXi admin group was created or modified shortly before direct ESXi logins or destructive VM operations, treat it as probable exploitation and preserve AD, vCenter, ESXi, and backup-system logs for incident response.

• ESX Admins
• Event ID 4727
• Event ID 4728
• Event ID 4729
• Event ID 4730
• Event ID 4731
• Event ID 4732
• Event ID 4733
• Event ID 4734
• Event ID 4735
• Event ID 4754
• Event ID 4755
• Event ID 4756
• Event ID 4757
• Event ID 4758
• /var/log/hostd.log
• /var/log/auth.log
• /var/log/shell.log
• /var/log/syslog.log
• /var/log/vobd.log
• UserLoginSessionEvent
• vim.event.UserLoginSessionEvent
• vim.event.VmPoweredOffEvent
• vim.event.TaskEvent
• SSH for the host has been enabled
• Shell for the host has been enabled
• esxcli system account
• vim-cmd vmsvc/power.off
• vim-cmd vmsvc/getallvms

What your security team should do

• Treat as a high-priority incident-prevention item because it is in CISA KEV, actively exploited in the wild, and associated with ransomware targeting ESXi/vSphere environments.
• Immediately inventory ESXi hosts joined to Active Directory and identify any configured admin group, especially groups named "ESX Admins".
• Patch or upgrade all affected ESXi and VMware Cloud Foundation deployments to vendor-fixed supported builds.
• Audit Active Directory for creation, deletion, recreation, ownership changes, and membership changes involving the configured ESXi admin group.
• Remove unauthorized users from ESXi-related AD groups and restrict who can create groups or modify membership in the relevant AD scopes.
• Limit direct ESXi host management access to hardened administrative networks and monitor all direct host logins.
• Disable ESXi SSH and shell access unless operationally required, and alert when they are enabled.
• Review recent VM power-off events, datastore file changes, snapshot deletion, backup failures, and host configuration changes for signs of ransomware staging.
• Validate that backups for virtualized workloads are offline, immutable, and restorable before relying on them for recovery.
• If suspicious AD group manipulation or unexpected ESXi administrator login is found, initiate incident response across both Active Directory and virtualization infrastructure.