Skip to main content
CybersecurityHacking

Misconfigured Virtualization Environments Expose Administrative Access Risks

Server room interior with rows of racks, management console, and cables, lit by daylight from a large window.
"A monitoring server becomes privileged infrastructure when it holds credentials that can administer the systems it observes." — Kaspersky GERT

Kaspersky GERT’s recent investigations of two separate ransomware incidents show that attackers did not need a dramatic VM escape to take down entire virtual estates. In both cases — one involving evidence of BlackNevas activity and an ESXi estate monitored by PRTG, the other involving The Gentlemen and a Proxmox cluster — the adversary followed administrative routes: exposed credentials, overprivileged monitoring identities, and reachable management services.

How BlackNevas leveraged PRTG and reused ESXi root passwords

GERT’s timeline shows the intrusion began with activity on a Windows host in a virtualized domain controller segment and UserAssist artifacts recording AnyDesk RMM and GMER execution. The environment used PRTG Network Monitor; that deployment had broad access to ESXi hosts and, critically, the same root password reused across multiple nodes. After gaining access to the monitoring environment, the actor used the ESXi credential to SSH to hosts sharing the password.

On 2025-10-18 and 2025-10-19, logs show connection attempts and an SSH session as root. The attacker uploaded a file named esx, attempted execution (initially blocked by "Execution of non-installed file prevented"), changed permissions (chmod 777 esx), deactivated execInstalledOnly via

esxcli system settings advanced set -o /User/execInstalledOnly -i 0

and then executed the malware and performed anti-forensic log deletion. The same root password allowed simultaneous control of another host (172.16.*.*) where the actor ran commands such as

nohup ./esx /p /vmfs/ /depth 5 /log /wipe

The chain combined monitoring, credential storage, and direct administration into one attack path, turning the monitoring server into privileged infrastructure.

How The Gentlemen abused Proxmox notes and VNC web sockets

In the second case, GERT found that a compromised administrator workstation contained administrative credentials and access details stored in plain-text notes. Those records provided root access to Proxmox. The attacker used the root account to activate VNC web sockets across nodes; logs record repeated GET requests such as

root@pam [01/08/2026:00:28:36 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****"

That access allowed widespread control of the Proxmox cluster and the execution of ransomware that encrypted the entire virtual environment. GERT highlights this as a textbook case of how unsafe credential storage on an admin workstation expands a single endpoint compromise to the management layer.

Wider technical threats illustrated by CVEs and unsafe defaults

GERT situates these cases among a broader set of virtualization risks. VM escapes — where guest code affects the host — remain critical: Broadcom reported exploitation of CVE-2025-22224, in which an attacker with administrator rights inside a VM could execute code as the VMX process on the host. Container runtime and kernel flaws also matter: GERT cites Copy Fail (CVE-2026-31431) and runc CVE-2024-21626 as examples of attacks that can break container isolation. Docker Engine 29.4.3 tightened default security profiles, and Docker fixes for archive and mount handling include CVE-2026-41567, CVE-2026-41568, and CVE-2026-42306.

The report also notes that unsafe settings — privileged containers, writable host mounts, access to the Docker socket, or direct SSH root access on ESXi — can create compromise routes without exotic exploits. Management APIs and tools (vCenter, Portainer, backup consoles) can be an easier route than an escape if a stolen identity or authorization gap exists.

Concrete mitigations, detection priorities, and product mentions

GERT’s remediation blueprint centers on reducing the attack surface created by administrative workflows: separate monitoring identities from administrative accounts; replace stored root passwords with vault retrieval, brokered identities, or limited API tokens; route ESXi administration through vCenter and enable Lockdown Mode where suitable; keep ESXi Shell and SSH stopped by default; and isolate management networks with hardened jump hosts and multifactor authentication.

The report urges treating configuration changes as security events (alert on execInstalledOnly, Secure Boot, Lockdown Mode, SSH activation, and changes to exception users). Logs and backups should be forwarded to protected storage that an administrator cannot erase. GERT also recommends specialized security tooling and names Kaspersky Cloud Workload Security (KCWS) — composed of Kaspersky Hybrid Cloud Security (KHCS) and Kaspersky Container Security (KCS) — as a fit-for-purpose solution to secure virtualized infrastructures and to scan for misconfigurations in images, IaC, and registries.

What this means for security teams, enterprises, and policymakers

  • Security teams and IT administrators: Walk your monitoring deployment configurations, identify any place where a monitoring identity holds recoverable host credentials, and test alerts for configuration changes such as execInstalledOnly and Lockdown Mode.
  • Enterprises and procurement leaders: Require vaulted credentials, named service accounts, and documented retrieval/rotation procedures for monitoring and backup tools; verify vendor guidance for recommended defaults (for example, routing management through vCenter).
  • Policymakers and regulators: The incidents underline the need for configuration baselines, protected logging and backups, and enforcement of least-privilege practices across management planes as part of operational security guidance.

GERT’s two cases converge on a single operational lesson: a fully patched hypervisor can still be made to yield when credentials, network reachability, and monitoring privileges combine. Fixing those administrative routes — not only chasing escapes — must be the first line of defense.

Source: Kaspersky — Virtualization security: attack layers and misconfiguration impact