Ransomware-Encrypted Veeam VBK Recovery: Akira, LockBit and Others

Veeam backups are supposed to be the thing that saves you from ransomware — which is exactly why attackers go after them. When a VBK file is found encrypted, it is tempting to write the backup off entirely. Sometimes that is correct; sometimes it is not. As with large databases, big backup files are often only partially encrypted, and whether a VBK can be recovered comes down less to which ransomware family hit it than to the backup's size and whether its internal metadata survived.

A VBK is a full backup — it holds the backed-up VM data as blocks, plus metadata that describes how those blocks map back to each virtual disk. Ransomware that uses intermittent or partial encryption to work quickly will often encrypt only the first portion of a large VBK and scattered regions after that, leaving most of the stored data blocks untouched. On a multi-hundred-gigabyte backup, that can mean the bulk of the backed-up data is still physically present in the file.

This is where VBK recovery differs from database recovery. A backup file is only useful if you can map its stored blocks back into the original virtual disks — and that mapping lives in the backup's metadata. If the encrypted region at the start of the file covers that metadata, you can be left with intact data blocks and no index telling you what they belong to.

On small backups the problem is worse: the metadata and data sit close together near the start of the file, so head encryption that a large backup would shrug off can take out everything that makes a small backup recoverable. In practice, a large VBK whose metadata survived is far more recoverable than a small one whose head was encrypted.

Where enough of the file survives, recovery means reconstructing the backup's structure from what remains — rebuilding or inferring the block mapping, extracting the virtual disks (VMDKs) from the surviving blocks, and then recovering the files, databases or VMs inside them. It is painstaking, file-by-file work done directly against the damaged VBK, not a restore through Veeam, which will refuse to open an encrypted or structurally damaged backup.

A real example from our lab: a 43 GB Veeam full backup encrypted by Akira and renamed .vbk.akira. The header, both snapshot slots and the first metadata banks were encrypted, so Veeam could not open it. Copies of the metadata tables had survived about 42 GB into the file; from them, and from the NTFS file table inside the disk, AS VBK Recovery Studio rebuilt the server's 466 GB virtual disk. 140,143 of 142,624 data blocks were verified intact, Windows mounted the data volume as healthy, and 354 of 412 sampled files opened correctly in independent reader software.

Most current ransomware groups try to destroy or encrypt the backups before they encrypt the servers, so a Veeam repository is often hit in the same night. The family matters less for VBK recovery than how it encrypted each file: whether it encrypted the whole file, only the start, or stripes through it. That is measured on the file itself, and the free edition of AS VBK Recovery Studio shows it before any decision.

What each family is known to do, and what is recoverable after it:

As with any ransomware case, this is not decryption. The encrypted regions of the file stay unreadable; what is recovered is the data the ransomware did not reach, rebuilt into usable form. For a large backup with surviving metadata that can be most of the protected data; for a small or heavily encrypted one it can be nothing. Only an examination of the actual VBK can tell which.

Keep the encrypted VBK, VIB and metadata files exactly as they are — they are the only raw material for recovery, and 'cleaning up' the repository can remove the one copy worth working from. Do not overwrite the repository with new backup jobs.

Check whether any older restore points, offsite copies or a VBK on separate media escaped the attack, since an unencrypted copy anywhere is always the fastest route back. If not, have the encrypted backup assessed before deciding anything — the file itself reveals how much survived.