A single root password, reused across several VMware ESXi hosts and stored where a network monitoring tool could use it, was all a ransomware operator needed to encrypt a company's virtual servers. That is one of two cases Kaspersky's Global Emergency Response Team (GERT) describes in a new report by Rauf Johari, and in neither one did the attackers need an exotic hypervisor exploit.
The second case involved The Gentlemen ransomware group and a Proxmox cluster, and it turned on something even more ordinary: an administrator's plain-text notes. Kaspersky's point is that a fully patched hypervisor can still fall to a shared password, an overprivileged monitoring account, an open SSH path or a management interface reachable from the general server network. "No VM escape was required," the team writes.
A monitoring server became the master key
The first investigation began with BlackNevas ransomware activity on a Windows system in a virtualized domain controller segment. UserAssist artifacts (Windows' record of programs a user launched) showed the AnyDesk remote access tool and GMER binaries had been run. The victim used PRTG Network Monitor to watch its virtual infrastructure, and that deployment had broad access to the ESXi hosts, which shared one root password.
After getting into the monitoring environment, the attacker used that ESXi credential to connect over SSH to the hosts that shared the password. Kaspersky notes that PRTG legitimately supports storing VMware credentials, but a monitoring server that holds credentials able to administer what it watches has become privileged infrastructure.
The host timeline, from October 2025, shows ESXi's own defenses doing their job, briefly. When root tried to run an uploaded binary named esx, the hypervisor refused with "Execution of non-installed file prevented", the execInstalledOnly policy at work. The attacker then switched it off with esxcli system settings advanced set -o /User/execInstalledOnly -i 0, ran the encryptor, and on a second host executed it with options to walk /vmfs/ and wipe logs.
Plain-text notes opened a Proxmox cluster
In the second incident, The Gentlemen used the dwell time between initial access and impact to look around. On a compromised system administrator's workstation they found Proxmox administrative credentials and access details saved in plain-text notes. Logging in as root, the actor used the Proxmox VNC web socket to reach other nodes, then downloaded and ran ransomware inside the cluster, encrypting the entire virtual environment. Kaspersky published the log lines showing repeated root@pam requests to the vncwebsocket endpoint.
Proxmox has been a target before: we covered an exploited authentication bypass that handed root to unpatched servers. This time no bug was involved at all.
Vault the root passwords and keep SSH off
Kaspersky's recommendations target exactly the routes these attackers used:
- Give monitoring platforms a dedicated identity with only the polling rights their sensors need, and never use ESXi root for routine monitoring.
- Find every stored copy of hypervisor, storage and backup credentials in monitoring tools, scripts and scheduled tasks, and replace them with vaulted secrets or limited API tokens. Give each host a unique credential.
- Administer ESXi through vCenter, enable Lockdown Mode where suitable, and keep SSH and the ESXi Shell stopped by default, as Broadcom recommends.
- Pair execInstalledOnly with UEFI Secure Boot and TPM-backed configuration protection, and alert whenever it, SSH or Lockdown Mode changes.
- Keep hypervisor, backup and monitoring traffic on an isolated management network reached through hardened jump hosts with multifactor authentication, and ship logs somewhere an intruder can't erase them.
The lesson in both cases is that patching and configuration are one job, not two. A security setting that the everyday admin credential can silently disable offers little resistance once that credential is stolen, and in a virtual environment that one credential is often the whole estate.
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.