“Ten days of dwell time from initial access to the destructive phase.” That is the forensic timeline recovered by Kaspersky’s Global Emergency Response Team (GERT) after an adversary, identifying itself as BlackNevas, systematically destroyed an organization’s virtualization estate: four ESXi hosts, every virtual machine on them, both vCenter Server Appliances, and all connected backup infrastructure.
What happened: management-plane compromise, not a hypervisor exploit
GERT’s investigation found no guest-to-host escapes or hypervisor memory corruption. Instead, every malicious action against ESXi and vCenter was executed through legitimate VMware management interfaces. The attackers authenticated to a vCenter appliance via SSH as root, staged remote-management software, and then used vCenter workflows and Host Profiles to reach ESXi hosts. The ransom notes named BlackNevas — a group first observed in November 2024 — and the attack chain exploited features and trust relationships in the virtualization management plane rather than technical flaws in the VMkernel itself.
Paths to the hypervisor and how persistence was established
The report identifies four common entry paths to virtualization infrastructure: public vulnerability exploitation, credential reuse from the Windows estate, abused Active Directory integration, and backup infrastructure used as a credential bridge. While this incident did not show an ESXi vulnerability as the initial vector, the advisory lists numerous CVEs relevant to defenders, including CVE-2021-21972, CVE-2021-22005, CVE-2021-21985, CVE-2023-34048, CVE-2024-37085, CVE-2024-38812/38813 and the CVE-2025-22224/22225/22226 guest-to-host chain.
On the breached vCenter appliance, two persistence layers were observed: MeshAgent (a legitimate MeshCentral endpoint) installed via a shell script, and Ligolo‑ng implemented as a systemd service named vmware-vdma under /etc/systemd/system and /opt/vmware/bin — a service that masqueraded as a VMware housekeeping unit and requested Restart=always. The attackers later used Host Profiles to flip TSM-SSH from policy-disabled to RUNNING and, within 11 minutes of reading the Host Profile, began direct SSH access to ESXi hosts from the vCenter IP — a highly trusted source on the management network.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadStaging, testing, and the destructive payload
The ESXi payload arrived via SFTP. Auth logs contained a client identifier associated with FlowSsh, and shell.log captured staging and execution of /tmp/esx64, including a /selftest run roughly three hours before final detonation. The observed detonation command was:
./tmp/esx64 /p /vmfs/ /depth 5 /wipe /allsys /detach /-showvolumes
Forensics showed ~2 KB overwrites at the start of virtual-disk files — sufficient to corrupt MBR or primary GPT structures in many layouts — and a rapid mass VM stop: on the disaster-recovery host all VMs stopped within 23 seconds. Importantly, backup capability had been attacked first: antivirus protections on the backup environment were disabled days earlier, backup services were stopped, recovery infrastructure was encrypted and administrative access disrupted before ESXi detonation, denying straightforward restoration.
Detection opportunities and the telemetry defenders must collect
Because ESXi often cannot host off-the-shelf agents, GERT emphasizes management-plane and host-native logs. Priority sources include auth.log (SSH authentication and client identifiers), shell.log (every ESXi Shell command), vpxa.log and vCenter Events/Tasks (Host Profile and remediation activity), and vobd.log (execInstalledOnly and service-state events). Other useful sources are vmkernel.log, vmksummary.log, esxupdate.log, hostprofiletrace.log, per-VM vmware.log, and VCSA systemd and filesystem paths.
High-fidelity detections arise from correlating legitimate actions into dangerous sequences. The report highlights several critical sequences: Host Profile remediation changing TSM-SSH to RUNNING outside an approved window followed by an SSH session from vCenter; new or modified VMware-looking systemd units pointing to non-baselined binaries; execInstalledOnly or host acceptance-level weakening; SFTP staging to /tmp followed by chmod/execution and access to /vmfs; and rapid mass VM power-off or world-kill operations. The source provides example correlation logic for Host Profile abuse and pre-impact payload staging that defenders can adapt into SIEM rules.
What this means for technologists, policymakers, and affected enterprises
- Technologists and security teams: Treat vCenter as Tier 0. Isolate virtualization administrative identities, restrict management-network access, enforce phishing-resistant MFA and identity federation, monitor Host Profile and cluster changes, forward ESXi and VCSA logs off-host, and test restore procedures that do not depend on the production control plane.
- Procurement and enterprise leaders: Design recovery as an independent security boundary. Ensure backup servers use separate administrative identities, isolate repositories, and assume production identity and management-plane compromise when validating restore capability.
- Policymakers and regulators: Prioritize visibility and retention requirements for virtualization-layer telemetry and consider guidance around management-plane segregation and minimum logging standards for ESXi and vCenter appliances.
GERT’s core conclusion is architectural: a patched hypervisor can still be the point of maximum ransomware impact when the management plane, identity plane, or recovery plane is compromised. The durable defense is therefore to harden those planes together — treat vCenter as Tier 0, separate identities, narrow direct ESXi access, preserve native logs outside the platform, and design backups as an independent authority.
Read the original investigation: https://securelist.com/esxi-ransomware/121959/
