Most Ontario businesses that still run their own servers do not run them on separate boxes any more. A single physical host runs the file server, the application server, the domain controller and the backup server as virtual machines, all managed by a layer called the hypervisor. It is an efficient way to buy hardware. It also means there is one machine in your environment that quietly holds everything else, and attackers have worked out that it is usually the least protected thing in the room. Field Effect, one of our security partners, published a breakdown of how ransomware groups are getting to it.
The one machine that holds all the others
The hypervisor is the software that divides a physical server's hardware among the virtual machines running on it. VMware ESXi, Microsoft Hyper-V and Proxmox are the three you are most likely to have. Whichever one you run, it sits below the operating systems your staff and applications actually touch.
That position is the problem. Your virtual machines probably have antivirus, endpoint detection, patching schedules and monitoring. The host underneath them often has none of it, because the tools you bought were built to run inside Windows, not beneath it. Field Effect's point is that hypervisors tend to be less protected than the machines they carry, which is precisely backwards given what is at stake.
If someone gets administrative access to that host, they do not need to break into your file server or your domain controller separately. They already have all of them.
Why attackers skip the virtual machines entirely
A virtual machine is, from the host's point of view, a file on a disk. On ESXi those are VMDK files; on Hyper-V they are VHDX files. An attacker on the host can encrypt, steal or delete those files directly, and every server inside them goes down at once.
This matters because it sidesteps most of what you have paid for. No malicious process ever runs inside the virtual machines, so the endpoint protection installed on them never sees anything to flag. There is no suspicious login to the file server, because nobody logged into the file server. The first sign of trouble is usually that everything stops responding at the same moment.
There is a second route as well. Some hypervisor vulnerabilities allow what is called a VM escape, where an attacker who has compromised one guest machine breaks out of it and runs code on the host. Either way, the blast radius is the whole stack rather than one server.
A moderate-severity flaw that handed over entire environments
CVE-2024-37085 is the example worth understanding, because it shows how badly a severity score can undersell a problem. It carried a CVSS rating of 6.8, which is the kind of number that gets a ticket filed for next quarter.
What it actually did was this: ESXi hosts joined to Active Directory granted full administrative rights to a domain group named "ESX Admins", and they did so by default. An attacker who already had a foothold in Active Directory could simply create a group with that name and inherit control of the hypervisor. Microsoft documented two threat actors, Storm-0506 and Octo Tempest, using it to encrypt at scale.
The same pattern shows up in the groups that hit UK retailers in 2025. Field Effect notes that DragonForce and Scattered Spider reportedly combined ESXi-focused payloads with credential abuse in those attacks, and cites reporting that damages at Marks & Spencer alone exceeded $400 million.
These products are not quiet, either. VMware disclosed five critical vulnerabilities, meaning CVSS 9.0 or higher, in its core virtualization products in 2024, and four more in 2025. In July 2026 Broadcom patched two vCenter flaws rated 9.8 — an authentication bypass and a directory traversal bug allowing arbitrary code execution — alongside an ESXi VM escape in the VMXNET3 virtual network adapter.
Running Hyper-V instead is not an answer
It is tempting to read all of this as a VMware problem and conclude that Hyper-V shops are fine. The opposite argument is closer to the truth.
Hyper-V runs on Windows Server. That means the host is a Windows machine, and ordinary ransomware families can encrypt it without anyone writing ESXi-specific tooling first. An attacker does not need specialist knowledge of virtualization to do damage; they need the same Windows credentials they were already hunting for. Field Effect points to recent incidents where Hyper-V servers were targeted for exactly this reason.
The useful takeaway is not which hypervisor to prefer. It is that the host is a separate thing from the virtual machines on it, and it needs its own patching, its own access control and its own monitoring regardless of which product you chose.
What to check in your own environment
Start with how the management interface is reachable. If vCenter, the ESXi web interface or Hyper-V management can be reached from any desktop on your network, that is the first thing to fix. Those interfaces belong on a dedicated, firewalled VLAN that only named administrative devices can reach, and they should never be exposed to the internet.
Then look at who can log in. Shared administrative accounts are common on hypervisors and should not be. Use named accounts with multi-factor authentication and least privilege, audit them regularly, and consider local non-domain accounts for management so that a compromise of Active Directory does not automatically become a compromise of the host. If you do integrate with a domain, restrict which domain accounts can reach the hypervisor at all.
Turn off what you are not using. SSH is frequently left enabled on ESXi hosts long after the engineer who needed it has gone home, and every open service is one more thing to patch and defend.
Finally, check where your backups live. A backup server running as a virtual machine on the host being encrypted is not a backup. You want copies that are offline or immutable, you want them tested, and you want DNS and at least one domain controller running somewhere other than the affected host, or your recovery stalls before it starts.
Patching the hypervisor itself deserves a place on the same schedule as your Windows updates. The July 2026 vCenter round is a reasonable illustration of why: a 9.8 is not something to leave for a convenient maintenance window three months out.
The part hardening cannot do on its own
Every mitigation above reduces the chance of someone reaching the host. None of them tell you when somebody has. Hypervisor attacks tend to succeed on a small missed detail — a port left open, an account with more rights than it needed, a patch that did not get applied — and the gap between the first access and the encryption is where an incident is either contained or lost.
That window is what monitoring is for. Watching the host itself, not just the virtual machines on it, is the difference between finding out from an alert and finding out because nothing boots on Monday morning.
