VMware ESXi Ransomware: Encrypted VMDK Recovery

Ransomware that reaches a VMware ESXi host can take out every virtual machine on it at once — which is why these attacks are so damaging. But 'the VMs are encrypted' rarely means every byte of every virtual disk is gone. The families that target ESXi are built for speed, and on large virtual disks that speed comes from encrypting only part of each file. Whether a VM is recoverable depends on how it was encrypted, how big the disk is, and which parts were hit.

Once an attacker has access to an ESXi host, they go after the datastore directly — the .vmx configuration, the small descriptor .vmdk, and the large -flat.vmdk files that hold the actual virtual-disk data. The small files are usually encrypted completely. The large flat files are where the shortcut happens: to finish before anyone notices, many ESXi-targeting families encrypt in a step pattern — encrypting a chunk, skipping ahead, encrypting another chunk — rather than the whole file. On a large disk, that leaves long stretches of the original data untouched.

A VMware virtual disk is two files: a tiny text descriptor and the large -flat.vmdk that is, in effect, a raw image of the guest's hard drive. Inside that flat file sits an ordinary filesystem — NTFS for a Windows VM, ext4 or XFS for Linux — with the guest's files, databases and application data.

Step-pattern encryption that touches only part of the flat file leaves much of that guest filesystem intact. Recovery works by reading the surviving regions of the flat file directly, reconstructing the guest filesystem from what remains, and pulling out the files and databases inside — not by booting the VM, which will not start from a damaged disk.

Three things: the encryption step pattern, the size of the disk, and which regions were hit. A large VMDK encrypted in a sparse step pattern can come back almost whole; a small VM can be covered end to end by the same pattern and lost.

The hardest cases are where the encrypted chunks land on the guest filesystem's own metadata — the NTFS master file table, or a database's internal structures inside the guest — because then surviving data has to be reassembled without the index that normally describes it. Damage to the VMFS datastore itself, on top of the encryption, makes it harder again.

Much ESXi ransomware encrypts the start of each -flat.vmdk, and that start holds the partition table, the boot sectors and the beginning of the guest's file system. We tested what that does to a real server disk: a 598 GB -flat.vmdk holding 844,121 files, with first its first 2 MB and then its first 64 MB replaced by random data, the way head-encrypting ransomware leaves it.

VMware could no longer boot or mount the disk, but AS VMware Recovery restored the partitions from the backup GPT and the backup boot sectors and read the NTFS file table from its mirror copy. 843,904 of the 844,121 files came back with their names and folders; what was lost was the small EFI boot partition, which lay entirely inside the destroyed region.

This is the best case. When the ransomware also encrypts stripes further into the disk, the files whose data lay in those stripes are damaged or lost, and the program reports them instead of guessing.

Often the VMs are encrypted on the datastore and in the Veeam repository on the same night. Then the backup may be the better source: in a real Akira case we rebuilt a 466 GB server disk from a 43 GB encrypted Veeam backup whose header and first metadata were destroyed, with 140,143 of 142,624 data blocks verified intact.

Most large ransomware groups now have an encryptor for ESXi hosts, and how each one encrypts a -flat.vmdk differs: some encrypt only the start, others encrypt stripes at fixed steps through the whole file. That is measured on the encrypted disk itself before anything else. Our guides to individual families:

As with any ransomware case, this is not decryption. The encrypted regions stay unreadable; what is recovered is the data between them, rebuilt into usable files. For a large, lightly stepped disk that can be most of the VM; for a small or heavily encrypted one it can be very little. Only examining the actual -flat.vmdk shows which.

Do not reinstall ESXi, re-create the datastore, or reformat anything — the encrypted VM files are the only material recovery can work from, and a fresh install can overwrite them. Power the host down to stop further encryption, but leave the datastore intact.

Check for anything that escaped: a replicated VM, a snapshot on separate storage, or a backup — if you have Veeam or similar, an untouched restore point is the fastest route back. If nothing clean survives, have the encrypted virtual disks assessed before deciding anything.