Attackers did not need to break out of a virtual machine to destroy this VMware environment. They obtained administrative access, used vCenter’s own configuration system to open SSH on the hosts, and damaged the recovery infrastructure before the final attack. Kaspersky’s November 13 investigation describes a ten-day intrusion that hit four ESXi hosts, their virtual machines, both vCenter appliances and connected backups. Ransom notes named BlackNevas; the report does not date the attack to this week.
The backup server also held a route into production
The access crossed several administrative boundaries. Credentials recovered from systems outside the virtualization layer let the intruder reach vCenter. Administrative execution on the backup infrastructure exposed more stored credentials. A system intended to restore production could therefore help someone administer it.
On the disaster-recovery vCenter appliance, a root SSH login was followed within 43 seconds by installation of MeshAgent, a legitimate remote-management agent. About four hours later, the intruder added a Ligolo-ng reverse tunnel under a plausible-looking service name, vmware-vdma. Its executable sat under /opt/vmware/bin/.
The brief SSH session was no longer the whole access story. The additional channels gave investigators a reason to examine services and outbound connections as well as interactive logins. A VMware-like name alone does not identify malware; its origin and whether the organization approved it matter.
Host Profiles turned a closed service back on
vCenter Host Profiles let administrators apply a common host configuration. Here, the attacker used that authority to enable TSM-SSH, the ESXi remote-shell service. Logs connected the configuration push to the service entering its running state 33 seconds later. Direct SSH access then came from the vCenter appliance’s IP address.
This explains why simply checking that SSH was disabled would have been an incomplete assessment. The account controlling the desired configuration could change that state. A connection from the trusted management server could look routine unless the defender also checked who requested the change and whether it matched an approved task.
It is a different episode from the earlier BlackNevas case involving PRTG credentials. That investigation traced a shared root password and an execution restriction changed after a blocked launch. The new report follows central management authority into the hosts.
The destructive run had a rehearsal
The attacker delivered an executable called esx64 over SFTP. Host logs recorded a /selftest run lasting about 16 seconds, roughly three hours before the destructive execution. That is a useful investigative interval: staging, a permission change and an unexpected test could be visible before virtual-machine storage is hit.
The report associates the operation with BlackNevas through the ransom notes and corroborating command-line characteristics. Investigators did not have the binary to validate every switch’s implementation. Likewise, observed overwriting of roughly the first 2 KB of virtual disks does not establish that every byte was erased or that every disk is recoverable. Disk layout and additional damage determine the recovery options.
Recovery had already been attacked
Before the final ESXi impact, the operator disabled antivirus in the backup environment, stopped backup services, encrypted recovery infrastructure and disrupted administrative access. This order matters: a backup can exist while the systems and identities needed to restore it are unavailable. The separate investigation into The Gentlemen also illustrates why backup repositories and their credentials deserve their own security boundary.
For an administrator investigating a similar sequence, the useful evidence spans both sides of management: vCenter Events and Tasks for the initiating account; vpxa.log and vobd.log for host configuration and service changes; and auth.log and shell.log for subsequent access and commands. Compare those events with change records and preserve them outside the affected infrastructure. A legitimate maintenance task can enable SSH, so the connected sequence is more informative than a service-state alert alone.
The practical review is whether ordinary administration, virtualization control and recovery share the same credentials and reachable management paths. Separate those authorities, restrict direct host access and test restoration using an independent recovery route. Patching remains necessary; this case shows why credentials and management privileges need equal attention.
References
- Elsayed Elrefaei and Mohamed Ghobashy, Kaspersky GERT. Ransomware at the hypervisor layer: how attackers use ESXi and vCenter features for malicious purposes. Securelist, November 13, 2026; accessed November 14, 2026. Investigation, timeline and incident indicators.
