VMware ESX / vCenter Pentesting
Enumeration
nmap -sV --script "http-vmware-path-vuln or vmware-version" -p <PORT> <IP>
msf> use auxiliary/scanner/vmware/esx_fingerprint
msf> use auxiliary/scanner/http/ms15_034_http_sys_memory_dumpBruteforce
msf> auxiliary/scanner/vmware/vmware_http_loginIf you find valid credentials, you can use more metasploit scanner modules to obtain information.
ESXi Post-Exploitation & Ransomware Operations
Attack Workflow inside Virtual Estates
- Develop: maintain a lightweight management agent (e.g., MrAgent), encryptor (e.g., Mario), and leak infrastructure.
- Infiltrate: compromise vSphere management, enumerate hosts, steal data, and stage payloads.
- Deploy: push agents to each ESXi host, let them poll C2, and pull the encryptor when instructed.
- Extort: leak proof-of-compromise data and run ransom chats once encryption is confirmed.[1]
Hypervisor Takeover Primitives
Once command execution on an ESXi console/SSH session is obtained, attackers typically run the following management commands to fingerprint and isolate the host before ransomware deployment:
uname -a # hostname / build metadata for tracking
esxcli --formatter=csv network nic list # adapter + MAC inventory
esxcli --formatter=csv network ip interface ipv4 get
esxcli network firewall set --enabled false
/etc/init.d/vpxa stop # cut vCenter off from the host
passwd root # rotate credentials under attacker controlThe same agent usually keeps a persistent loop that polls a hard-coded C2 URI. Any unreachable status triggers retries, meaning the beacon stays live until operators push instructions.[1]
MrAgent-Style Instruction Channel
Lightweight management agents expose a concise instruction set parsed from the C2 queue. That set is enough to operate dozens of compromised hypervisors without interactive shells:
| Instruction | Effect |
|---|---|
Config | Overwrite the local JSON config that defines target directories, execution delays or throttling, enabling hot re-tasking without redeploying binaries. |
Info | Return hypervisor build info, IPs and adapter metadata gathered with the uname/esxcli probes. |
Exec | Kick off the ransomware phase: change root credentials, stop vpxa, optionally schedule a reboot delay and then pull+execute the encryptor. |
Run | Implement a remote shell by writing arbitrary C2-provided commands to ./shmv, chmod +x and execute it. |
Remove | Issue rm -rf <path> for tool clean-up or destructive wiping. |
Abort / Abort_f | Stop queued encryptions or kill running worker threads if the operator wants to pause post-reboot actions. |
Quit | Terminate the agent and rm -f its binary for fast self-removal. |
Welcome | Abuse esxcli system welcomemesg set -m="text" to display ransom notices right in the console banner. |
Internally these agents keep two mutex-protected JSON blobs (runtime config + status/telemetry) so that concurrent threads (e.g. beaconing + encryption workers) do not corrupt shared state. Samples are commonly padded with junk code to slow shallow static analysis but the core routines remain intact.[1]
Virtualization & Backup-Aware Targeting
Mario-like encryptors only traverse operator-supplied directory roots and touch virtualization artefacts that matter for business continuity:
| Extension | Target |
|---|---|
vmdk, vmem, vmsd, vmsn, vswp | VM disks, memory snapshots and swap backing files. |
ova, ovf | Portable VM appliance bundles/metadata. |
vib | ESXi installation bundles that can block remediation/patching. |
vbk, vbm | Veeam VM backups + metadata to sabotage on-box restores. |
Operational quirks:
- Every visited directory receives
How To Restore Your Files.txtbefore encryption to ensure ransom channels are advertised even on disconnected hosts. - Already processed files are skipped when their names contain
.emario,.marion,.lmario,.nmario,.mmarioor.wmario, preventing double encryption that would break the attackers’ decryptor. - Encrypted payloads are renamed with a
*.mario-style suffix (commonly.emario) so operators can verify coverage remotely in consoles or datastore listings.[1]
Layered Encryption Upgrades
Recent Mario builds replace the original linear, single-key routine with a sparse, multi-key design optimised for multi-hundred-gigabyte VMDKs:
- Key schedule: Generate a 32-byte primary key (stored around
var_1150) and an independent 8-byte secondary key (var_20). Data is first transformed with the primary context and then re-mixed with the secondary key before disk writes. - Per-file headers: Metadata buffers (e.g.
var_40) track chunk maps and flags so the attackers’ private decryptor can reconstruct the sparse layout. - Dynamic chunking: Instead of a constant
0xA00000loop, chunk size and offsets are recomputed based on file size, with thresholds extended up to ~8 GB to match modern VM images. - Sparse coverage: Only strategically chosen regions are touched, dramatically reducing runtime while still corrupting VMFS metadata, NTFS/EXT4 structures inside the guest or backup indexes.
- Instrumentation: Upgraded builds log per-chunk byte counts and totals (encrypted/skipped/failed) to stdout, giving affiliates telemetry during live intrusions without extra tooling.[1]
See also
Linux LPE via VMware Tools service discovery (CWE-426 / CVE-2025-41244):
Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244