LockBit 5.0 Ransomware Recovery: ESXi, NAS and Veeam Backups

LockBit 5.0 emerged in September 2025, marking the operation's resurgence following a February 2024 law enforcement takedown (Operation Cronos) that had disrupted its infrastructure and leaked details of its affiliate program. This version has also been tracked under the alias "ChuongDong," and continues the same ransomware-as-a-service, affiliate-driven model as earlier LockBit versions.

The notable technical change in this version is cross-platform payloads explicitly targeting Windows, Linux and VMware ESXi, with enhanced evasion built in — expanding beyond the largely Windows-centric focus of earlier LockBit variants (see our separate LockBit 3.0 / LockBit Black coverage for that generation's specifics, including its documented Veeam credential extraction).

Because this version explicitly adds ESXi to its target list, an incident attributed to LockBit 5.0 needs the same datastore- and VMDK-level assessment as any ESXi-targeting ransomware — checking whether virtual disks were fully or only partially encrypted before assuming a guest VM is a total loss. As with earlier LockBit generations, backup infrastructure and credentials should be assessed independently rather than assumed safe just because the ransom note only references production systems.

A pattern seen in LockBit 5.0 incidents: the ESXi host is encrypted — its datastore and the virtual machines' VMDK files — and so are the Veeam backups, because the backup repository was a NAS (QNAP, Synology or similar) reachable as a network share from the same network. Incrementals (.vib), the monthly full backups (.vbk) and the chain metadata (.vbm) are all hit in the same run.

That removes both the production systems and the usual way back. What remains are encrypted files — and for large files like VMDKs and VBKs, encrypted rarely means encrypted completely.

A Veeam .vbk keeps everything that describes its contents near the start of the file: the file header, two snapshot slots (a second copy of the metadata, kept for safety), and the metadata tables behind them — the directory of virtual machines and disks, and the block store that maps each disk block to its place in the file. In smaller backups we found all of this inside the first 512 KB.

Ransomware that encrypts the start of each file therefore destroys the header, both snapshot slots and the root of the metadata together — the backup copy of the metadata is lost with the original. Veeam cannot open the file, even when more than 90% of the actual backed-up data is still there, untouched, further along.

The data blocks themselves survive wherever the encryption did not reach, and each compressed block carries its own checksum, so a full scan of the file can find and verify every intact block without the metadata. In a full backup the blocks are stored largely in disk order, which often allows the virtual disk — and the files inside it — to be rebuilt.

When the metadata is gone completely, missing pieces can be identified by size and content: which blocks belong to which virtual machine, and which lost files are which. Newer backups also keep further copies of their metadata deeper in the file; where those survived, as in our Akira case, the whole virtual disk can be rebuilt. Where the disk cannot be rebuilt, the files are recovered from the readable data by their own structure, without their original names.

Every file in the chain is worth checking separately. The ransomware encrypts each one on its own, so an incremental (.vib) or an older full backup may be damaged differently — or less — than the newest full backup.

Do not let Veeam rescan, repair or clean up the repository, and do not delete "broken" restore points — retention jobs can remove exactly the files that still hold recoverable data. Copy every .vbk, .vib and .vbm from the NAS to separate storage, read-only, and work on the copies. Check whether the NAS's own snapshots survived; attackers often delete them, but not always.

Keep the ransom note and a few encrypted files together with unencrypted copies of the same files if any exist. Then measure, before deciding anything: how much of each VMDK and each backup file was encrypted, and where.