From firewall to hypervisor: how one edge bug becomes an all-VMs-down day
A single internet-facing firewall bug can end with every virtual machine encrypted at once. Here is the perimeter-to-hypervisor path and the containment that actually stops it.
Modern ransomware affiliates do not start with a phishing email and a single laptop. They start at the edge, and they aim for the hypervisor, because encrypting the virtualization layer takes down every virtual machine in one move. The whole estate becomes a single point of failure.
How the attack works
The entry point is an internet-facing firewall with an authentication-bypass flaw. The attacker reaches the management interface without a login, creates a rogue admin and a VPN account, and is now inside the network. From the VPN subnet they run discovery tooling against Active Directory to map domain controllers, shares, and the certificate-services web enrollment endpoint. They coerce a machine to authenticate and relay that authentication, an SMB reflection weakness, into AD CS, which mints a certificate for a Tier-0 account. That certificate is privileged Kerberos access. With it they push a Group Policy change that disables the antivirus fleet-wide, load a signed-but-vulnerable driver to kill the EDR sensor, and install a legitimate DFIR agent as covert command and control. They copy more than a gigabyte of file-share data out for extortion leverage, then log into vCenter with the minted identity, enable SSH on the ESXi hosts, and run an encryptor that powers off and encrypts every VM. In ATT&CK terms the chain runs T1190 to T1557.001 to T1649 to T1484.001 and ends at T1486.
Why it works
The path exists because trust flows unchecked from the edge to the core. The firewall is exposed and unpatched. The certificate authority accepts a relayed authentication because web enrollment does not require channel binding or signing. And the hypervisor management plane is reachable from a compromised domain identity, so one Tier-0 credential is all it takes to reach every VM at once.
How to fix it
The non-obvious truth this scenario teaches: in a virtualized estate the hypervisor is the crown jewel, so contain toward the vCenter and ESXi management plane first. Isolate that network, disable the Tier-0 identity, and revoke the issued certificate, because disabling an account does not invalidate a certificate it already holds. Then patch the firewall and remove its rogue accounts, enforce Extended Protection for Authentication on certificate web enrollment so coerced authentication cannot be relayed, strip the vulnerable driver and the covert agent, and treat the CA and krbtgt as compromised: revoke the window’s certificates, rotate krbtgt twice, and reset Tier-0 secrets. On recovery, restore the trust core, the domain controllers, the CA, and vCenter, before you restore VM availability.
Practice it
We built this perimeter-to-hypervisor incident as a GraphLattice Range scenario so responders can rehearse the call that matters, protecting the hypervisor management plane, before the encryptor ever runs.