Hyper-V Ransomware: Encrypted VHDX Recovery

Ransomware on a Hyper-V host hits the same way it does on VMware: it encrypts the files that make up each virtual machine. And as with VMware, that rarely means the whole virtual disk is destroyed. Hyper-V's VHDX disks are usually large, and large files are what ransomware tends to encrypt only partially. What can be recovered depends on how the disk was encrypted and which parts of it were hit.

A Hyper-V VM is a set of files: the .vhdx (or older .vhd) virtual disks, any .avhdx checkpoint files, the .vmcx configuration and the .vmrs runtime state. The small configuration and state files are usually encrypted completely. The large virtual disks are where partial encryption happens — to finish quickly, many families encrypt a portion of each big .vhdx and skip the rest, leaving much of the disk's data in place.

A VHDX is a structured container: a header area and a block allocation table (BAT) near the start of the file map logical disk blocks to where they physically sit, and the bulk of the file is the data blocks themselves. Inside those blocks is the guest's own filesystem — usually NTFS — holding its files, databases and applications.

Partial encryption that touches only part of the file leaves large regions of the guest filesystem intact, and recovery works by reading those surviving regions directly and reconstructing the guest filesystem from them — not by starting the VM, which will not boot from a damaged disk.

The encryption pattern, the disk's size, and which structures were hit. Two Hyper-V specifics matter: if the encrypted region at the start covers the VHDX header and BAT, the block map has to be rebuilt before the data makes sense; and if the VM was running on a checkpoint, its recent data lives in an .avhdx differencing file on top of the base .vhdx, so recovery may need to work across the checkpoint chain.

As always, a large disk encrypted sparsely can come back almost whole, while a small VM — or one hit by full encryption — can be lost.

The first megabyte of every VHDX is its header section: a file identifier, two copies of the header (at 64 KB and 128 KB) and two copies of the region table (at 192 KB and 256 KB), which points to the block allocation table (BAT) and the metadata. Ransomware that encrypts only the first megabyte of each file therefore destroys both copies at once, and Hyper-V can no longer open the disk, even though almost all of the data is still there.

What happens next depends on the type of disk. In a fixed VHDX the guest disk is stored in order after the header area, so the guest's partitions and NTFS file system can be read directly from the surviving part, just like a VMware -flat.vmdk. In a dynamic or differencing VHDX the data blocks (usually 32 MB each) are stored in the order they were first written, and the BAT says where each one belongs. If the BAT survived further into the file, the disk can be rebuilt from it; if it was encrypted too, the blocks have to be placed by their content, using the guest file system's own structures.

We tested the fixed-disk case on a real 598 GB server disk with its first 64 MB destroyed, the way head-encrypting ransomware leaves it: 843,904 of its 844,121 files were recovered with their names and folders, from the backup partition table, the backup boot sectors and the mirror copy of the NTFS file table. The test was run on a VMware flat disk; a fixed VHDX holds the guest disk the same way.

When the Hyper-V host and the backups were encrypted together, 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, and delivered it as a VHDX file: Windows mounted the data volume as healthy, and 140,143 of 142,624 data blocks were verified intact. Placing blocks by their content when the block map is lost is the same method a dynamic VHDX needs.

Most current ransomware groups encrypt Windows servers first, and a Hyper-V host is a Windows server: the same encryptor that hits the file server hits the VHDX files. How each family encrypts large files differs, and that is measured on the encrypted disk before anything else. Our guides to individual families:

The encrypted regions stay unreadable; this is not decryption. What is recovered is the data the ransomware did not reach, rebuilt into usable files. For a large, lightly encrypted VHDX that is often most of the VM; for a small or heavily encrypted one it can be very little. Only examining the actual .vhdx and .avhdx files shows which.

Preserve every VM file — the .vhdx, .avhdx, .vmcx and .vmrs are all raw material for recovery, and deleting checkpoints or re-creating the VM can remove what recovery needs. Do not merge or delete checkpoints, and do not reinitialise the storage. Power the host down to stop further encryption.

Check for anything untouched — a replica, a backup, or a VHDX on separate storage — and if nothing clean survives, have the encrypted disks assessed before deciding anything.