What is ESXi Hypervisor CLI Abuse – Bitdefender TechZone

Mechanism. Attackers do not typically arrive at ESXi hosts through direct internet exposure. The common path is lateral movement from a compromised domain environment, or credential theft targeting vCenter. The second vector is exploitation of ESXi-facing management services. CVE-2021-21985, for example, allowed unauthenticated remote code execution via the vSphere Client, a direct pivot to shell access. ESXi-facing CVEs appear regularly in VMware security advisories and CISA's Known Exploited Vulnerabilities catalog.

The Active Directory path needs stating precisely, because it is commonly overstated. ESXi hosts can be joined to Active Directory directly, and in that configuration a compromised domain administrator account grants SSH access to those hosts. But AD domain join for ESXi is optional and not universal. Many environments use vCenter SSO with an AD identity source without joining ESXi hosts to the domain, and in that architecture domain administrator credentials alone do not grant ESXi shell access. vCenter administrative credentials are high-value regardless: an attacker holding them can enable ESXi Shell or SSH on any managed host remotely, whatever the AD configuration.

Why this is possible. Disabling the shell by policy does not remove it. For an authenticated user with sufficient privileges, enabling it is a single command, or a click in the vSphere Client. Interactive access is available through SSH, the ESXi Shell console, or the Direct Console User Interface, and DCUI is reachable through remote management interfaces such as iDRAC or iLO, so physical presence is not required either.

Detection angle. Enablement writes an event to hostd.log on the host, forwarded to vCenter's vpxd.log when the host is managed. The event exists in almost every compromised environment. What is usually missing is anything reading it inside the window where reading it would matter — which turns a real-time signal into a post-incident artifact.

Fig. 2. ESXi VM termination methods: graceful shutdown to force kill, each addressing speed and guest awareness limitations.

Mechanism. ESXi ships two primary command-line interfaces: esxcli, a modern structured CLI for host management, and vim-cmd, VMware's legacy command-line interface to the vSphere APIs. Both run with full hypervisor privileges, both are signed VMware utilities, and both are used daily by legitimate administrators. Attackers use the same commands for reconnaissance, VM manipulation, and impact staging. The table below maps each phase to its commands, artifacts, and detection difficulty.

The first objective is to map the inventory and locate the datastore paths. vim-cmd vmsvc/getallvms lists every registered VM with its datastore path, VMDK locations, and VM ID — the reconnaissance anchor, because it tells the attacker where every virtual disk lives. esxcli vm process list enumerates running VMs with their World IDs, ESXi's internal process identifier for a running VM and a prerequisite for force-kill. esxcli storage filesystem list enumerates mounted datastores, ESXi's storage abstraction, typically backed by VMFS volumes or NFS mounts.

Why this is possible. These are the standard commands. An administrator running them during capacity planning and an attacker running them during reconnaissance produce identical output and identical logs. Nothing distinguishes them.

ESXi locks VMDK files while VMs are running, to prevent simultaneous writes. Encrypting a locked VMDK corrupts the file or fails outright, so attackers stop the VMs first — which is what converts an inventory into a target list. ESXi offers three termination methods and ransomware scripts escalate through them:

Why this is possible. Force-kill exists because administrators genuinely need it. In documented campaigns, scripts enumerate the running VMs, iterate the World IDs, and escalate to force-kill in rapid succession; a host with fifty VMs clears in under a minute. Each shutdown is written to vmkernel.log — which is the point at which the attack becomes loud, and also the point at which almost nothing is listening.

With the VMs stopped, the attacker locates the disks. find /vmfs/volumes/ -name "*.vmdk" searches every datastore recursively and returns the full path to every virtual disk on the host. Additional targets include VMSS (suspend state), VSWP (swap), and VMSD (snapshot descriptor) files.

A note on snapshot recovery. Encrypting VMSD files disrupts snapshot management and prevents clean deletion or consolidation, but the snapshot disk data itself lives in delta VMDKs named <vmname>-000001.vmdk. Campaigns targeting snapshot recovery comprehensively encrypt those too. Encrypting VMSD metadata alone is disruptive but does not destroy snapshot data.

The chain ends with the encryption binary — typically an ELF executable built for ESXi's VMkernel-compatible userspace — iterating the discovered file list and encrypting in place. It is the only non-native component in the entire attack.

Detection angle. No command above is anomalous, and no phase produces a persistent artifact until the encryption stage, by which point the outcome is already decided. What the phases produce instead is an order: enumerate, stop, locate, encrypt, with no intervening administrative action and no change ticket. Detect the sequence, not the command. The specific tells are a kill sequence covering most VMs on a host with nothing between the kills, datastore enumeration followed immediately by recursive VMDK discovery, and find output redirected to a file — which indicates a script rather than a person.

Internal placement does not prevent access when the attacker arrives with credentials rather than an exploit. The entry point is credential theft and lateral movement from an environment that is already compromised. The host's network position is irrelevant to an authenticated session. Segmentation reduces who can reach the host, not what a legitimate administrator can do once they are on it. It raises the cost of the pivot and changes nothing about the technique that follows.

Disabling the shell removes it from the default configuration, not from the host. Any authenticated user with sufficient privileges turns it back on in one command, and with vCenter credentials it can be enabled remotely on any managed host through the vSphere Client or the API. Shell disablement is a control on convenience, not on capability. It is worth doing — the enablement event is one of the few high-fidelity signals available - but its value is that it forces the attacker to generate that event, not that it stops them

The hypervisor context changes the arithmetic in both directions. One compromised host is dozens of encrypted VMs from a single session, and there is no agent inside ESXi watching for it. Recovery is worse too: restoring individual Windows machines from backup is a practiced workflow, while restoring datastores, re-registering VMs, and validating VMDK integrity across every workload on a host has more steps and more failure points. This is not endpoint ransomware that happens to run on a hypervisor. It is an infrastructure attack that uses the hypervisor's own management plane, and it should be planned for as one.

Being infrastructure is the reason they are targeted, not a reason they are safe. But the objection contains a true premise: agent-based endpoint protection genuinely does not apply, because it requires a resident agent inside an OS that will not host one. The answer is not an agent on the hypervisor but monitoring that operates outside the guest — real-time correlation of shell activity against VM state changes, and network analysis of the management segment.