DarkGate malware account creation

Threat snapshot

VMware ESXi is the hypervisor layer that underpins virtualised infrastructure in a large proportion of enterprise data centres. An attacker who gains administrative access to an ESXi host has control over every virtual machine running on it: they can power VMs off and on, snapshot and clone them, modify their configurations, attach storage, and directly access the files that make up the virtual disks. This level of access converts a single hypervisor compromise into potential access to every workload, every database, and every service running on that host.

CVE-2024-37085 is an authentication bypass vulnerability in VMware ESXi that exploits the way ESXi handles the Active Directory group named ESX Admins. When an ESXi host is joined to an Active Directory domain and the ESX Admins group is deleted from Active Directory, ESXi continues to grant full administrative access to any user who is a member of any group subsequently named ESX Admins in Active Directory, even if that group was created by an unprivileged user. An attacker with standard Active Directory user rights can create a group called ESX Admins, add themselves to it, and inherit full ESXi administrator privileges without any ESXi credentials. Log360 detects this exploitation technique through the Potential Exploitation of CVE-2024-37085 rule, which fires when the ESX Admins group is created in Active Directory.

At a glance

How this attack works

CVE-2024-37085 exploits a specific behaviour in how VMware ESXi integrates with Active Directory for administrative access. When ESXi is configured to use Active Directory for authentication, it grants full administrative access to members of the domain group named ESX Admins. This integration is by design and is a supported configuration for managing ESXi access through Active Directory group membership.

The vulnerability arises from ESXi's handling of the case where the ESX Admins group does not exist in Active Directory. In this scenario, ESXi does not disable the feature or fall back to a local authentication mode. Instead, it continues to check for the group at authentication time. If any Active Directory group named ESX Admins is created or re-created, ESXi immediately begins granting full administrative access to its members, treating the newly created group as the legitimate ESX Admins group regardless of who created it.

An attacker who has standard Active Directory user rights can exploit this behaviour by taking the following steps: first, verify or ensure that no ESX Admins group currently exists in the target Active Directory domain; second, create a new Active Directory group named exactly ESX Admins; third, add their own account or a controlled account to this group; fourth, authenticate to the ESXi host using that account, which will now be granted full ESXi administrator privileges.

The attack requires only the Active Directory permissions needed to create a group and add members to it, which are standard permissions available to most domain users by default in many Active Directory configurations. No ESXi credentials, no network access to the ESXi management interface during the setup phase, and no vulnerability in ESXi itself beyond the flawed group validation logic are required. The vulnerability was disclosed in July 2024 and was exploited by ransomware operators including Black Basta and Storm-0506 in observed campaigns within weeks of disclosure.

The ransomware operator connection

CVE-2024-37085 was documented in active exploitation by ransomware operators specifically because ESXi access provides the most efficient path to encrypting an organisation's entire virtualised infrastructure in a single operation. An attacker who can power off and snapshot all VMs on an ESXi host, then encrypt the VMDK files that make up those virtual machines, can render an organisation's entire data centre unavailable simultaneously. This is why ESXi-targeting ransomware has become a priority attack vector and why the group creation signal detected by this rule warrants immediate escalation.

Attack chain

The table below maps each stage of a CVE-2024-37085 exploitation attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A financial services organisation runs its core transaction processing and reporting systems on VMware ESXi hosts joined to its corporate Active Directory domain. The ESXi hosts are configured for AD-based authentication, and the ESX Admins group was created during the initial ESXi deployment but has since been deleted as part of a group cleanup operation that removed unused security groups from Active Directory.

A threat actor who gained access to the corporate network through a phishing campaign targeting helpdesk staff has been operating under a compromised helpdesk account for five days. Researching the organisation's infrastructure, the attacker identifies that the ESXi hosts are domain-joined and that no ESX Admins group currently exists in Active Directory. Using the compromised helpdesk account, which has the default Active Directory permission to create groups in certain OUs, the attacker creates a new security group named ESX Admins in Active Directory and adds the helpdesk account to it.

Log360 fires the CVE-2024-37085 group creation alert within 90 seconds of the group being created. The SOC analyst reviews the alert, recognises the ESX Admins group name in the context of the CVE, and immediately escalates. Before the incident response team can disable the group or the ESXi authentication integration, the attacker has already authenticated to the primary ESXi host and begun powering off virtual machines. The incident response team isolates the ESXi management network, disables the compromised account, and removes the ESX Admins group from Active Directory. Three of the organisation's eleven VMs were powered off before the attack was contained. No VMDK encryption occurred because the ransomware deployment had not yet been initiated.

Why this happens

The ESX Admins group deletion, which creates the vulnerable condition, is not inherently suspicious. Groups are deleted as part of routine AD hygiene all the time. An organisation that cleaned up unused groups months ago has no way to know that this created a vulnerability in their ESXi authentication configuration without specifically auditing the ESXi AD integration settings. The attack is also fast: from group creation to ESXi access, the exploitation can complete in under two minutes. The group creation event is the only Active Directory signal that precedes the compromise.

Business impact: What can go wrong

Successful exploitation of CVE-2024-37085 converts a standard domain user credential into full hypervisor administrative access, with the following potential consequences:

• Mass VM encryption: an attacker with ESXi administrative access can power off all virtual machines on a host and directly encrypt the VMDK files that make up those VMs. A single ESXi host can host dozens of virtual machines. Encrypting the VMDKs of all hosted VMs simultaneously is the most efficient path to a large-scale ransomware impact, requiring no access to the guest operating systems individually.
• Complete data centre disruption: powering off all VMs on an ESXi host immediately disrupts every service running on those VMs, including databases, application servers, email systems, and any other workload hosted on that infrastructure. The disruption is simultaneous and immediate, with no per-VM warning.
• VM snapshot exfiltration: ESXi administrative access allows the creation and export of VM snapshots. A snapshot of a running VM contains the full memory state and disk contents of that VM at the time of capture, including any data in memory and all stored files. Exfiltrating snapshots provides the attacker with complete copies of every hosted workload.
• Persistent hypervisor backdoor: an attacker with ESXi administrative access can modify VM configurations, deploy additional VMs, install ESXi plugins, or modify the hypervisor configuration to maintain persistent access that survives guest OS remediation. Malicious VMs or hypervisor-level implants are extremely difficult to detect from within the guest OS.
• Trust boundary violation: ESXi hosts that run multiple tenant workloads or multiple sensitive systems on the same physical host expose all co-hosted workloads to a single point of compromise. An attacker with ESXi access can access the disks of every VM regardless of the guest OS security controls on each individual VM.
• Regulatory consequence: for organisations subject to PCI DSS, HIPAA, or GDPR, a confirmed ESXi compromise affecting VMs hosting regulated data triggers breach notification obligations. The scope of a hypervisor-level compromise, covering all VMs on the affected host, significantly expands the notification and remediation requirements.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the CVE-2024-37085 detection rule can fire reliably, ensure the following are in place:

• Windows Account Management auditing is enabled on all domain controllers, generating Event ID 4727 and Event ID 4731 for security group creation events. The rule fires on the group creation event, which is logged on the domain controller that processes the group creation request. All domain controllers must have Account Management auditing enabled to ensure the event is captured regardless of which DC processes the request.
• Domain controller logs are forwarded to Log360 in near-real-time via the Log360 agent or Windows Event Forwarding. Group creation events must reach Log360 promptly because the window between group creation and ESXi authentication can be under two minutes. Any significant log forwarding delay reduces the time available for the SOC to respond before the attacker authenticates to ESXi.
• ESXi syslog forwarding is configured to send authentication and management API logs to Log360 or to a syslog server ingested by Log360. ESXi does not generate Windows Security events. Visibility into post-authentication ESXi activity requires ESXi-native logging forwarded via syslog.
• The ESXi hosts in scope are confirmed as domain-joined and known to Log360 as monitored log sources. If ESXi syslog is not forwarded to Log360, the rule will still fire on the Active Directory group creation event, but post-authentication ESXi activity will not be visible in the same investigation interface.

Note: The Log360 rule detects the ESX Admins group creation in Active Directory, which is the precursor event to the exploitation. Detection at this stage provides a window to prevent the attacker from completing the exploitation before they authenticate to ESXi. Even if ESXi syslog is not configured, the group creation alert alone is sufficient to initiate an investigation. However, configuring ESXi syslog forwarding to Log360 is strongly recommended to provide full visibility into whether exploitation has already progressed to ESXi authentication before the alert is acted on.

Detecting VMware ESXi privilege escalation using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: Potential Exploitation of CVE-2024-37085 - Suspicious Creation Of ESX Admins Group. Configure an alert profile for the same. Set the severity to Critical and configure immediate SOC queue notification. Creation of a group named ESX Admins in Active Directory is an extremely rare event in most environments and any alert from this rule should be treated as a potential CVE-2024-37085 exploitation attempt until confirmed otherwise.

Step 2: Tune the rule for your environment

After enabling the rule, review the following:

• Determine whether your ESXi hosts are domain-joined. The rule is specifically relevant to environments where ESXi hosts are joined to Active Directory. If your ESXi hosts do not use Active Directory authentication, the rule will still detect the group creation event but the exploitation path is not available. Document whether your ESXi hosts are domain-joined and include this in the alert triage procedure.
• Check the current state of the ESX Admins group in your Active Directory. Before enabling the rule, verify whether an ESX Admins group already exists in your domain. If it does, the vulnerability condition is not present and the rule will fire only if a second group of the same name is somehow created, which is blocked by Active Directory uniqueness constraints. If the group does not exist, your environment is vulnerable to this technique and the rule is actively protective.
• Identify the IAM accounts and OU paths that are authorised to create security groups in your Active Directory. If your environment legitimately creates ESX Admins groups as part of new ESXi deployments, document the specific account and OU responsible for that creation. Create a scoped exclusion covering that exact account and OU combination.

Step 3: Read the alert

When the rule fires, the alert will display the name of the group created (which will be ESX Admins or a close variant), the account that created the group, the domain controller that processed the request, the OU where the group was created, and the timestamp. Review the creating account immediately. An account that is not a documented ESXi administrator or IT infrastructure team member requires immediate escalation. Then check whether the group has already had members added to it, which indicates the exploitation preparation is already underway.

Investigating an alert

When the Potential Exploitation of CVE-2024-37085 rule fires, an L2 analyst should work through the following steps:

• Identify the creating account and verify authorisation immediately. Determine whether the account that created the ESX Admins group is a documented ESXi administrator or an IT infrastructure team member with a documented reason to create this group. Contact the account owner directly. If the account owner cannot confirm they created the group, or if the account is a standard user or helpdesk account with no ESXi administration role, treat this as confirmed exploitation and initiate containment before completing the remaining investigation steps.
• Check whether the group has members. Query Log360 for Event ID 4728 or 4732 showing accounts being added to the ESX Admins group in the minutes following the group creation alert. If members have already been added, identify those accounts. The member accounts are the ones the attacker intends to use for ESXi authentication.
• Check for ESXi authentication attempts by the group members. Query the ESXi syslog data in Log360 for authentication events from the accounts identified as ESX Admins group members. A successful ESXi authentication from a group member confirms that exploitation has progressed beyond the group creation stage and that the attacker already has ESXi administrative access.
• Check for post-authentication ESXi activity. If ESXi authentication is confirmed, query the ESXi management logs for VM power state changes, snapshot operations, VMDK access, or configuration modifications. Any of these actions following a suspicious authentication indicates active exploitation of the ESXi administrative access.
• Identify the source of the group creation. Review the workstation or server from which the Active Directory group creation was performed. Identify the source IP from the domain controller event log and determine whether it corresponds to a known IT administrator workstation or an unrecognised endpoint. If the source is an end-user workstation, trace back to determine how the account operating on that workstation was compromised.
• Assess the scope of the ESXi hosts at risk. Determine how many ESXi hosts in your environment are joined to the affected Active Directory domain and would therefore be subject to the ESX Admins group-based access grant. All domain-joined ESXi hosts in the domain are potentially affected, not only the host the attacker may have targeted first.

Escalation trigger

Escalate immediately to L3 and initiate emergency ESXi containment procedures if the creating account is not a documented ESXi administrator; if accounts have already been added to the ESX Admins group; if ESXi authentication from a group member is confirmed; or if any VM power state changes or VMDK operations are observed on any ESXi host following the group creation. Do not wait for the investigation to be complete before initiating containment. The window between group creation and active exploitation is measured in minutes.

Responding and remediating

Immediate containment

• Delete the ESX Admins group from Active Directory immediately using the Domain Admins account. This revokes the exploited access grant at the Active Directory level. ESXi will no longer grant administrative access to accounts in this group once it is deleted, effectively closing the exploitation path.
• Isolate the ESXi management network from the corporate network if ESXi authentication by the attacker-controlled account has already been confirmed. Blocking network access to the ESXi management interface prevents the attacker from using their administrative session for further actions even if they have an active authenticated session.
• Disable the account that created the ESX Admins group and any accounts that were added as members of that group. Disabling these accounts in Active Directory prevents further authentication attempts, including against ESXi hosts that may not yet have been accessed.
• If active VM manipulation (power off events, snapshot operations) has been confirmed on any ESXi host, isolate that host from storage and network immediately to prevent further VM access while the scope of the activity is assessed.

Forensic preservation

• Export Windows Security event logs from all domain controllers covering the full period from the first unusual account activity through the ESX Admins group creation and any subsequent group membership additions. These logs are the primary record of the exploitation preparation sequence.
• Export ESXi authentication and management logs from all potentially affected ESXi hosts covering the same period. These logs record which accounts authenticated, what actions they performed, and when. They are required to determine the scope of any VM manipulation that occurred.
• Document the current power state and integrity of all VMs on affected ESXi hosts. Create a snapshot of the current state before any remediation to preserve evidence of what may have been modified, powered off, or accessed.

Eradication and recovery

• Apply the VMware patches that address CVE-2024-37085. VMware released security updates in July 2024. Patched ESXi versions validate the ESX Admins group against a specific, registered group rather than any group with the matching name. Applying the patch eliminates the vulnerability at the hypervisor level.
• As an interim measure before patching, create a legitimate ESX Admins group in Active Directory under a controlled, monitored OU with membership restricted to documented ESXi administrators. The presence of a legitimate ESX Admins group prevents an attacker from creating a new group with the same name, as Active Directory enforces group name uniqueness within a domain.
• Audit all domain-joined ESXi hosts for the current Active Directory authentication configuration and verify the ESX Admins group membership is correctly limited to authorised accounts. Review all ESXi hosts, not only the one that triggered the alert.
• Conduct a full review of all VM power state changes, snapshot operations, and VMDK access events across affected ESXi hosts for the incident window. Restore any VMs that were powered off, and assess the integrity of any VMs whose VMDK files may have been accessed during the attacker's session.

False positive guidance

The ESX Admins group name is specific enough that false positives from this rule are uncommon. The following scenarios may produce legitimate alerts:

• New ESXi host deployment: when a new ESXi host is being deployed and joined to the Active Directory domain, an administrator may create the ESX Admins group as part of the documented setup procedure. This will be performed by a named IT infrastructure team member, from a documented administrative workstation, and will align with a change ticket for the new ESXi deployment. Verify the creating account, the source workstation, and the corresponding change record before closing the alert.
• Group recreation after AD cleanup: organisations that have previously deleted the ESX Admins group as part of a group cleanup exercise may legitimately need to re-create it. This should be performed by a documented ESXi administrator during a planned change window with an approved change ticket. The re-creation should be followed immediately by verifying that only authorised accounts are added as members.
• Testing and validation in development environments: security teams or infrastructure engineers testing the CVE-2024-37085 detection in a non-production environment may trigger the rule intentionally. Notify the SOC before conducting such tests and document the test activity in the incident record when the alert fires.

Key differentiator

Legitimate ESX Admins group creation is performed by a named IT infrastructure team member during a documented new ESXi deployment or a planned group restoration, with a corresponding change ticket, from a known administrative workstation. An exploitation attempt will be performed by a standard user or helpdesk account with no ESXi administration role, with no corresponding change ticket, and from a workstation not associated with IT infrastructure management. Any ESX Admins group creation that cannot be immediately attributed to a documented ESXi deployment or group restoration procedure should be treated as a CVE-2024-37085 exploitation attempt until proven otherwise.

Hardening and prevention

The following controls prevent or limit the impact of CVE-2024-37085 exploitation in your environment:

• Apply the VMware security patches addressing CVE-2024-37085. This is the definitive remediation. Patched ESXi versions validate the ESX Admins group against a specific registered identifier rather than any group with a matching name, eliminating the vulnerability entirely.
• As an immediate interim control before patching, create and maintain a legitimate ESX Admins group in Active Directory under a controlled, monitored OU. A pre-existing ESX Admins group with verified membership cannot be created again by an attacker due to Active Directory group name uniqueness constraints, blocking the exploitation path.
• Restrict the Active Directory permission to create security groups. By default, domain users can create groups in certain OUs. Review the group creation permissions in your Active Directory and restrict the ability to create security groups to designated IT administrator accounts only, removing this permission from standard users and helpdesk accounts.
• Isolate the ESXi management network from the general corporate network using VLAN segmentation and firewall rules. Restricting which hosts and accounts can reach the ESXi management interface means that even if an attacker creates the ESX Admins group, they need network access to the management interface to complete the exploitation. Management network isolation is a defense-in-depth control that limits exploitation to attackers with access to the management network.
• Use ESXi local authentication rather than Active Directory integration where operationally feasible. Removing the Active Directory authentication dependency eliminates the attack surface entirely. For environments where AD integration is required for operational reasons, compensating controls including this detection rule and network isolation are necessary.
• Monitor Active Directory for group creation events involving names that relate to your infrastructure components, not only ESX Admins. Groups named after other management interfaces such as vCenter Admins or HyperV Admins may indicate similar targeting of other management plane components.