BlackNevas Ransomware Attacks VMware ESXi Servers, Destroying Virtual Machines and Backup Infrastructure - GBHackers News
The BlackNevas ransomware group has been documented destroying an organization's entire virtualization estate over 10 days, wiping four ESXi hosts and all virtual machines.
Kaspersky's Global Emergency Response Team (GERT) has documented a sophisticated attack where the BlackNevas ransomware group systematically destroyed an organization's virtualization infrastructure. The attackers wiped four ESXi hosts, every virtual machine on them, both vCenter Server Appliances (VCSA), and all connected backup infrastructure over a 10-day period.
Notably, the attackers exploited no hypervisor flaw, guest-to-host escape, or memory corruption. Instead, they performed all actions through legitimate VMware management interfaces, making the intrusion appear as routine administration. This approach allowed them to bypass traditional security monitoring that focuses on detecting malicious activity rather than legitimate administrative actions.
Initial Access
The attackers gained initial access using valid credentials (MITRE ATT&CK T1078) from non-virtualization systems within the network perimeter. These credentials provided access to the vCenter appliances. Once inside, they extracted stored secrets from backup servers after gaining administrative execution, leveraging service accounts, hypervisor credentials, and repository access to pivot into other system tiers.
Backup platforms hold service accounts, hypervisor credentials and repository access, which makes them a convenient pivot into other tiers.
Persistence Techniques
On the disaster-recovery vCenter, the operators connected over SSH as root and deployed MeshAgent, the endpoint component of MeshCentral, within just 43 seconds. Approximately four hours later, they returned through MeshAgent and installed a Ligolo-ng reverse tunnel as a systemd unit named vmware-vdma.service. The binary was placed under /opt/vmware/bin/agent and communicated with api.cloudvflare[.]com:443.
The most unusual technique involved abuse of vCenter Host Profiles. The attackers used the compliance workflow to push a configuration change that switched TSM-SSH from disabled to running. SSH reached the RUNNING state just 33 seconds after the push, with direct sessions to the ESXi hosts originating from the trusted vCenter IP address.
Destruction Phase
Before detonation, the attackers disabled antivirus on the backup environment days in advance, stopped backup services, and encrypted the recovery repositories. This strategic ordering removed the restore path before production systems were affected. The payload arrived over SFTP, with auth.log recording a FlowSsh client identifier. The operators executed the binary with specific switches matching the Trigona-derived BlackNevas family.
The final command, ./tmp/esx64 /p /vmfs/ /depth 5 /wipe /allsys /detach /-showvolumes, caused every VM on the disaster-recovery host to stop within 23 seconds. The attackers overwrote the first 2 KB of each virtual disk, destroying the MBR and primary GPT header, though the backup GPT may allow partial recovery in some cases.
Mitigation Recommendations
Defenders should treat vCenter as a Tier 0 asset and provide it with dedicated administrative identities using phishing-resistant MFA. Organizations should maintain the execInstalledOnly runtime option and VIB acceptance levels at their approved baseline, and enable Lockdown Mode where operations allow. Since ESXi logs reside in a ramdisk cleared on reboot, forward auth.log, shell.log, vpxa.log, and vobd.log to remote syslog.
Security experts recommend separating backup authority from production Active Directory and testing restores on the assumption that vCenter and AD are unavailable. Patching alone is insufficient, as recovery systems sharing the production identity plane can be compromised through it. A Backup Viewer deserialization flaw (CVE-2025-64393) demonstrates how a single low-privilege role can yield SYSTEM execution on backup servers.
Related
