How Ransomware Turns VMware Management Into a Force Multiplier

Ransomware against VMware infrastructure does not require a guest-to-host escape or a novel hypervisor exploit. A compromise of the virtualization management plane can be enough to turn routine administrative capabilities into a destructive control system.

That is the central finding from Securelist, Kaspersky's research and incident-response publication, which examined an intrusion that ultimately affected four ESXi hosts, the virtual machines running on them, two vCenter Server Appliances and connected backup infrastructure. The attackers spent approximately 10 days inside the environment before the destructive phase.

The investigation identified the BlackNevas group in ransom notes. Securelist also assessed similarities between the observed ESXi command line and publicly documented BlackNevas and Trigona-family behavior. That comparison strengthened the assessment, but the researchers did not have the encryptor binary or a hash to validate the attribution directly. The case should therefore be understood primarily as an analysis of an attack pattern, rather than as a universal signature for BlackNevas.

Why the virtualization layer changes the impact calculation

In a conventional server environment, compromising one operating system may initially affect one workload. In a virtualized environment, control of vCenter or an ESXi host can provide access to many workloads through a small number of administrative interfaces. Domain controllers, databases, application servers and backup systems may all depend on the same virtualization estate.

This creates a visibility gap. Guest operating systems can have endpoint detection and response agents, but those agents cannot directly observe a process on ESXi modifying a virtual disk file. They may see the consequences—such as I/O failures, abrupt shutdowns or an unbootable system—without seeing the process responsible.

Securelist notes that third-party endpoint agents are not generally installed directly on ESXi or the vCenter Server Appliance. Defenders therefore need to rely on native hypervisor logs, vCenter task and event telemetry, network monitoring, centralized logging and controls outside the affected platform.

Access paths into the management plane

The investigated intrusion did not show evidence that an ESXi vulnerability was used for initial access. Instead, credentials obtained from non-virtualization systems inside the organization were used to reach the vCenter appliances. This is an important distinction: a fully patched hypervisor can still be exposed when privileged identities are reused across the Windows, backup and virtualization estates.

Securelist identifies four recurring routes into virtualization infrastructure:

• Vulnerability exploitation: publicly known flaws in vCenter, ESXi or related components remain a relevant exposure, even though they were not implicated as the initial access route in this case.
• Credential reuse: administrative credentials from domain controllers, jump servers, administrator workstations or other systems may also work against vCenter or ESXi.
• Active Directory integration: overly broad relationships between domain groups and ESXi administration can allow a domain compromise to become a hypervisor compromise.
• Backup infrastructure: backup servers often store hypervisor credentials and have wide network access, making them a potential bridge between production and recovery environments.

The report specifically discusses CVE-2024-37085, which concerns ESXi hosts configured for Active Directory user management. The issue can allow abuse of the ESX Admins group behavior to obtain full ESXi administration. Securelist cites the vulnerability as an example of why domain membership should not automatically confer hypervisor-level authority. The report states that the issue is fixed in ESXi 8.0 U3 and describes configuration changes recommended for older systems.

Other vulnerabilities listed by Securelist include CVE-2021-21972, CVE-2021-22005, CVE-2021-21985, CVE-2021-21974, CVE-2023-34048, CVE-2024-38812, CVE-2024-38813 and CVE-2025-22224 through CVE-2025-22226. The researchers explicitly caution that these examples were not evidence of exploitation in the incident under review. They represent virtualization attack-surface considerations, and known exploitation or KEV status does not by itself establish ransomware use in this case.

Persistence beyond the original SSH session

After authenticating to a vCenter appliance as root over SSH, the attackers installed MeshAgent, a component of the legitimate MeshCentral remote-management platform. They later installed Ligolo-ng as a reverse tunnel configured to run as a systemd service. Securelist maps these observed behaviors to MITRE ATT&CK Systemd Service, T1543.002, and Protocol Tunneling, T1572.

The persistence service was named vmware-vdma.service, used a VMware-looking path under /opt/vmware/bin/, and was configured to restart automatically. Its description presented it as an appliance-maintenance function. The report treats this as a high-confidence incident artifact, while also warning that VMware-like names should not be judged in isolation because legitimate custom integrations can exist.

The associated Ligolo-ng infrastructure included the defanged domain api[.]cloudvflare[.]com. Securelist also recovered a remote-management agent address, 45[.]149[.]154[.]135, and infrastructure addresses 91[.]92[.]242[.]121, 31[.]41[.]33[.]212 and 188[.]240[.]57[.]94. These are incident-specific indicators, not durable identifiers for the malware or group, and should be handled as retrospective hunting data.

Using vCenter to change host security state

A particularly important part of the sequence involved Host Profiles. The attackers used vCenter to change the TSM-SSH setting on target ESXi hosts, enabling SSH where policy had previously disabled it. The observed sequence began with a Host Profile configuration read, followed about 10 minutes later by a configuration push, and then by the ESXi TSM-SSH service reaching a running state.

This is a trust-boundary problem. Host Profiles are legitimate compliance and configuration mechanisms, but once vCenter is compromised, the same mechanism can weaken host security while appearing structurally similar to normal administration. Direct SSH sessions to the ESXi hosts then originated from the vCenter appliance, a source normally trusted on the management network.

A useful detection analytic is therefore not simply “SSH enabled” or “SSH used.” It is the combination of an unexpected Host Profile remediation, a change to TSM-SSH, and a subsequent SSH connection from vCenter or another management appliance. Securelist describes this sequence as a high-fidelity detection opportunity because each individual event may be legitimate while the combination is unusual and dangerous.

Payload staging and the destructive phase

The ESXi payload was delivered through SFTP. The authentication log recorded a client identifier associated with FlowSsh, a library capable of SFTP, remote execution, interactive shells and tunneling. Securelist emphasizes that the client identifier is stronger evidence than assumptions based only on behavior.

The payload was staged in /tmp, made executable and run with a self-test option. The test lasted approximately 16 seconds and occurred around three hours before the final destructive execution. That gap created a valuable pre-impact opportunity: unexpected executable staging under /tmp, followed by execution and access to /vmfs, should receive urgent investigation.

The command used for detonation targeted the VMFS root and included options associated with recursive processing, wiping, detaching from the terminal and operating across system files. Securelist assessed that the forward-slash command style and selected switches resembled publicly documented BlackNevas and Trigona-family behavior. Because the binary was unavailable, the exact implementation of every parameter could not be independently confirmed.

Incident artifacts indicated that approximately the first 2 KB of virtual disk files were overwritten. That can damage early disk structures, including boot and partition metadata, but it does not automatically prove that all data is unrecoverable. Recovery depends on the virtual-disk layout and on whether additional filesystem, volume or application structures were modified.

Recovery was attacked before production impact

The attackers disrupted the recovery path before the final ESXi impact. Securelist reports that antivirus protection was disabled in the backup environment, backup services were later stopped, recovery infrastructure was encrypted and administrative access was disrupted.

This sequence demonstrates why immutable storage alone is not a complete recovery strategy. An organization may possess an intact copy of its data but still be unable to restore it if the backup management server, credentials, repositories or network paths are controlled through the compromised production identity and virtualization planes.

What organizations should do now

1. Treat vCenter as a Tier 0 system. Restrict management access to dedicated networks and administrator workstations. Use separate virtualization identities, strong authentication through supported federation and close monitoring of privileged sessions.
2. Eliminate unnecessary credential reuse. Do not use ordinary domain or workstation administrator accounts for ESXi and vCenter administration. Review AD group mappings, especially where domain groups can obtain ESXi privileges.
3. Monitor configuration changes as sequences. Alert on unexpected Host Profile remediation affecting TSM-SSH, ESXi Shell, acceptance levels or execInstalledOnly, particularly when followed by remote access or unusual vCenter-to-host activity.
4. Keep SSH exceptional. Detect unauthorized enablement of ESXi SSH and investigate newly created services, unfamiliar agents, VMware-looking systemd units and binaries placed in unexpected directories.
5. Centralize evidence outside the virtualization domain. Preserve ESXi authentication and shell logs, vpxa.log, vobd.log, hostd.log, vmkernel.log, vmksummary.log, Host Profile traces, vCenter tasks and VCSA authentication data on independent logging infrastructure.
6. Protect backup administration separately. Use independent identities, minimize domain dependencies, isolate repositories and management interfaces, and test restoration while assuming that production AD and vCenter are unavailable.
7. Hunt for impact precursors. Look for rapid power-off or world-kill activity across many VMs, an abrupt drop in running VM counts, unexpected SFTP staging, executable changes in /tmp and access to VMFS storage.

Conclusion

The Securelist investigation shows that hypervisor ransomware is fundamentally an identity, management-plane and recovery-design problem. Attackers did not need a guest escape in this incident. They used valid access, legitimate VMware administration features, alternate persistence and native host capabilities to move from a compromised management appliance toward broad operational impact.

Defensive priorities should follow the same architecture: isolate and harden vCenter, separate administrative identities, narrow direct ESXi access, detect risky configuration sequences, preserve logs outside the affected platform and ensure that recovery authority cannot be destroyed through production credentials.

Sources

• Securelist: ESXi ransomware—why it is dangerous and how to defend against it