Ransomware Moved Up the Stack: Hypervisors Went From 3% to 25% of Cases
There's a number from Huntress that deserves more attention than it has had. Across the malicious encryption incidents Huntress worked during 2025, the share involving the hypervisor rose from 3% in the first half of the year to 25% in the second, with the Akira group driving most of the increase. 1
That's an eightfold increase in the share of cases reaching the virtualisation layer, inside a single year. It's one vendor's telemetry rather than a census of the whole ecosystem, but the direction is hard to miss.
Pure economics
Encrypting a guest VM gets you one victim's data and requires you to defeat one victim's security. Compromising the hypervisor gives attackers a path to every guest on the box at once, and the guests' own security, their EDR, their guest firewall, their careful patching, is irrelevant because you're working underneath all of it.
Virtual machine storage is also a concentrated target. Whether the disks are qcow2 files, LVM volumes, a VMFS datastore or Ceph images, many customers' data tends to sit in one place under one administrative control plane. From the host, compromising fifty customers isn't fifty separate compromises.
Hypervisor management planes are too often treated as plumbing rather than as a crown-jewel target, with flat management networks, shared administrative credentials, unhurried patching, and monitoring aimed at the guests rather than the host.
The compounding failure is backups
We wrote in April about the support desk compromise behind this. A session hijacking attack gave an unauthorised party access to Virtualizor's support system, where roughly 1,500 old tickets, some more than a year old, contained plaintext root credentials that customers had pasted into tickets while requesting support. Virtualizor was explicit that its software itself wasn't the vulnerability, and that the servers which were compromised were those whose passwords had never been rotated and whose admin panels and SSH weren't firewalled. 2 Downstream of that, reports emerged of ransomware attacks affecting multiple hosting providers, with customer data loss reported. 3
The pattern in these incidents is consistent, and it isn't really about the encryption.
The provider had backups. The backups were reachable from the compromised environment, with credentials that the compromise also yielded. Backups inside the same trust boundary fail with it, and that, rather than the encryption, is where permanent loss comes from.
A backup that shares credentials, network trust or an administrative boundary with production may fail at exactly the moment you need it. It's a second copy in the same blast radius.
Five controls that hold up
Off-provider copies matter most, and they're what most people skip. Not another volume, another region, or another product from the same vendor, but a different provider entirely, with credentials that exist nowhere in your production environment.
Separate production from backup authority. The direction of the transfer matters less than the permission model: production should not be able to destroy history. Having the backup system reach in and pull, with production holding no credentials at all, is the cleanest way to arrange that. An account that can write but never delete gets you the same property where a push model is unavoidable. What fails is the arrangement where the credentials sitting on your production machine can also empty the backup store, because ransomware on that machine inherits them.
Immutability, meaning object-lock or append-only storage, so an attacker with valid credentials still can't delete history.
Restore drills, because an untested backup is a hypothesis. Restore something real, on a schedule, and time it.
Encryption before it leaves, so a compromised backup provider is an availability problem rather than a disclosure one.
KVM, and one point against our own interest
Two things are worth stating plainly, because they're structural rather than promises.
We run full KVM virtualisation rather than shared containers. Isolation between customers rests on hardware-assisted virtualisation and the hypervisor boundary, not on namespaces or a control panel's permission model. That isn't immunity: a compromised host is a compromised host on any platform. But the isolation boundary between you and the customer next door is enforced at the virtualisation layer rather than through a shared guest kernel. There is no shared kernel for a local privilege escalation to cross.
You also get virtual console access through the client area. Every VPS and VDS currently in our catalogue has noVNC console access, so during a recovery you're not dependent on SSH working, on the network being sane, or on sending anyone a credential.
And here's the part that runs against our own commercial interest: don't keep your only backup with us. We run four countries, and a second VPS at another of our sites, from €5/mo, can be used as a separate copy that survives a regional or jurisdictional failure. We don't sell a managed backup product, and that arrangement is one you build yourself. It also doesn't help if the failure is us. For that you need a copy at a provider whose credentials we've never seen.
Any hosting company that tells you otherwise is selling you a single point of failure with a redundancy sticker on it.
The question to ask your provider
If your hypervisor management plane were compromised tonight, what of mine survives, and how long does it take me to get it back?
You're allowed to ask. The answer, and how quickly it arrives, tells you most of what you need to know.