ESXi VM Escape in the Wild: Analysis of Chinese Zero-Day Exploit Toolkit

708words ·4min
https://andytips.com/security/vmware-esxi-zero-day-vm-escape-2025/
Page content

Chinese-speaking hackers breached SonicWall VPN and escalated all the way to VMware ESXi hypervisor control.
The exploit toolkit was apparently in development for over a year before anyone knew these bugs existed.

Introduction

So Huntress dropped their analysis of a December 2025 intrusion and honestly it’s one of those reports that makes you sit back for a minute.
Chinese-speaking threat actors popped a SonicWall VPN and didn’t stop until they had full control of the ESXi hypervisor.
Not just a VM — the whole hypervisor.

The kicker is how long this toolkit has apparently been floating around.
We’ll get to that.

Vulnerability Info

Three ESXi zero-days that Broadcom disclosed in March 2025 look like they were chained together here.

CVE CVSS Description
CVE-2025-22224 9.3 TOCTOU flaw in VMCI leading to code execution in VMX process
CVE-2025-22225 8.2 Arbitrary write vulnerability enabling VMX sandbox escape
CVE-2025-22226 7.1 Out-of-bounds read in HGFS leaking VMX memory

A 9.3 chained with two others — not exactly a gentle combination.

Attack Walkthrough

Huntress walked through what they observed and it’s pretty textbook lateral movement until it suddenly isn’t.

1. Backup Domain Controller

They got in with stolen DA creds over RDP and started dropping the usual recon stuff:

  • Advanced Port Scanner 2.5.3869
  • SoftPerfect Network Scanner
  • ShareFinder dumping network shares to C:\ProgramData\shares.txt

Nothing fancy so far.

2. Primary Domain Controller

Here’s where they started prepping the environment.
Firewall rules to block outbound while keeping internal traffic open — classic move to slow down response while they work:

netsh advfirewall firewall add rule "name=Block External Outbound" dir=out action=block remoteip=0.0.0.0-255.255.255.255 profile=any
netsh advfirewall firewall add rule "name=Allow Local Network-2" dir=out action=allow remoteip=10.0.0.0/8 profile=any

Then WinRAR to stage data from network shares.
You know where this is going.

3. ESXi Exploit Execution

About 20 minutes after dropping the toolkit they kicked it off:

devcon.exe disable "PCI\VEN_15AD&DEV_0740"
devcon.exe disable "ROOT\VMWVMCIHOSTDEV"
kdu.exe -prv 1 -map MyDriver.sys
exploit.exe

First two commands kill the VMCI drivers so they can talk to the hardware directly.
Third one uses KDU to shove an unsigned driver into the kernel — DSE bypass that’s been around for a while now.
Fourth one runs MAESTRO and that’s when the VM escape happens.

Exploit Toolkit Components

Component Purpose
MAESTRO (exploit.exe) Orchestrates everything — disables VMCI and coordinates driver loading
MyDriver.sys The actual exploit driver. Supports 155 ESXi builds from 5.1 through 8.0 which is a lot of dev work
VSOCKpuppet Backdoor that sits on the ESXi host and talks over VSOCK port 10000
client.exe Runs inside a guest VM to control the backdoor

155 builds supported.
Someone spent serious time on this.

Threat Actor Attribution

This is where it gets interesting.
PDB paths in the binaries showed a folder dated “2024_02_19” named “全版本逃逸–交付” — translates roughly to “All version escape - delivery”.
That’s February 2024.
The vulns weren’t public until March 2025.

So either they found these independently or had access to them through other means.
Either way that’s over a year of lead time.

There was also an English README bundled with it which makes me think this might be a comercial toolkit being sold around.
The Chinese strings are why attribution points to Chinese-speaking actors but who knows who else has copies by now.

Mitigation Steps

Shadowserver data from January 8 2026 shows over 30000 internet-exposed ESXi instances still vulnurable to CVE-2025-22224.
Thirty thousand.
That’s a lot of targets sitting there.

If you’re running ESXi:

  1. Patch now — EOL versions need to be upgraded because there’s no fix coming
  2. Check your VPN appliances especially if you’re on SonicWall
  3. MFA on DA accounts and trim priviliges where you can
  4. Monitor for weird VSOCK activity on ESXi hosts (lsof -a helps)
  5. Watch for BYOD loaders like KDU showing up

IOC

Item SHA256
MAESTRO 37972a232ac6d8c402ac4531430967c1fd458b74a52d6d1990688d88956791a7
client.exe 4614346fc1ff74f057d189db45aa7dc25d6e7f3d9b68c287a409a53c86dca25e
VSOCKpuppet c3f8da7599468c11782c2332497b9e5013d98a1030034243dfed0cf072469c89
MyDriver.sys 2bc5d02774ac1778be22cace51f9e35fe7b53378f8d70143bf646b68d2c0f94c

Final Thoughts

Another reminder that VM isolation isn’t the wall people think it is.
Once you’re on the hypervisor everything running on that box is yours.

What stuck with me is the timeline.
A year of development before disclosure means there’s probably other stuff like this out there right now that we won’t hear about until it’s too late.

Anyway patch your stuff and go check your VPN configs.

References