BlackNevas and The Gentlemen ransomware hit ESXi and Proxmox through reused root credentials and an overprivileged PRTG monitoring server

Linha do tempo

1. securelist.com ↗ · pub. 06/11/2026 07:00 · coletado 06/11 08:00 primeiro registro

   BlackNevas and The Gentlemen ransomware hit ESXi and Proxmox through reused root credentials and an overprivileged PRTG monitoring server

   ler a análise desta fonte ocultar

   Kaspersky GERT investigated two ransomware incidents in virtualized environments. Both were enabled by misconfiguration, not by a VM escape or a hypervisor vulnerability. In Case 1, the investigation began with BlackNevas ransomware activity on a Windows system. The environment's PRTG Network Monitor server had broad access to VMware ESXi hosts and the same root password was reused across several nodes. The attacker then used that ESXi credential to reach the hosts over SSH. In Case 2, The Gentlemen group found plaintext root credentials in notes on a compromised administrator workstation. They used them to log in to Proxmox, and the entire virtual environment was encrypted.

   Technical Details

   • Case 1 (BlackNevas): The investigation began with BlackNevas ransomware activity on a Windows system in a virtualized domain controller segment. UserAssist artifacts showed execution of AnyDesk and GMER. The article states that, after obtaining access to the monitoring environment, the attacker used the ESXi credential to connect over SSH to the hosts sharing the same password. The attacker gained root on ESXi and used esxcli to disable the execInstalledOnly policy, which had blocked the initial execution attempt, so that the encryption binary could run. The attacker also deleted logs. The article presents these steps as one case and does not name the ransomware binary run on ESXi.
   • Case 2 (The Gentlemen): The actor found administrative credentials and access details in plaintext notes on a compromised administrator workstation and used the root account to log in to Proxmox. It enabled the VNC web socket through that account, and logs show root accessing other hosts through it. The actor then downloaded and executed ransomware, which encrypted the entire virtual environment.
   • Contributing factors: The report lists an overprivileged monitoring identity, a reused root password and direct SSH to ESXi that bypassed vCenter role controls. It also lists weak or missing hardening (Secure Boot/TPM enforcement of execInstalledOnly, Lockdown Mode), unsafe storage of credentials in notes, and broad management-network reachability.
   • Other threats (background only): The article also covers VM escape, container escape, poisoned images, management API abuse and backup targeting.

   Remediation

   • Give monitoring tools a dedicated least-privilege identity. Never use ESXi root for polling.
   • Replace static root passwords with vaulted or brokered credentials, use unique credentials per host, and rotate them after any suspected compromise.
   • Administer ESXi through vCenter. Keep SSH and ESXi Shell off by default and enable Lockdown Mode.
   • Enforce execInstalledOnly with UEFI Secure Boot and TPM, and alert on changes to it, to SSH, to accounts and to firewall rules.
   • Isolate management networks behind hardened jump hosts with MFA.
   • Send logs to protected storage and keep backups under separate identities, out of reach of administrators.
   • Do not keep privileged credentials in plaintext notes. Use a password manager or PAM.