Why does ESXiArgs-style encryption leave the VM data intact?

The malware's encryption script sized its work to run fast across a whole datastore: small files were encrypted fully, while large files were only partially touched or skipped. A .vmdk descriptor is a few hundred bytes of text and gets destroyed; the -flat.vmdk holding the actual disk data is often untouched — and a descriptor can be rebuilt from scratch.

Does this recovery work for every ESXi ransomware variant?

No. It works when the flat/data extents survived. Later variants and other families encrypt larger portions of big files, and thin-provisioned or snapshot-heavy chains complicate rebuilds. Always image the datastore or work on copies first, and treat restorable backups as the primary plan — descriptor rebuilds are the fallback.

What was the initial access vector for ESXiArgs?

The February 2023 campaign targeted internet-exposed ESXi hosts, widely associated with the OpenSLP heap-overflow vulnerability CVE-2021-21974 patched two years earlier. The durable lessons: never expose ESXi management interfaces to the internet, patch hypervisors on a schedule, and disable SLP if unused.

Engineering Note

Recovering VMware VMs after an ESXiArgs-class attack

Why ESXiArgs-style ransomware often leaves VM data intact, and the vmkfstools descriptor-rebuild procedure that brings encrypted VMs back without paying.

By Pavel Glukhikh November 19, 2025 2 min read

TL;DR

ESXiArgs-class ransomware frequently encrypts only the small VM metadata files — the .vmx and the plain-text .vmdk descriptor — while leaving the multi-gigabyte -flat.vmdk data files intact. That asymmetry makes many 'encrypted' VMs recoverable: rebuild the descriptor with vmkfstools, re-register the VM, pay nobody. CISA codified the approach in its ESXiArgs-Recover script after the February 2023 campaign (advisory AA23-039A). This note records the manual procedure and the hardening that prevents the rerun.

The asymmetry that makes recovery possible

A VMware virtual disk is two files: a small plain-text descriptor (vm1.vmdk) and the large data extent (vm1-flat.vmdk). ESXiArgs-class encryptors, optimizing for speed across whole datastores, fully encrypted the small files — descriptors, .vmx, .vmxf, .nvram — while only partially touching or entirely skipping the large flat files. Encrypted metadata, intact data. I’ve rebuilt enough descriptors in lab and recovery work to treat this as a standard play: before restoring from backup or even thinking about a ransom note, check whether the flat files survived.

ls -la /vmfs/volumes/datastore1/vm1/
# vm1.vmdk.args / vm1.vmdk encrypted, tiny
# vm1-flat.vmdk — 107374182400 bytes, unencrypted extension, plausible size

First moves are incident-response basics: isolate the host from the network, image or snapshot the datastore if you can, and work on copies. The rebuild below is safe — it never writes into the flat file — but discipline in incident response is what keeps a recoverable situation recoverable.

Rebuilding the descriptor with vmkfstools

CISA’s ESXiArgs-Recover script automates this; the manual version (per VMware KB 1002511) is worth knowing anyway, because understanding what the script does is the difference between recovery and hope. Get the exact flat-file size in bytes, then create a temporary disk of identical size:

ls -l /vmfs/volumes/datastore1/vm1/vm1-flat.vmdk
# -rw------- 1 root root 107374182400 ... vm1-flat.vmdk

vmkfstools -c 107374182400 -d thin /vmfs/volumes/datastore1/vm1/temp.vmdk

That produces temp.vmdk (a fresh, valid descriptor) and temp-flat.vmdk. Delete the new flat, keep the descriptor, and point it at the surviving data:

cd /vmfs/volumes/datastore1/vm1/
rm temp-flat.vmdk
mv temp.vmdk vm1.vmdk
vi vm1.vmdk
#  - Extent line: change "temp-flat.vmdk" -> "vm1-flat.vmdk"
#  - If the original disk was thick-provisioned, delete: ddb.thinProvisioned = "1"

Check consistency, then re-register the VM (rebuild the .vmx from a backup copy or by creating a new VM that reuses the existing disk):

vmkfstools -e vm1.vmdk
vim-cmd solo/registervm /vmfs/volumes/datastore1/vm1/vm1.vmx

Repeat per disk. Snapshot chains are the hard case — delta descriptors must reference their parents correctly — which is exactly when you use CISA’s script or restore from backup instead of hand-editing.

The defensive half of the note

Recovery knowledge is not a substitute for the architecture that makes it unnecessary. The ESXiArgs campaign hit hosts that were internet-exposed and unpatched against a 2021 CVE. The durable fixes:

# Disable SLP if you don't use it (the ESXiArgs-era vector)
esxcli network firewall ruleset set --ruleset-id CIMSLP --enabled false
/etc/init.d/slpd stop
chkconfig slpd off

Plus the non-negotiables: management interfaces on an isolated network, never the internet; hypervisor patching treated with server-OS urgency; and backups that a compromised vCenter or host credential cannot reach — the core argument of ransomware-resilient architecture and backup and recovery security. The descriptor rebuild is a great trick. Needing it twice is a design failure.

Frequently asked questions

Why does ESXiArgs-style encryption leave the VM data intact?: The malware's encryption script sized its work to run fast across a whole datastore: small files were encrypted fully, while large files were only partially touched or skipped. A .vmdk descriptor is a few hundred bytes of text and gets destroyed; the -flat.vmdk holding the actual disk data is often untouched — and a descriptor can be rebuilt from scratch.
Does this recovery work for every ESXi ransomware variant?: No. It works when the flat/data extents survived. Later variants and other families encrypt larger portions of big files, and thin-provisioned or snapshot-heavy chains complicate rebuilds. Always image the datastore or work on copies first, and treat restorable backups as the primary plan — descriptor rebuilds are the fallback.
What was the initial access vector for ESXiArgs?: The February 2023 campaign targeted internet-exposed ESXi hosts, widely associated with the OpenSLP heap-overflow vulnerability CVE-2021-21974 patched two years earlier. The durable lessons: never expose ESXi management interfaces to the internet, patch hypervisors on a schedule, and disable SLP if unused.