The attacker did not encrypt sixty servers. They encrypted the datastores holding sixty virtual machines, which took one login and a few minutes. The hypervisors were not domain members, ran no endpoint agent, and had not been patched in over a year, so nothing in the security programme touched them. CISA and the FBI have published advisories on exactly this pattern, and the reason it works is always the same.
Why virtualisation hosts fall outside the programme
Every tool assumes an operating system it can install an agent onto. Hypervisors do not accept one, so they are absent from endpoint detection, absent from patch management and frequently absent from the asset register, which was built from directory membership. Nobody decided to exclude them. The tooling simply had no way to include them, and the gap persisted because the machines were stable and never demanded attention. The result is a class of system carrying the highest impact in the estate with the least oversight applied to it. Meanwhile they became the single most consequential systems in the building.
How the attacker reached the console
The management interface was reachable from the ordinary user network, which is common in estates that grew without segmentation. The administrator account used a password that also appeared on a Windows server compromised earlier in the intrusion. There was no second factor on the console. From an authenticated session the attacker did not need an exploit: the platform’s own features allowed shutting down virtual machines and enabling shell access on the host, and from there the encryption ran against the datastore files directly.
“The detail that decided how bad this became was the backup server sitting as a virtual machine on the same cluster it was protecting. It went down with everything else in the first minute. If your recovery capability lives inside the thing you are recovering from, you do not have a recovery capability, you have an optimistic assumption.”
William Fieldhouse, Director, Aardwolf Security Ltd
What recovery actually involved
Nine days, most of it spent rebuilding hosts and restoring from an offline copy that was eleven days old because the weekly tape rotation had been reduced during a cost review. Domain controllers were rebuilt first, then file services, then the line-of-business applications in an order nobody had documented in advance. The technical work was slower than expected because the runbooks were stored on the file server that had been encrypted, which is a detail worth checking in your own environment this week.
The changes that followed
Management interfaces moved to a dedicated network reachable only from administrative workstations. Multi-factor authentication was enabled on the virtualisation console and lockdown mode turned on. Host credentials were made unique and taken out of the shared password vault used for Windows systems. Hypervisor patching became a scheduled activity with an owner. Backups moved to an appliance outside the cluster with immutable retention, and an internal infrastructure penetration test now runs annually with the virtualisation layer explicitly in scope, supported by vulnerability scanning across the estate that includes devices without agents.
Frequently asked questions about hypervisor attacks
These questions follow any incident involving virtualisation infrastructure.
Does this only affect one vendor?
No. The pattern applies to any virtualisation platform whose management interface is reachable and whose credentials are shared with the wider estate. The vendor changes and the failure mode does not.
See also: Orlando Business Law Attorney: Legal Guidance for Growing Businesses in Central Florida
How do you patch a host without downtime?
Live migration lets you evacuate a host, patch it and return workloads with no outage, which is available in most clusters that were sized with any headroom. Where there is no headroom, that is a capacity decision with a security consequence.
hypervisor-ransomware-incident-walkthrough
By
