CVE-2024-37085 - How a Deleted and Re-Created AD Group Can Let Attackers Bypass Authentication in VMware ESXi
Security in virtualized environments is more important than ever, and VMware ESXi is a popular choice for organizations worldwide. But sometimes, subtle misconfigurations or obscure vulnerabilities can lead to serious security issues. In this post, we’ll break down the details of CVE-2024-37085, a recently discovered authentication bypass vulnerability in VMware ESXi related to Active Directory (AD) integration.
By understanding how this bug works, you’ll be better prepared to secure your ESXi hosts and avoid falling victim to a crafty Active Directory attack.
What is CVE-2024-37085?
CVE-2024-37085 is an authentication bypass vulnerability that affects VMware ESXi hosts configured for Active Directory authentication. The loophole lets a malicious user with sufficient AD privileges (but not necessarily with ESXi access already) gain full control over a hypervisor host.
How? If the group assigned ESXi administrative privileges (typically called ESXi Admins) is deleted from AD and then re-created—deliberately or incidentally—ESXi does not notice the difference. Any user added to the new group will have administrative access to the ESXi host, even though from AD’s perspective, the original and re-created groups are different entities.
How ESXi Joins Active Directory
Most organizations use Active Directory integration for managing access to ESXi hosts. An administrator joins the ESXi system to a domain and picks a group (like ESXi Admins) whose members can be admins on the host.
For example, you might issue these PowerCLI commands
# Join ESXi to Active Directory
Add-VMHostAuthentication -User "ESXiAdmin" -Password "SuperSecret123" -Domain "corp.example.com" -JoinDomain
# Set the appropriate Admin group
Get-VMHost | Get-VMHostAccount | Set-VMHostADGroup -GroupName "ESXi Admins"
From now on, any user in the ESXi Admins group in AD can administer the host.
The Vulnerability
The vulnerability happens because of how ESXi identifies the group in AD. When the ESXi host is joined to the domain and an admin group is assigned, ESXi remembers the *name* of the group (like ESXi Admins)—not its unique Security Identifier (SID).
But in Active Directory, when you delete and re-create a group using the same name, the new one gets a different SID. Effectively, to AD these are completely different objects—even if they look the same to the user.
The bug: If the group is deleted and then re-created, and the new group is assigned the same name, ESXi continues to trust it *because it only looks at the group name, not the SID*. Anyone with enough AD rights can exploit this by:
Adding malicious accounts to this group.
ESXi will now allow those new users to authenticate as admins.
Here’s a step-by-step illustration (not actual exploitation code, but a demonstration workflow)
# 1. Remove the original group (requires AD admin rights)
Remove-ADGroup -Identity "ESXi Admins"
# 2. Re-create the group with the same name
New-ADGroup -Name "ESXi Admins" -GroupScope Global -Path "OU=Groups,DC=corp,DC=example,DC=com"
# 3. Add a malicious user as a member
Add-ADGroupMember -Identity "ESXi Admins" -Members "eviluser"
# eviluser can now log into the ESXi host using their AD credentials, with admin rights!
The ESXi server, relying on group name instead of SID, treats eviluser as a trusted admin—even though this user never had privilege on the original group.
Real-world Attack Scenario
1. An attacker with AD admin rights (e.g., an insider or a compromised Domain Admin) identifies an ESXi host using AD for management.
They add their chosen user accounts into the group.
4. The ESXi host (even if untouched, and even after reboot) allows these users full administrator access.
Potential for VM compromise: control over all guest VMs
- Persistence: access remains as long as the group with the expected name exists in AD and contains the attacker’s identity
1. Upgrade VMware ESXi
Watch for patches and advisories from VMware addressing CVE-2024-37085. Upgrading to a patched release is the best solution.
2. Use SIDs, Not Names (If Possible)
If any configuration allows referencing AD groups by SIDs instead of names, use this method (though most ESXi AD integrations do not support this by default).
3. Monitor Group Changes in AD
Set up alerts for the deletion and re-creation of privileged AD groups. You can use these sample PowerShell snippets to locate recently created critical groups:
# Find all groups created in the last 7 days
Get-ADGroup -Filter * | Where-Object { $_.whenCreated -gt (Get-Date).AddDays(-7) }
4. Restrict AD Admin Privileges
Limit who can delete or re-create critical AD groups to reduce the risk of malicious changes.
References
- VMware: Joining vSphere hosts to Active Directory
- NIST CVE-2024-37085 Entry
- VMware Security Advisories
Conclusion
CVE-2024-37085 is a classic example of a subtle chain of events leading to a serious security risk. If your ESXi hosts allow AD-based admin logins, deletion and re-creation of the admin group could open a hidden backdoor for attackers.
Timeline
Published on: 06/25/2024 15:15:12 UTC
Last modified on: 08/02/2024 03:43:50 UTC