Virtualization Misconfigurations Turn Ransomware Into a Fleet-Wide Incident

Virtualization can concentrate an organization’s most important services behind a small number of management systems. That efficiency also creates a risk multiplier: when an attacker reaches a hypervisor, cluster console, monitoring platform, storage system, or backup service, the consequences can extend well beyond one compromised endpoint.

In a report published by Securelist, Kaspersky’s Global Emergency Response Team (GERT) examines two ransomware investigations involving VMware ESXi and Proxmox environments. The cases did not depend on a demonstrated virtual-machine escape. Instead, attackers used ordinary administrative routes that had been made unusually powerful by weak credential handling, excessive permissions, direct host access, and insufficient network separation.

The central lesson is operational rather than theoretical: a patched hypervisor can still be exposed if a monitoring server stores a reusable root credential, if SSH is broadly reachable, or if an administrator’s plain-text notes provide access to a management cluster.

Two incidents, one recurring pattern

Securelist describes the first case as an ESXi intrusion associated with BlackNevas ransomware activity. The investigation began with evidence on a Windows system located in a virtualized domain-controller segment. UserAssist artifacts recorded execution of the AnyDesk remote-management tool and GMER binaries. The environment also used PRTG Network Monitor to observe its virtual infrastructure.

According to GERT’s findings, the PRTG deployment had broad access to ESXi hosts and contained, or could use, a root credential that was reused across multiple nodes. After gaining access to the monitoring environment, the attacker used that credential to connect to hosts over SSH. The monitoring relationship therefore became an administrative pathway into the virtualization layer.

On one ESXi host, the source timeline records connection attempts from a masked private address shown as 192.168[.]*[.]*. During a root SSH session, a file named esx was uploaded. An initial execution attempt was blocked by the ESXi execInstalledOnly policy. The attacker then changed that setting and executed the file. On another host, a root SSH session from a masked address shown as 172.16[.]*[.]* was followed by execution of the same file and log-clearing activity.

These details are important because they show how a security control can lose value when the same highly privileged identity can disable it. The execution restriction created an obstacle, but it did not prevent an administrator-level account from changing the configuration and continuing.

The second investigation involved ransomware activity attributed in the source to The Gentlemen group and a Proxmox environment. During the period between initial access and visible impact, the attacker searched a compromised system administrator workstation and found administrative credentials and access information stored in plain-text notes. Those details were sufficient to log in to Proxmox using the root account.

GERT reports that the attacker then activated the Proxmox VNC WebSocket through the compromised root account. The available logs show repeated requests to the Proxmox API endpoint for VNC WebSocket access across nodes. Securelist says this access was used to download and execute ransomware in the cluster, resulting in encryption of the virtual environment.

The source does not establish that either case involved a VM escape. In both investigations, the decisive route was valid access to administrative functionality. That distinction should shape incident response: defenders must investigate the management plane, identity systems, monitoring infrastructure, and administrator workstations—not only guest operating systems.

Why the blast radius became so large

Monitoring became administration

Monitoring systems often need access to collect health and performance data, but Securelist emphasizes that this access should not make the monitoring platform an indirect administrator of the infrastructure it observes. In the ESXi case, the monitoring server was connected to privileged credentials and had a network path to the hosts. A compromise of that server could therefore be converted into control of multiple hypervisors.

For MSPs and internal infrastructure teams, this is a useful architectural test: if an attacker compromises the monitoring server, can that person start an interactive administrative session, retrieve host credentials, or reach management services directly? If the answer is yes, monitoring belongs inside the management threat model.

Credential reuse multiplied one compromise

The reused ESXi root password allowed access to more than one host. Password complexity alone would not have addressed this failure. The more important controls are unique credentials, centralized identity management, limited privilege, controlled secret retrieval, and rapid rotation after suspected exposure.

The Proxmox case illustrates a different form of the same problem. Plain-text notes on an administrator workstation converted endpoint compromise into cluster access. The source recommends approved password-management or privileged-access-management systems, multifactor authentication, and immediate credential rotation when an administrative workstation may have been compromised.

Direct root access bypassed safer workflows

Direct SSH access to ESXi allowed the actor to authenticate as root, upload a file, change a security setting, execute it, and remove evidence. Securelist cites Broadcom guidance favoring management through vCenter, stopping SSH and the ESXi Shell during normal operation, and using Lockdown Mode where appropriate. Any operational exception should be narrowly defined, time-limited, monitored, and tested against backup and recovery dependencies.

Configuration changes were part of the attack

The ESXi timeline shows that the attacker did not merely run a payload. The actor also changed execInstalledOnly and performed log-clearing activity. This means configuration state and logging behavior should be treated as security telemetry. Alerts should cover changes to execution controls, Secure Boot enforcement, Lockdown Mode, SSH status, local accounts, firewall rules, remote logging, and permitted exception users.

The broader virtualization attack surface

Securelist places these incidents within a larger connected stack that includes hypervisors, container runtimes, management consoles, APIs, virtual switches, datastores, images, registries, automation accounts, and backups. Each layer can provide a route to broader impact.

Virtual-machine escapes remain a distinct risk. The report cites CVE-2025-22224 as an example in which an attacker with administrator rights inside a VM could execute code as the VMX process on the host; Broadcom reportedly observed exploitation in the wild. The source also discusses container-isolation risks, including Linux kernel and runtime weaknesses and unsafe settings such as privileged mode, excessive capabilities, writable host mounts, or access to the Docker socket.

Among the container-related issues named by Securelist are CVE-2026-31431, described as a Linux kernel flaw affecting shared page-cache behavior; CVE-2024-21626, involving runc and leaked file descriptors; and Docker-related issues CVE-2026-41567, CVE-2026-41568, and CVE-2026-42306. The report also references a Portainer advisory, GHSA-7fw3-x4r2-g7wc, concerning an authorization-validation gap involving equivalent API representations.

These examples are not presented as the cause of the two ransomware cases. They illustrate why virtualization defense must address both administrative access and software vulnerabilities. Images and templates introduce another propagation risk: a compromised base image, stale template, mutable tag, or exposed build token can spread unwanted content through normal deployment automation.

Virtual networks, storage, snapshots, and backups require separate attention. East-west traffic may remain inside a host and avoid physical network sensors. Snapshot and memory files can contain sensitive material, while backup systems have broad access that makes them attractive targets for recovery-point deletion or further lateral movement.

Detection and investigation priorities

Organizations should collect and correlate telemetry from the hypervisor, management plane, identity provider, monitoring platforms, administrator workstations, firewalls, storage systems, backup infrastructure, and privileged-access tooling.

• Review successful and failed root or privileged logins, especially over SSH and from monitoring or general-purpose server networks.
• Alert on SSH or ESXi Shell activation, changes to Lockdown Mode, execution policies, Secure Boot settings, local accounts, and exception lists.
• Monitor monitoring platforms for credential retrieval, interactive sessions, unusual administrative API calls, and connections to hypervisor management ports.
• Investigate uploads of unexpected binaries to hosts, execution of files from unusual locations, and log-clearing or remote-logging changes.
• Review Proxmox API activity, including VNC WebSocket requests, for unexpected root use, unusual source systems, and access spanning multiple nodes.
• Search administrator workstations for plain-text credentials, scripts, connection profiles, scheduled tasks, and other recoverable secrets.
• Protect logs in remote, access-controlled storage so that a compromised administrator account cannot erase the evidence.

These are defensive monitoring priorities derived from the activity described by Securelist. The report does not provide a complete detection-rule set or claim that every listed event is malicious by itself.

What organizations should do now

1. Separate monitoring from administration. Use dedicated service identities with only the permissions required for polling. Do not use ESXi root or an equivalent emergency account for routine monitoring.
2. Find and replace stored privileged secrets. Review monitoring tools, scripts, scheduled tasks, service configurations, connection managers, and administrator notes. Use a vault, brokered identity, or limited token where supported, and record retrieval events.
3. Remove routine direct host access. Route ESXi administration through the central management plane where practical. Keep SSH and ESXi Shell stopped by default, and restrict approved exceptions by source, time, and identity.
4. Segment the management plane. Separate hypervisor, monitoring, storage, backup, migration, and cluster-management traffic from ordinary server and user networks. Use hardened jump hosts and multifactor authentication for administrative access.
5. Make configuration drift visible. Baseline security settings and alert when execution controls, Secure Boot, Lockdown Mode, SSH, firewall rules, accounts, or remote logging change.
6. Protect recovery systems. Give backup platforms separate identities and management paths, and maintain recovery copies outside the ordinary administrative reach of the virtual environment.
7. Patch and constrain guest and container layers. Apply relevant hypervisor, kernel, container-runtime, and management-platform updates. Reduce risky virtual devices, privileged container settings, unnecessary capabilities, writable host mounts, and exposed APIs.
8. Validate images and templates. Use controlled builders, provenance records, immutable references, signature verification, and planned rebuilds from trusted sources.

Conclusion

The cases examined by Securelist show that ransomware can achieve broad virtualization impact without breaking through a VM boundary. A monitoring server with excessive privilege, a reused root password, plain-text administrator notes, reachable SSH, and weak management-plane separation can be enough.

Virtualization security therefore has to combine vulnerability management with identity governance, segmentation, configuration monitoring, protected logging, and resilient backups. The first priority is to map which systems can administer the environment—and then reduce that reach until a single compromised tool or workstation cannot control the entire cluster.

Sources

• Securelist: Virtualization security: attack layers and misconfiguration impact