BlackNevas Wiped an ESXi Estate in 10 Days Without a Single Hypervisor Exploit

A ransomware crew destroyed an organization's entire virtualization estate over 10 days without exploiting a single ESXi or vCenter vulnerability. Kaspersky's Global Emergency Response Team (GERT), which investigated the incident, says the BlackNevas group — first observed in November 2024 — took out four ESXi hosts, every virtual machine on them, both vCenter Server Appliances and all connected backup infrastructure using nothing but legitimate VMware management interfaces.

No guest-to-host escapes. No hypervisor memory corruption. Just stolen credentials and the tools vCenter already trusts.

Why the hypervisor changes ransomware economics

Virtualization consolidates control points — and that cuts both ways. In a non-virtualized environment, one compromised guest affects one OS. Compromise the management plane, and an attacker reaches every host and every datastore at once. When domain controllers, databases and backup workloads share the same estate, one privileged vCenter login becomes maximum blast radius.

Kaspersky's global security services report puts ransomware at 39.4% of GERT incidents in 2025, and 2026 data shows the trend holding. Since the Babuk ESXi source code leaked in September 2021, at least ten ransomware families have shipped ESXi-capable lockers built on it — many run by crews that couldn't write one from scratch. Notably, victim organizations in this case ran unsupported ESXi versions, making them easier targets.

How did the attackers get in?

Four routes dominate, and three need no vulnerability at all:

• Vulnerability exploitation — CVE-2021-21972, CVE-2021-22005, CVE-2024-37085 (used by Akira and Black Basta) and CVE-2025-22225 (seen in ransomware) all carry CISA KEV listings, though none were used here.
• Credential reuse — admin accounts lifted from Windows systems carried the attackers straight into vCenter. A valid login looks operationally normal.
• Active Directory integration abuse — where AD groups map to ESXi admin rights, domain compromise can equal hypervisor compromise.
• Backup infrastructure as a credential bridge — backup servers store hypervisor credentials; the attackers harvested them after gaining admin execution there.

In this incident, credentials from non-virtualization systems opened the vCenter appliances. The initial access came through SSH.

Persistence in 43 seconds

The attackers logged into the disaster-recovery vCenter appliance as root via SSH. Forty-three seconds later, they deployed MeshAgent — the endpoint component of the legitimate MeshCentral platform. The SSH session lasted 2 minutes 26 seconds; they never used SSH again. Four hours later, they returned via MeshAgent and installed a Ligolo-ng reverse tunnel as a systemd service named vmware-vdma, describing itself as "DNS, time, VM settings sync," with its binary planted in /opt/vmware/bin/ and Restart=always. The C2 domain: api.cloudvflare[.]com — a one-character typosquat of cloudflare.com.

Turning vCenter into an attack tool

Then came the trick worth every CISO's attention. The attackers abused vCenter Host Profiles — a compliance feature meant to enforce host configuration — to flip TSM-SSH to RUNNING on target ESXi hosts. Eleven minutes after the initial configuration read, policy-disabled SSH became direct remote access. Subsequent SSH connections originated from the vCenter appliance IP, a source most management networks implicitly trust.

Each step was legitimate in isolation. The sequence was not.

Detonation and recovery destruction

The payload arrived via SFTP, stamped with a FlowSsh client identifier, staged to /tmp/esx64. A /selftest run — about 16 seconds — executed roughly three hours before detonation, likely validating compatibility with the target build. The final command targeted the VMFS root with /wipe, /allsys, /detach and /-showvolumes, parameters matching documented BlackNevas/Trigona family behavior. The encryptor overwrote roughly the first 2 KB of virtual disk files — enough to kill the protective MBR and primary GPT header, though backup GPT structures may permit partial recovery.

All VMs on the disaster-recovery host stopped within 23 seconds.

Crucially, backups were hit first: antivirus on the backup environment was disabled days before, then services stopped, recovery infrastructure encrypted and administrative access cut — all before the ESXi detonation.

What does this change for defenders?

The lesson is architectural, not product-shaped:

• Treat vCenter as Tier 0 — dedicated admin identities, phishing-resistant MFA, restricted management networks, monitored Host Profile changes.
• Separate virtualization identities from ordinary enterprise admin credentials; where ESXi is domain-joined, follow Broadcom's workarounds (fixed in ESXi 8.0 U3) for CVE-2024-37085.
• Keep direct SSH exceptional, and alert when Host Profile remediation enables TSM-SSH outside approved windows — especially followed by SSH from vCenter.
• Forward ESXi logs remotely — auth.log, shell.log, vpxa.log, vobd.log; ESXi logs live on a ramdisk and vanish at reboot.
• Design backup as a separate security boundary with independent identities, so production compromise can't authorize destruction of the recovery path itself.

A fully patched hypervisor still became the point of maximum impact. The battle was won by the attacker before encryption ever began — in identity, management and recovery planes that most endpoint tools never see.