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.
The virtualization trust stack and recurring entry paths (Source: securelist)
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.
Compromise of the management plane converted a legitimate compliance mechanism into an access path to the managed hypervisor (Source: securelist)
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
CategoryItemDetail / ContextConfidenceScopeServicevmware-vdmaSystemd unit masquerading as a VMware service on VCSAHighIncident-specificServicevspbindWindows service for the remote-management agentHighIncident-specificDomainapi.cloudvflare[.]comLigolo-ng C2; one-character typosquat of cloudflare.comHighIncident-specificIPv445.149.154[.]135Remote-management agent C2HighIncident-specificIPv491.92.242[.]121VPS used for initial portal accessHighIncident-specificIPv431.41.33[.]212VPS used for initial portal accessHighIncident-specificIPv4188.240.57[.]94VPS used for initial portal accessHighIncident-specificSHA-128f8da19ddcdf26e426875c7a834b34a79bc1c33svhost.exe / lock.exeHighSample-specificSHA-25615dc419b7fbeb50c50820a7cd27997541deafa4fa710f074bb657f0149574bafRemote-management agentHighSample-specificSHA-2565a9b7a0d3f25757aea957713d7e84cabec87597b3474368328a8fd5ed7a12f78Installed remote-management agent variantHighSample-specificForensic source: ESXi authentication/var/run/log/auth.logSource IPs, users, SSH timing, and client identifiersN/AMinimum collection setForensic source: ESXi commands/var/run/log/shell.logExact commands executed through ESXi ShellN/AMinimum collection setForensic source: vCenter-to-host managementvpxa.log + vCenter Events/TasksHost Profile remediation, service changes, and administrative sourceN/AMinimum collection setForensic source: Host security observationsvobd.logexecInstalledOnly, service, and security-state eventsN/AMinimum collection setForensic source: Host managementhostd.logVM and host tasks, and API/management interactionsN/AMinimum collection setForensic source: Kernel / storagevmkernel.log + vmkwarning.logStorage faults, world lifecycle, and VMkernel warningsN/AMinimum collection setForensic source: Impact scalevmksummary.logHourly VM count and host heartbeatN/AMinimum collection setForensic source: VIB historyesxupdate.logPatch / VIB installationN/AMinimum collection setForensic source: Host Profilehostprofiletrace.logProfile application and compliance activityN/AMinimum collection setForensic source: Per-VM evidencevmware.log beside VMXPower and device operations for individual VMsN/AMinimum collection setForensic source: VCSA persistence/etc/systemd/system + referenced binariesUnauthorized services and persistence pathsN/AMinimum collection setForensic source: VCSA accessSSO logs, auth logs, wtmp, shell historyAuthentication, session, and command contextN/AMinimum collection setForensic source: Backup layerApplication logs + Windows telemetry + credential-store evidenceRecovery-path compromise and credential bridgeN/AMinimum collection setForensic source: NetworkFirewall / flow / proxy / DNSvCenter-to-ESXi SSH, C2, tunneling, and management-segment pivotsN/AMinimum collection set
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
——————————————————–
Click Here For The Original Source.
