It took the attacker eleven minutes to turn a VMware compliance feature into a way in. Using vCenter Host Profiles, a tool built to keep ESXi hosts configured to a known good state, the intruder pushed a change that switched SSH on across the target hypervisors, then logged into them directly from the vCenter appliance itself, a source most networks treat as fully trusted.
That is one of the more striking findings in a new report by Elsayed Elrefaei and Mohamed Ghobashy of Kaspersky's Global Emergency Response Team (GERT). Over a 10-day period, the attackers destroyed the victim organization's whole virtualization estate: four ESXi hosts, every virtual machine on them, both vCenter Server Appliances and all connected backup infrastructure. The ransom notes named BlackNevas, a group first observed in November 2024.
The key detail is what was missing. Kaspersky found no guest-to-host escape and no hypervisor memory corruption. "Every action taken against ESXi was executed through legitimate VMware management interfaces," the researchers write.
Stolen admin passwords reached vCenter first
The intrusion did not start at the hypervisor. Credentials taken from non-virtualization systems inside the network were used to log into the vCenter appliances, and after gaining administrative execution on the backup infrastructure, the attacker extracted the credentials stored there. Kaspersky calls backup servers "a concentrated trust point" because they hold hypervisor credentials and broad network reach in order to do their job. A valid login, the team notes, can look operationally normal unless analysts check the source host, the time and what the account normally manages.
This is the second Kaspersky GERT case involving BlackNevas we have covered this month. In an earlier investigation, a reused ESXi root password stored in a monitoring tool did the damage.
A fake VMware service kept the door open
On the vCenter appliance that managed disaster recovery, the attacker logged in as root over SSH and, 43 seconds later, deployed MeshAgent, the endpoint component of the legitimate MeshCentral remote management platform. The whole SSH session lasted 2 minutes and 26 seconds, and the intruder never used SSH on that appliance again, which blunts monitoring that only watches interactive sessions.
About four hours later they returned through MeshAgent and installed Ligolo-ng v0.8.2, a reverse tunnelling tool, as a systemd service named vmware-vdma. The unit pointed at /opt/vmware/bin/agent, carried the description "DNS, time, VM settings sync (v2.03.24766)" and was set to restart always. Kaspersky says a VMware-looking service that is absent from an organization's list of trusted services is "a high-confidence anomaly requiring immediate validation."
Alert when Host Profiles touch SSH
The Host Profiles sequence left a tight, correlatable trail: the host configuration read at T+0, the change pushed at 10 minutes 18 seconds, and the TSM-SSH service reaching RUNNING 33 seconds later, recorded across vpxa.log and vobd.log. Kaspersky's recommendations:
- Alert when Host Profile remediation changes TSM or TSM-SSH outside an approved change window, especially when a new SSH session from vCenter or another management appliance follows.
- Treat vCenter as a Tier 0 asset. Use separate administrative accounts for the domain and for hypervisors, and restrict management interfaces to dedicated network paths.
- Alert on any change to the host acceptance level or the execInstalledOnly setting, which ESXi 8 enables by default to block binaries not installed through VIB packages.
- Where ESXi is joined to Active Directory, apply Broadcom's workaround for CVE-2024-37085 on older hosts (set esxAdminsGroupAutoAdd to false and authValidateInterval from 1440 to 90 minutes), or move to ESXi 8.0 U3, which fixes it.
Kaspersky adds that the targeted organizations were running unsupported ESXi versions, which made them easier to attack.
Indicators from the investigation
Kaspersky published the following indicators recovered during the engagement (defanged):
- Ligolo-ng tunnel endpoint: api[.]cloudvflare[.]com:443
- IP addresses: 45[.]149[.]154[.]135, 91[.]92[.]242[.]121, 31[.]41[.]33[.]212, 188[.]240[.]57[.]94
- SHA256: 15dc419b7fbeb50c50820a7cd27997541deafa4fa710f074bb657f0149574baf, 5a9b7a0d3f25757aea957713d7e84cabec87597b3474368328a8fd5ed7a12f78
- SHA1: 28f8da19ddcdf26e426875c7a834b34a79bc1c33
- Persistence artifact: /etc/systemd/system/vmware-vdma.service
The uncomfortable lesson is that hardening an ESXi host means little once the system allowed to reconfigure it is in hostile hands. When a single management plane can rewrite the security posture of every host it controls, it deserves the protection of a domain controller, not of an appliance someone set up and forgot.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.