Misconfigurations Enabled Ransomware Attacks on ESXi and Proxmox
Summary
Kaspersky GERT details two ransomware investigations: reused ESXi root credentials accessible through monitoring, and Proxmox credentials stored in plain-text notes. The cases show how privileged access enabled encryption without a VM escape.
Key points
- Kaspersky GERT investigated ransomware incidents affecting ESXi and Proxmox environments.
- In the ESXi case, broad monitoring access and a reused root password enabled SSH access to multiple hosts; the attacker disabled execInstalledOnly, ran ransomware, and cleared logs.
- In the Proxmox case, credentials in plain-text notes on a compromised administrator workstation enabled root access and use of a VNC websocket to run ransomware across the cluster.
- The article says neither incident required a VM escape; exposed administrative paths and privileged credentials enabled access to the virtualization layer.
- Recommended defenses include dedicated least-privilege monitoring identities, unique vaulted credentials, restricted SSH access, network segmentation, and alerts for security-setting changes.
- The article also discusses risks from VM and container escapes, compromised images, management APIs, and weak network, storage, and backup controls.
Article Details
- Attack Vectors
- In the ESXi incident, access to a monitoring environment exposed a reusable root credential; the attacker used it to connect to multiple ESXi hosts over SSH.
- On ESXi, the attacker disabled the execInstalledOnly restriction, then executed the uploaded encryption binary and deleted logs.
- In the Proxmox incident attributed to The Gentlemen group, an attacker found administrative credentials and access details stored in plain-text notes on a compromised administrator workstation.
- The attacker used the Proxmox root account to activate the VNC web socket, access other hosts, and download and execute ransomware across the cluster.
- Defensive Notes
- Use dedicated, least-privilege monitoring identities; do not store reusable hypervisor root credentials in monitoring systems.
- Use unique, vaulted credentials for each host, rotate exposed secrets, and protect privileged access with multifactor authentication.
- Route routine ESXi administration through vCenter; keep SSH and ESXi Shell disabled by default, restrict approved access, and alert on root logins and service activation.
- Enforce and monitor execInstalledOnly, Secure Boot, and Lockdown Mode where supported.
- Store privileged credentials in an approved password manager or privileged access management system rather than plain-text notes.
- Separate monitoring, management, backup, storage, and workload networks; restrict permitted source, destination, and services.
- Forward host, identity, management, and network logs to protected remote storage, and protect backups with separate identities and restricted management paths.
- Patch hypervisors, kernels, runtimes, and management software; use trusted image sources, controlled builds, provenance records, and signature checks.
MITRE ATT&CK
T1021.004 · SSHIn the ESXi incident, the attacker used SSH as root to connect to hosts sharing the reused password.T1021.005 · VNCThe attacker used Proxmox's VNC web socket with the root account to access other hosts.T1059.004 · Unix ShellThe ESXi attacker ran shell commands, including chmod and esxcli, to prepare and execute the encryption binary and change a system setting.T1078 · Valid AccountsThe attackers used valid root credentials to access ESXi hosts and the Proxmox environment.T1105 · Ingress Tool TransferThe attacker uploaded the file named esx to an ESXi host over an SSH session.T1486 · Data Encrypted for ImpactRansomware encrypted ESXi workloads in one incident and the Proxmox virtual environment in another.T1552.001 · Credentials In FilesIn the Proxmox incident, the attacker found administrative credentials and access details in plain-text notes on a compromised administrator workstation.T1562.001 · Disable or Modify ToolsThe attacker disabled the ESXi execInstalledOnly restriction to permit execution of the binary.
CVE
CVE-2024-21626opencontainers · runc; Red Hat · OCP-Tools-4.15-RHEL-8; +25 moreFor instance, runc CVE-2024-21626 involved leaked file descriptors that could expose the host filesystem to a malicious image or container process.CVE-2025-22224Vmware · Cloud foundation; Vmware · Esxi; +3 moreVMware CVE-2025-22224 showed this risk: an attacker with administrator rights inside a VM could execute code as the VMX process on the host, and Broadcom reported exploitation in the wild.CVE-2026-31431Linux · Linux; Red Hat · NVIDIA for RHEL 10; +95 moreCopy Fail (CVE-2026-31431) is a good example of a kernel flaw.CVE-2026-41567Vendor / Product unavailableDocker fixed archive and mount-handling flaws in CVE-2026-41567, CVE-2026-41568, and CVE-2026-42306.CVE-2026-41568Vendor / Product unavailableDocker fixed archive and mount-handling flaws in CVE-2026-41567, CVE-2026-41568, and CVE-2026-42306.CVE-2026-42306Vendor / Product unavailableDocker fixed archive and mount-handling flaws in CVE-2026-41567, CVE-2026-41568, and CVE-2026-42306.
Threat Actors
Malware
Vendors
BroadcomBroadcom, the parent company of VMware, recommends managing vSphere through vCenter, disabling SSH during normal operation, and using Lockdown Mode where suitable.KasperskyKaspersky GERT recently investigated two more ransomware cases on ESXi and Proxmox environments in which weak access controls, insufficient network separation, exposed administrative services, and poor management of
Products
Docker EngineThe fix is a kernel update; Docker Engine 29.4.3 also tightened its default security profiles to reduce exposure on hosts that had not yet been patched.ESXiKaspersky GERT recently investigated two more ransomware cases on ESXi and Proxmox environments in which weak access controls, insufficient network separation, exposed administrative services, and poor management ofPortainerA stolen vCenter identity, exposed Docker API, overpowered Portainer role, or compromised backup console may give an attacker an easier route than an escape exploit.ProxmoxKaspersky GERT recently investigated two more ransomware cases on ESXi and Proxmox environments in which weak access controls, insufficient network separation, exposed administrative services, and poor management ofPRTG Network MonitorThe environment also used PRTG Network Monitor to monitor its virtual infrastructure.VMware vCenter ServerDirect SSH access allowed the actor to authenticate as root, upload a binary, and change a security setting without first passing through vCenter role controls.
Tools
AnyDeskUserAssist artifacts recorded execution of the AnyDesk RMM tool and GMER binaries.esxcliThe threat actor gained root access to the ESXi environment and used the esxcli command to bypass the system restriction by disabling the execInstalledOnly policy to execute the encryption binary and also performGMERUserAssist artifacts recorded execution of the AnyDesk RMM tool and GMER binaries.