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_dump

Bruteforce

msf> auxiliary/scanner/vmware/vmware_http_login

If 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.

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 control

The 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.

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.

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.txt before encryption to ensure ransom channels are advertised even on disconnected hosts.
Already processed files are skipped when their names contain .emario, .marion, .lmario, .nmario, .mmario or .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.

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 0xA00000 loop, 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.

References

Unit 42 – From Linear to Complex: An Upgrade in RansomHouse Encryption