- › Encrypting a virtualization host encrypts the disk files of every virtual server on it, so a few hosts can mean the whole data center in one move.
- › Hypervisors usually run no endpoint protection, keep short local logs, and are often managed with the same domain credentials attackers steal first.
- › The common routes in are management interfaces reachable from the user network, hypervisor admin rights tied to the production domain, and hosts left unpatched because rebooting them is disruptive.
- › Isolate management on its own network, separate the admin identity from the domain, lock down the host shell, and get its logs off the box.
- › Keep backups on separate storage under separate credentials, and test restoring a whole host's worth of servers, not one file.
The calls start at about six on a Monday morning. The ERP system is down, the file shares are gone, the domain controllers are not answering, and the virtual desktops show a blank screen. Nobody can find a single server that is working, because every one of them lives on the same eight virtualization hosts, and over the weekend somebody encrypted the files those hosts use to store their virtual disks.
That is the attack this article is about. It does not need to reach two hundred servers one at a time, because it can reach the eight machines underneath them and encrypt everything those machines hold.
Why Attackers Go Straight for the Host
Virtualization concentrates risk by design. Consolidating many servers onto a few physical hosts saves money and makes administration easier, and it also means that each host holds many servers’ entire disks as a handful of large files. An attacker with administrative access to the host can stop the virtual machines and encrypt those files directly, taking every server on that host down in one move, regardless of what security software runs inside each one.
The host itself is usually a poor place to defend. Most hypervisors cannot run a conventional endpoint detection agent, so the tool your security team relies on everywhere else is absent from the machine that matters most. Logs are often kept locally and rotate quickly, and many organizations never send them anywhere central. Ransomware operations have built encryptors aimed specifically at virtualization hosts for years, because the payoff per intrusion is so large.
How They Get There
The routes in are rarely exotic. In the environments I assess, three come up again and again.
The first is a management interface that ordinary users can reach. The hypervisor’s web console and its central management server often sit on the same network as everything else, so an attacker who lands on any workstation can reach the login page. Our piece on the segmentation project you never finished covers how that happens, and virtualization management is usually the most valuable thing left on the flat part of the network.
The second is identity. Hypervisor management is frequently joined to the production directory so administrators can sign in with their normal accounts, which means anybody who compromises a domain administrator, or a group the hypervisor trusts, has the keys to every host. Attackers go after domain credentials early in nearly every intrusion, and when those credentials also open the virtualization layer, the attacker inherits it for free. We described the same pattern of quietly chained trust in identity and access management: what to fix first.
The third is patching. Updating a host means moving its virtual machines elsewhere or taking them down, so host patches get deferred longer than almost anything else in the estate. Remote shell access gets enabled for a troubleshooting session and is never turned off again. Each of those is a reasonable decision on the day it is made, and together they leave the most valuable machines the least maintained.
Why the Usual Defenses Miss It
The defenses most organizations rely on for ransomware live inside the virtual machines. Endpoint detection watches processes in each server, application control restricts what each server can run, and the security team’s dashboards show healthy agents across the estate. None of that sees an attacker who works on the host underneath, because from the host’s point of view, every one of those servers is a file.
Backups are the other common blind spot. Snapshots stored on the same datastore are encrypted along with everything else. Backup servers that run as virtual machines on the affected hosts go down with them, and backup consoles that use the same domain credentials can be logged into and wiped by the same attacker. We covered the restore side of this in the backups were fine and you still lost a week, and a host-level attack is the case that tests it hardest.
What to Do About It
None of this requires replacing your virtualization platform. It requires treating the layer underneath your servers as the most sensitive system you run, which it is.
Put management on its own network
Move the hypervisor management interfaces and the central management server onto a dedicated network that ordinary workstations and servers cannot reach at all. Administrators connect through hardened jump hosts or dedicated admin workstations, and nothing else crosses into that segment. This single change removes the most common route in.
Separate the administrative identity
Do not let ordinary production domain accounts administer the hypervisors. Use dedicated admin accounts that exist only for virtualization, protected by phishing-resistant multi-factor authentication, and if you can, manage the virtualization layer from an identity source that a compromise of the production domain does not reach. Keep a local emergency account on each host for the day the directory is down, handled the way we described in the account that skips every control.
Lock the host down
Disable remote shell access and enable it only for the duration of a specific task. Turn on the host settings that restrict management to the central server and that allow only signed, installed software to run, where your platform offers them. Remove default and unused local accounts.
Patch the hosts on a schedule
Live migration exists so that you can move virtual machines off a host, patch it, and move them back without downtime. Use it on a regular cadence, and treat a host that is months behind on patches as a finding at the same level as an unpatched internet-facing server.
Get the logs off the host
Send host and management server logs to a central store the virtualization administrators cannot alter. Alert on remote shell being enabled, new local accounts, changes to host security settings, and many virtual machines being powered off within a short window, because that last pattern is often the moment just before encryption starts.
Keep the backups out of reach
Store backups on separate storage, managed with credentials that are not in the production domain, with at least one copy that cannot be altered or deleted for a set period. Then test restoring a whole host’s worth of virtual machines at once, and time it, because that is the restore you will be doing. Our ransomware prevention framework puts these controls in the wider layered model.
The Layer Nobody Is Watching
Most security programs were built around servers and endpoints, and they watch those well. The virtualization layer arrived later, often as an infrastructure project with its own team, and in many organizations it sits outside the security program’s view entirely.
An attacker looks at the same environment and sees eight machines holding everything. Spending the next quarter making those eight machines as hard to reach and as closely watched as anything you own is one of the highest-return projects available to most mid-sized organizations.
Chris Armour is Director of Information Security at Grab The Axe.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
