BlackNevas Ransomware Attacks VMware ESXi Servers, Destroying Virtual Machines and Backup Infrastructure

A newly disclosed intrusion in which the BlackNevas group destroyed an organization’s entire virtualization estate over 10 days.

Kaspersky’s Global Emergency Response Team (GERT) documented the attackers wiped four ESXi hosts, every virtual machine on them, both vCenter Server Appliances (VCSA) and all connected backup infrastructure.

They exploited no hypervisor flaw, guest-to-host escape, or memory corruption. Every action ran through legitimate VMware management interfaces, so the intrusion looked like routine administration.

BlackNevas Ransomware Attacks VMware ESXi Servers

Initial movement relied on valid accounts (MITRE ATT&CK T1078). Credentials from non-virtualization systems inside the perimeter gave access to the vCenter appliances.

The attackers also extracted stored secrets from backup servers after gaining administrative execution there. Backup platforms hold service accounts, hypervisor credentials and repository access, which makes them a convenient pivot into other tiers.

Similar flaws in backup software keep appearing, such as the BinaryFormatter deserialization RCE in Veeam Backup & Replication, which lets low-privileged domain users run code on backup servers.

On the disaster-recovery vCenter, the operators connected over SSH as root and deployed MeshAgent, the endpoint component of MeshCentral, within 43 seconds.

About four hours later they returned through MeshAgent and installed a Ligolo-ng reverse tunnel as a systemd unit named vmware-vdma.service.

The binary sat under /opt/vmware/bin/agent and beaconed to api.cloudvflare[.]com:443. The unit used a VMware-style description and Restart=always, which maps to T1543.002 (Systemd Service) and T1572 (Protocol Tunneling). Because the actors never used interactive SSH again, monitoring limited to SSH sessions missed them.

The most unusual technique was abuse of vCenter Host Profiles. The adversary used the compliance workflow to push a configuration change that switched TSM-SSH from disabled to running.

SSH reached the RUNNING state 33 seconds after the push, and direct sessions to the ESXi hosts then originated from the trusted vCenter IP. Defenders can correlate vpxa.log and vobd.log entries to catch this sequence.

Alert on Host Profile remediation that alters TSM-SSH outside an approved change window, followed by a new SSH session from the management appliance.

Before detonation, the actors disabled antivirus on the backup environment days ahead, stopped backup services and encrypted the recovery repositories.

This ordering removed the restore path before production was touched. Critical remote code execution flaws in Veeam Backup & Replication are a recurring route to that kind of backup tampering.

Patching alone is not enough, because a recovery system sharing the production identity plane can be compromised through it. A Backup Viewer deserialization flaw, CVE-2025-64393, shows how a single low-privilege role can yield SYSTEM execution on the backup server.

The payload arrived over SFTP, and auth.log recorded a FlowSsh client identifier. The operators ran chmod +x on /tmp/esx64 and executed it with the /selftest switch for about 16 seconds.

Securelist said roughly three hours later they launched the final command, ./tmp/esx64 /p /vmfs/ /depth 5 /wipe /allsys /detach /-showvolumes. The forward-slash switches match the Trigona-derived BlackNevas family.

Every VM on the disaster-recovery host stopped within 23 seconds, and vmksummary.log showed the running-VM count dropping to zero. Roughly the first 2 KB of each virtual disk was overwritten, destroying the MBR and primary GPT header. The backup GPT may still allow partial recovery.

Defenders should treat vCenter as a Tier 0 asset and give it dedicated administrative identities with phishing-resistant MFA. They should keep the execInstalledOnly runtime option and VIB acceptance levels at their approved baseline, and enable Lockdown Mode where operations allow.

ESXi logs live in a ramdisk that is cleared on reboot, so forward auth.log, shell.log, vpxa.log and vobd.log to remote syslog. Separate backup authority from production Active Directory, and test restores on the assumption that vCenter and AD are unavailable.

IOCs

Note: IP addresses and domains are intentionally Qdefanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Join 16,000+ SOC teams using ANY.RUN to streamline threat investigations and reduce manual effort. Explore for your team