Ransomware Is Going for the Floor Your Servers Stand On — and Your Backups Are Standing There Too

On July 29, 2026, Broadcom publishes a security advisory for VMware vCenter — the console that manages a company's virtual servers. Two of the bugs score 9.8 out of 10. No login required. No workaround. Patch now.

Five days later, on August 3, the first victim connects to attacker infrastructure. By August 5, an incident-response firm that later mapped the campaign has counted 343 compromised addresses on the way to 361, across 47 countries. In the intrusion they took apart, the chain does not stop at vCenter. It runs down into the ESXi hosts underneath — the software every virtual server actually lives on — creates administrator accounts there, stops the running machines, and encrypts the storage they sit on.

The same week, on August 5, a hosting provider called HostDZire confirms that several of its ESXi nodes in India, the Netherlands, and the United States have been hit. The virtual disks are encrypted beyond recovery. The provider has no working backups of its own. It rebuilds from scratch and tells customers to restore from whatever copies they kept somewhere else. Customers who kept none lose everything.

I have spent most of my career treating the virtualization layer as plumbing — reliable, boring, somebody else's problem. That assumption is now a liability. Ransomware crews stopped going room by room. They go for the floor.

So if the attack lands on the layer everything runs on, what does your backup actually have to be to survive it?

What actually happened in August#

Three things overlapped in a two-week window. Each is worth understanding on its own, because each one breaks a different assumption.

The vCenter flaw — July 29 to August 21

A quick map of the building. A virtual machine, or VM, is a server that exists as software rather than as a box you can touch. ESXi is the hypervisor — the thin layer of software installed on the physical hardware that runs those VMs, the way a floor holds up the offices on it. vCenter is the management console for all the ESXi hosts at once: think of it as the building manager's desk, with the master keys to every floor.

The July 29 advisory, VMSA-2026-0006, covered two critical vCenter vulnerabilities. One, CVE-2026-59309, let an attacker skip authentication entirely. The other, CVE-2026-59310, was a path traversal bug in vCenter's syslog service — the component that accepts log messages from other systems. A path traversal flaw means the software can be tricked into writing a file somewhere it should never write. Picture a mail slot that is supposed to drop letters into a bin, but can be angled so the letter lands in the manager's in-tray and gets treated as an instruction. In this case the "letter" landed where vCenter's scheduler would run it, as the root user, with no login recorded at all.

According to the incident report published by QUIRSO GmbH and covered by Cyber Security News on August 18, the attackers used that foothold to install a backdoor, create scheduled tasks with VMware-sounding names that kept re-enabling remote access, pull credentials from vCenter's local directory, and create their own vSphere administrator accounts. Then they went down a level: local administrator accounts on the ESXi hosts, a Babuk-derived encryptor copied over through the datastore browser, and a helper script that stopped the running VMs, encrypted the storage volumes, and removed the high-availability agent that would normally try to restart machines elsewhere. Large disk files were only partially encrypted — the first 512 megabytes — which is enough to make a VM unbootable.

The timeline is the part I want you to sit with. Advisory on a Wednesday. First victim the following Monday. Most of the eventual victims by that Wednesday. CISA, the federal cybersecurity agency, added the bug to its Known Exploited Vulnerabilities list — the catalog of flaws confirmed to be in active use — on August 18, with a federal patch deadline of August 21. Rapid7 noted that vCenter has been on that list ten times before. Nobody who runs vCenter can say this was a surprise category.

The hosting provider that lost everything — August 5

HostDZire is a budget hosting company, not a Fortune 500. I include it not because it is representative of enterprise operations but because it is the cleanest illustration I have seen of the failure mode.

Its customers' servers were VMs on HostDZire's ESXi hosts. When those hosts were encrypted, every customer VM went with them — that is what a hypervisor compromise means. The provider's own backups did not survive, because they were reachable from the same place. So the recovery plan collapsed to a single question for each customer: did you keep a copy somewhere HostDZire could not touch? Those who did rebuilt. Those who did not are gone.

I am not going to pretend a small hosting company's backup discipline tells you anything about AWS or Azure. It does not. But I have walked into plenty of server rooms at companies of a few hundred people where the backup server was a VM on the same cluster it was backing up, and the "off-site" copy was a network drive the same administrator account could reach. Structurally, those environments are HostDZire.

The pattern: not new, just refined

None of this arrived out of nowhere. In July 2025, Google's Mandiant team published the playbook of the criminal group tracked as Scattered Spider for VMware environments, and it reads like a recipe: talk a help desk into resetting a password, use that to reach Active Directory (the company's central directory of users and permissions), use that to reach vCenter, add yourself to the backup software's administrators group, delete the backup jobs, snapshots, and repositories, and only then encrypt — at the hypervisor layer, underneath the endpoint security running inside each VM.

In January 2026, Huntress published its analysis of a toolkit built to escape from inside a guest VM up into the ESXi host, chaining three vulnerabilities disclosed in 2025. The developers' folder names suggested they had built it as a zero-day more than a year before the vendor disclosed the bugs. And the way the attackers got in the door in that case? A compromised SonicWall VPN. The exotic part was the escape; the entry was ordinary.

Ransomware families now come with hypervisor-specific encryptors as standard equipment — Huntress documented Akira variants built for both ESXi and Hyper-V in late 2025, and the August campaign used a Babuk descendant. By the counts that exist, August 2026 was the busiest ransomware month on record. I am not going to print the number, because it is one research firm's tally of leak-site claims and claims are not victims. The direction is not in doubt.

The copy you would restore from is on the same floor#

Here is the structural problem, and it is the reason "we have backups" and "we have endpoint protection" are not answers to this post.

Endpoint detection and response — EDR, the software that watches each server for malicious behavior — runs inside the VM. It is a smoke detector in each office. When the fire starts in the crawlspace under the floor, the detectors upstairs report nothing until the floor gives way. Every one of the August victims could have had excellent agents on every Windows server and seen nothing, because nothing happened on the Windows servers. It happened underneath them.

Backups have the same shape of problem. A snapshot — the hypervisor's own point-in-time copy of a VM — lives on the same storage as the VM. It is a photograph of the room, kept in the room. A backup server that runs as a VM on the production cluster is a fire extinguisher stored in the building that is on fire. A backup repository that the domain administrator account can write to is exactly what the Scattered Spider playbook deletes first, and the attackers in August had domain-level credentials before they touched a single host.

The victims downstream of this are not abstract. The QUIRSO mapping put compromised vCenter servers in technology, research, education, and telecommunications environments across 47 countries. HostDZire's customers in three countries lost their data through a provider they had never audited. In both cases the people who kept a copy off the floor recovered, and the people who did not did not.

This is why multi-vendor and multi-region advice, which I have given in this space before for cloud outages, does not carry over cleanly. You can have two clusters, two data centers, and two hypervisors, and if one set of credentials manages all of them, an attacker with that set has all of them. Redundancy protects you from failure. It does not protect you from an administrator, and after August 3 the attacker was an administrator.

The attackers didn't break into the office. They took the floor, and every office on it went with it.

The part that is genuinely not urgent#

If I stopped there I would be selling you a panic, and the record does not support one.

Rapid7's advisory note is worth quoting in spirit: vCenter is usually restricted to internal or dedicated management networks, which is why 361 exposed victims is a small number against the installed base. The August campaign hit the minority who had management interfaces reachable from the internet or from a broad, flat network. If yours is not, you were not in the first wave — you are in the second-wave category, where the attacker has to get inside first, and that is the Scattered Spider path rather than the scan-and-exploit path.

Second, a lot of genuinely small companies have no hypervisor at all anymore. If your servers are cloud instances and your applications are SaaS, the ESXi part of this post is your provider's problem. The backup part still is not, and I will come back to that.

Third, I argued in June that companies should wait before applying Windows 11 updates, because Microsoft had made its customers the test group. That advice does not transfer here, and the difference is instructive. A Windows update breaks a laptop; a hypervisor exploit takes the estate. For a management-plane bug with a 9.8 score and no workaround, the window between "patch available" and "actively exploited" was five days. That is not a patch cycle. That is a fire drill.

One more honest qualifier: some of you cannot patch even if you want to. Since Broadcom ended perpetual VMware licensing, customers whose support contracts lapsed have reported being unable to download routine patches. Broadcom's stated exception is critical, 9.0-and-above fixes for vSphere 8.x — which does cover the August bugs — but if you are on ESXi 6.x or 7.x, you are past end of support, and the Huntress toolkit was built with exactly you in mind. An unpatchable hypervisor is a migration project, not a patching project, and pretending otherwise is the most expensive mistake on this page.

How This Impacts Your Organization#

The principle here does not change with company size: whatever runs your servers can be attacked directly, and the copy you would restore from has to survive that attack or it is not a backup. What changes with size is which part of that sentence you have already solved, where the leverage sits, and which overcorrection is waiting for you.

Large Enterprises (1,000+ employees)

You have a virtualization team, an identity team, and a backup team, and the August attack path walks through all three in an afternoon. Your real risk is not capability — you have immutable backup storage, privileged access management, and a management network that was segmented years ago. Your risk is that nobody owns the question "can the backup platform survive losing vCenter and the domain?" as a single question. Each team can truthfully say its piece is fine, and the estate can still be HostDZire.

Where the leverage lives is scale and process. You can get a management-plane patch SLA written into the platform team's service commitments — days for critical, not the 30-to-90 that "internal-only appliance" usually earns. You can afford a separate identity for the backup platform that the domain does not control, and a quarterly restore test that starts from the assumption that vCenter is gone. You can require the same of the hosting and colocation providers that hold pieces of your estate, in the contract.

The concrete organizational move: name one owner for hypervisor-plus-recovery resilience, and have that person run a tabletop where the injected event is "domain admin compromised, vCenter compromised, backup console reachable." The exercise will surface which of your three teams believes another team has it covered.

Mid-Size Organizations (100–999 employees)

You feel this fastest because one or two people own all three layers, and the same administrator account usually has rights to all three. That is the attack path — and it is also why you can fix it faster than the enterprise can, because there is no committee.

The overcorrection to avoid is buying a second hypervisor platform or a multi-site replication project as the answer. Replication copies the encryption too, and a second platform managed by the same credentials is not a second platform. The money is better spent on separating the backup platform from the domain and on making one copy of the backups impossible to alter for a fixed period — most backup products call this immutability, and most storage vendors and cloud providers offer it as a checkbox now.

Three moves that do not require a platform team: put vCenter and the ESXi management interfaces behind a management network that is not reachable from ordinary office devices or the general VPN; give the backup server its own local administrator account and multi-factor authentication that Active Directory does not control; and apply management-plane patches rated critical within a week, treating them as a different class from your ordinary monthly cycle.

Small & Growing Organizations (under 100 employees)

Honest counsel first: if your servers are already in the cloud and your applications are SaaS, do not stand up a hypervisor project because of this post. You are not the target of a help-desk social engineering campaign, and a single ESXi host in a closet is more exposure than you had before. The part of this post that is yours is the HostDZire part.

The provider's backup is not your backup. Whether your systems run at a small hosting company, a managed service provider, or a cloud, one copy of the data that matters has to exist somewhere the provider's own failure cannot reach — a different provider, or an offline copy you control. That is a monthly task for one person and a small storage bill, and it is the entire difference between the HostDZire customers who reopened and the ones who did not.

If you do run your own host or two, the lightweight discipline is short. Know the version. If it is out of support — ESXi 6.x, and 7.x is now past its general support date — plan to move rather than patch. Do not let the host's management page face the internet. Keep one backup copy off the host. You do not need immutability products or a management network; you need those four things, and you can check them on Monday.

What to do Monday morning#

1. Find out where your hypervisor management interfaces are reachable from. Ask whoever runs vCenter, Hyper-V, or Proxmox one question: from which networks can someone reach the management console? If the answer includes the internet, the general office network, or the all-staff VPN, that is the first fix. This is free — it is a firewall rule and an afternoon.
2. Check the version and the patch date on every host and on vCenter. Write them down. If vCenter is below 8.0 U3k (or 9.0.2.0100 / 9.1.0.0300 on the newer lines), it is exposed to the August bugs. If any ESXi host is 6.x or 7.x, it is out of support and the conversation is migration, not patching. This is free and takes an hour.
3. Trace what your backup server trusts. Is it a VM on the cluster it protects? Does the domain administrator account have rights to it? Can that account delete backup jobs or repositories? Each "yes" is one step the Scattered Spider playbook needs. The fix is a separate local account with its own multi-factor authentication, and moving the backup server off the production cluster.
4. Make one copy of your backups impossible to alter. Most backup products and most object-storage services offer a setting that locks a backup for a fixed number of days so that nobody — including an administrator — can delete or encrypt it. Turn it on for the systems that matter, with a retention window longer than your typical time to notice an intrusion.
5. Run one restore that assumes the hypervisor is gone. Not "restore a file." Pick one important VM and restore it to hardware or a cloud instance that does not depend on vCenter, the domain, or the production cluster, and time it. You will learn whether your backups are real, and you will learn your actual recovery time rather than the one on the slide.
6. Have the provider conversation. If part of your estate lives at a hosting company or managed service provider, ask them in writing: where are your backups of our systems, what can reach them, and what happens if your hypervisor is encrypted? Then make one copy that does not depend on their answer. This is a meeting, not a project.
7. Decide the management-plane patch rule. As a leadership decision, not an IT one: critical fixes to the layer everything runs on get applied within a defined number of days, and that number is measured in single digits. Write it down so the next 9.8 does not start with a debate about the maintenance window.

If you want a place to start#

If you would rather not build the checklist from scratch, the "can we restore if the layer underneath is gone?" question maps directly onto the platform-security and recovery sections of a NIST Cybersecurity Framework readiness assessment, and the NIST CSF 2.0 readiness toolkit we built at DLegendDigital walks through exactly those items in plain language. And if you want a second set of eyes on where your backups physically live relative to your hypervisor and identity systems — a one-time architecture review, not an engagement — that is the kind of short, focused work our PBF consulting does. This post is independent of those offerings; the actions above stand on their own.

The uncomfortable truth#

So what does a backup have to be to survive an attack on the layer everything runs on? It has to be somewhere that layer cannot reach, protected by credentials that layer does not control, and locked so that even the people who manage it cannot alter it for a while. Anything short of that is a copy that shares the floor with the original, and in August the floor is what they came for.

Over the next year I expect the hypervisor to be treated the way the identity provider started being treated in 2025 — as a tier-zero system with its own rules, its own credentials, and its own patch clock. I expect more of the VMware base to be sitting on unsupported versions than anyone wants to admit, and I expect the next campaign to find them.

I would rather you found them first. Pull the version list on Monday.

— Charles Redding