A ransomware attack on 5 August 2026 compromised multiple VMware ESXi virtualisation nodes at hosting provider HostDZire, affecting infrastructure in India, the Netherlands and the United States. Virtual disks on the impacted servers were encrypted beyond recovery.

That last phrase carries the weight. Not encrypted pending negotiation — encrypted beyond recovery. For customers whose only copy of a workload lived on those hosts, the data is gone.

Why hypervisors are the preferred target

Ransomware crews have systematically shifted toward hypervisor-level attacks over the past several years, and the reasoning is entirely rational from their side:

One action, many victims. Encrypting VMDK files on a single ESXi host takes down every virtual machine on that host at once. Ten separate guest infections require ten separate successful compromises; one hypervisor compromise achieves the same result.

No endpoint agent in the way. ESXi is a purpose-built hypervisor, not a general-purpose OS. Most EDR products cannot install on it. The attacker operates in a space where your detection stack is simply not present.

Guest backup agents are bypassed. A backup agent running inside a VM protects that VM's filesystem. When the underlying virtual disk file is encrypted at the hypervisor layer, the agent's view of the world is irrelevant — and if the backup repository is itself a VM on the same cluster, it is encrypted too.

Speed. Encrypting a few dozen large VMDK files is far faster than walking millions of individual files inside each guest. Detection windows shrink accordingly.

The typical route in is not an ESXi exploit. It is stolen vCenter credentials, an exposed management interface, or an unpatched hypervisor reachable from a compromised segment.

Hardening ESXi environments

Isolate the management network

ESXi management interfaces and vCenter should sit on a dedicated management VLAN reachable only from a jump host or privileged access workstation. They should never be internet-facing, and they should not be reachable from general user subnets. This single control eliminates the most common attack path.

Enable lockdown mode

ESXi lockdown mode restricts direct host access, forcing administration through vCenter where actions are logged and access is controlled. It is a built-in feature that costs nothing and is disabled in most environments.

Disable SSH unless actively in use

The SSH service on ESXi hosts should be off by default and enabled only for the duration of specific maintenance. Persistent SSH is one of the most common footholds in these incidents.

MFA on vCenter, always

vCenter credentials are the keys to the entire virtual estate. They warrant phishing-resistant MFA and should never be shared, never be reused, and never be stored in a general-purpose password vault that ordinary IT staff can reach.

Patch on a real schedule

ESXi patching requires migrating workloads and rebooting hosts, which makes it easy to defer. Broadcom publishes advisories regularly and hypervisor CVEs are consistently exploited. Build the maintenance window into the operational calendar rather than treating each patch as a negotiation.

Backups that survive a hypervisor compromise

This is the part that determines whether an ESXi incident is recoverable:

  • Backups must live outside the virtual environment. A backup server running as a VM on the cluster it protects offers no protection at all.
  • Immutability is required, not optional. Object lock, WORM storage or an appliance with hardened immutability, so that compromised backup credentials cannot delete history.
  • Keep an air-gapped or logically isolated copy. Offline tape or a separate cloud account with independent credentials.
  • Test full VM restore, and time it. "We have backups" is not a recovery plan. "We restored forty VMs in six hours last quarter" is.
  • Protect the backup infrastructure's own credentials with the same rigour as domain admin. Attackers target the backup system first, deliberately.

If you buy hosting

The HostDZire customers who lost data are, in most cases, organisations that assumed their provider's infrastructure resilience covered them. It generally does not. Standard hosting agreements make the customer responsible for their own data protection.

Practical questions to put to any hosting or VPS provider, in writing:

  • Do you back up customer data, and what is the retention and recovery point objective?
  • Are those backups immutable and stored outside the production virtualisation environment?
  • What is your contractual liability if data is unrecoverable?
  • Have you tested a full restore, and when?

If the answers are unsatisfactory, the fix is to maintain your own independent backup of anything you cannot afford to lose — in a separate provider, under separate credentials. That is a modest ongoing cost against a total-loss scenario.