Why hypervisor targeting changes the game
Most endpoint protection runs inside the guest OS. The hypervisor sits below it. An attacker who compromises ESXi directly can encrypt every virtual disk on the host without triggering a single guest-level detection. The VMs don't crash from malware. They crash because the hypervisor killed them and encrypted their storage. Scattered Spider, LockBit, Akira, BlackCat, Play, and Fog affiliates all target ESXi specifically because it multiplies impact while evading the entire endpoint security stack.
The ESX Admins AD group. By default, VMware ESXi trusts an Active Directory group called "ESX Admins" for administrative access when joined to a domain. Attackers create this group in AD (or add themselves to it if it exists), and ESXi grants them full admin access automatically. No ESXi credential needed. No vCenter required. AD group membership equals hypervisor admin. Multiple ransomware campaigns have exploited this exact path.
Hunt checklist
- 1. Check for ESX Admins group creation or modification in AD Search Security EID 4727 (group created) and EID 4728 (member added) for the "ESX Admins" group. If this group was recently created or had new members added, and those members are not authorized VMware administrators, this is a high-confidence pre-attack indicator. Security EID 4727/4728 · AD group audit · Hybrid AD
- 2. Monitor for SSH access to ESXi hosts ESXi SSH should be disabled in production. If enabled, search for: SSH connections to ESXi management IPs from unexpected sources, new SSH keys added to ESXi authorized_keys, and SSH sessions from hosts that are not in your VMware admin jump box list. ESXi: /var/log/auth.log · Zeek: SSH connections to ESXi management VLAN
-
3. Hunt for esxcli VM termination commands
Before encrypting .vmdk files, ransomware operators must power off the VMs. Search ESXi shell history and logs for:
esxcli vm process kill,vim-cmd vmsvc/power.off, andesxcli vm process list(reconnaissance). Mass VM termination followed by file modifications in /vmfs/volumes/ is the ransomware deployment sequence. ESXi: /var/log/shell.log · vCenter: task/event logs · Ransomware - 4. Check for NTLM relay to ESXi management Attackers relay NTLM credentials from compromised hosts to ESXi management interfaces (HTTPS on 443). Search for: NTLM authentication events on ESXi from non-vCenter sources, vCenter admin role assignments to unexpected accounts, and new ESXi local accounts created via the web management interface. ESXi: /var/log/hostd.log · vCenter audit logs · PetitPotam (NTLM relay)
- 5. Monitor /vmfs/volumes/ for ransomware artifacts Search for: new ELF binaries in /vmfs/volumes/ or /tmp/ on ESXi hosts, file extension changes on .vmdk/.vmx/.vmxf files, and ransom notes dropped alongside encrypted virtual disks. ESXi ransomware is compiled as Linux ELF binaries targeting the ESXi environment specifically. ESXi: file system monitoring on /vmfs/volumes/ · FIM
- 6. Verify vCenter access controls and segmentation vCenter should be accessible only from authorized management networks. Check for: vCenter web console access from non-admin subnets, vCenter API calls from unexpected sources, and vCenter admin role grants to non-VMware-admin accounts. Segment ESXi management interfaces onto a dedicated VLAN with strict ACLs. vCenter: audit log · Firewall rules on ESXi management VLAN
Related playbooks
Ransomware Detected (ESXi targeting is a primary deployment method)
Scattered Spider (ESXi is their preferred encryption target)
Hybrid AD Enterprise (ESX Admins group abuse via AD)
PetitPotam (NTLM relay to ESXi management)