Stolen Root Credentials Opened ESXi and Proxmox to Ransomware

A reused root password and plaintext administrator notes helped ransomware operators reach virtualization infrastructure in two investigations described by Kaspersky. The November 6 report by Rauf Johari examines how existing compromises expanded into ESXi and Proxmox environments.

In the ESXi case, investigators found that a PRTG monitoring deployment could reach multiple hosts using the same root credential. The attacker used SSH, disabled an execution restriction after an initial block, and ran the encryption binary. The published host timeline places that activity in October 2025.

In the separate Proxmox incident attributed to The Gentlemen, credentials in notes on an already-compromised administrator workstation enabled root access. Kaspersky says the attacker used a VNC websocket and subsequently downloaded and executed ransomware within the cluster, encrypting the virtual environment.

These are accounts of movement into privileged administration after an initial foothold. The report does not establish the original entry method for either organization, and neither case required a VM escape.

Access controls need their own review

Broadcom’s Lockdown Mode documentation gives administrators a way to evaluate direct host access and its exceptions. It says the exception-user list is intended for service accounts with specific tasks; adding ordinary ESXi administrators defeats the control’s purpose. Strict mode also changes recovery options: without a working vCenter connection or suitable permitted access, a host can become unavailable. Recovery access should be tested before changing the mode.

A separate Broadcom explanation of execInstalledOnly clarifies another boundary. In ESXi 7.0 through 8.x, the feature restricts unsigned binaries but does not prevent unsigned scripts executed through interpreters such as Python. Broadcom documents additional Secure Boot and enforcement settings while making clear that these do not remove the interpreter limitation.

For defenders, the resulting audit has two parts: verify which identities and network paths can administer hosts, then verify what each execution control actually enforces. A working sensor or a configured policy alone does not answer both questions.

Latest articles

Related articles