The first attempt to run a ransomware binary on an ESXi host failed. The host recognized that the file was not installed through its approved software path and stopped it. The attacker was already logged in as root. They turned off the execution restriction and ran the file again.
That sequence appears in a November 6, 2026, report from Kaspersky’s Global Emergency Response Team (GERT). It reconstructs two older incidents, one involving BlackNevas on VMware ESXi and another involving The Gentlemen on Proxmox VE. In one case a monitoring system could reach several hosts with the same root password. In the other, a workstation held the credentials for the system that ran the virtual machines.
ESXi blocked the file, then root changed the rules
Investigators started with a Windows system in a segment containing a virtualized domain controller. Its UserAssist records showed launches of AnyDesk and GMER. That was a clue on the Windows side of the investigation. The path into ESXi ran through credentials associated with the PRTG Network Monitor deployment, which had broad access to the hosts.
On October 19, 2025, a root SSH session uploaded a file named esx. The first launch produced the error Execution of non-installed file prevented. The attacker then disabled the execInstalledOnly runtime setting and executed the encryptor. Broadcom documents that this setting blocks the execution of non-installed files when the corresponding kernel setting is off. In this case, the account running the file could also change the setting that stopped it.
A second host used the same root password. GERT found a root SSH login there on the same date, followed by execution of the encryptor and deletion of logs. The shared credential is what made a password recovered from the monitoring environment useful on multiple hosts.
Proxmox root access began in an administrator’s notes
In the second investigation, The Gentlemen found plaintext credentials and access details on a compromised administrator workstation. The notes gave the attacker what they needed to log in to Proxmox as root.
GERT published redacted log records showing root@pam making successive requests to the vncwebsocket endpoint. Those requests show the account being used to reach other nodes through the management interface. GERT says ransomware was subsequently run in the cluster and encrypted the virtual environment.
The workstation notes played a role similar to the monitoring credentials in the ESXi case. Each put administrative access to the hosts on a system outside the hypervisor. In a separate investigation involving The Gentlemen, backup repositories were another place to recover credentials.
What to check on your own hosts
- Start with the monitoring account. Check credentials inherited from PRTG groups as well as per-device settings. Give monitoring a dedicated identity with the permissions its sensors actually need. Check whether the monitoring network can reach ESXi over SSH.
- Map where root credentials can be used. Check for reuse across hosts and copies in notes, scripts, or exported configurations. After a suspected compromise, rotate exposed credentials from a trusted system and move their storage into an approved vault.
- Keep evidence outside the hosts. Forward management and host logs to protected storage. Investigate unexpected root SSH logins, changes to
execInstalledOnlyand unfamiliar Proxmox console sessions against your change records. The second ESXi host shows why local logs alone can leave gaps.
A patch inventory answers which software is current. These two cases suggest a second question worth asking during the same review. Which other systems already hold the credentials to administer your hosts?
References
- Rauf Johari, Kaspersky GERT. Virtualization security: attack layers and misconfiguration impact. Securelist, November 6, 2026.
- Broadcom. ESXi ExecInstalledOnly runtime setting. Knowledge Base, article 401376. Accessed November 8, 2026.
