Ransomware Comes for VMware: Why Attackers Go After the Hypervisor

When I think of ransomware, I think of databases, file servers, and client machines, the places that store lots of data. So I wasn't surprised to read that attackers hit VM servers, but I hadn't really thought of them as a normal target. Then I read this write-up on ESXi ransomware, and it makes sense. Locking up the hosts that hold the virtual disks for potentially thousands of employees is a pretty reasonable goal for a threat actor.

It's also not hard to find targets. The article notes roughly 8,000 ESXi hosts exposed directly to the internet, according to Shodan. (Shodan is an interesting topic all by itself.)

How the VMware stack is laid out

Generally, you've got a vSphere/vCenter server at the top controlling many ESXi host servers, which run the virtual machines your users actually work in. Most ransomware aimed at ESXi goes after vCenter, and for a good reason. vCenter is the central management point for the hosts, and the article points out that its default service account (vpxuser) has root permissions on the hosts it manages. Compromise one server and you can reach all of them.

What gets encrypted

Once they're in, the ransomware goes after the files that make virtual machines work:

• Virtual disks (.vmdk): where the VM's data lives, so encrypting them makes the VM unusable.
• Memory/paging files (.vmem): encrypting these causes data loss.
• Swap files (.vswp): encrypting these can crash the VM.
• Snapshots (.vmsn): these get targeted so you can't just roll back to a clean copy.

That last one is the part I'd highlight. Obviously, attackers want to lock up critical data. But they also want to take away your easy way out, which is why a snapshot on the same host is not a backup.

How the encryption works

The most interesting part of the article, to me, was the encryption method. Ransomware commonly uses hybrid encryption. Symmetric encryption can encrypt big volumes of data much faster than asymmetric, so the attackers use something like AES (or Chacha20) to encrypt the files with a key. Then they use RSA to encrypt that key. The attacker holds the matching RSA private key, so only they can unlock the file key. If a ransom is paid, they hand over a decryptor that uses their private key to recover the file keys, which then decrypt the files. (That's the reason "just guess the key" isn't an option for the victim.)

Two real campaigns

This isn't hypothetical. Two examples:

• ESXiArgs (February 2023). Attackers exploited CVE-2021-21974, a heap overflow in ESXi's OpenSLP service that allows remote code execution without authentication. VMware had patched it in February 2021, about two years earlier. The campaign hit more than 3,800 servers, according to CISA, and it went after unpatched hosts exposed on port 427. It encrypted configuration files so the VMs wouldn't start, and CISA eventually released a recovery script.
• CVE-2024-37085 (2024). Microsoft reported that ransomware operators, including groups it tracks as Storm-0506 and Octo Tempest, were using a flaw in domain-joined ESXi hosts to get full administrative control. ESXi automatically gave admin rights to members of an Active Directory group named "ESX Admins," even if that group didn't exist, so an attacker just had to create it and add an account they controlled. The ransomware deployed in these attacks included Akira and Black Basta.

The first was an old, patched bug. The second was a design assumption nobody thought to question. Neither required anything fancy.

What helps

The article's mitigations are pretty practical:

1. Update vCenter (VCSA) to the latest versions.
2. Use multi-factor authentication and remove default accounts.
3. Deploy EDR/XDR tooling that can spot suspicious activity on the hosts and the management plane.
4. Segment the network to limit lateral movement.

I'd add two more. Don't expose ESXi management interfaces to the internet, because that's what put thousands of servers in ESXiArgs' path. And keep backups somewhere the hypervisor's admin credentials can't reach, such as offline or immutable storage.

Takeaway

If you work in an environment that uses VMware, this is something to take seriously. The hypervisor is a single point of failure for everything that runs on it, so it deserves the same protection as your most critical server, and probably more.