vCenter CVE-2026-59310: China-Nexus APT Establishes 361 Ransomware Footholds in 47 Countries

Campaign summary

A suspected China-nexus APT converted a single VMware vCenter vulnerability into 361 confirmed footholds across 47 countries. German incident response firm QUIRSO tracked the campaign against CVE-2026-59310, a CVSS 9.8 directory traversal flaw in Broadcom VMware vCenter Server that yields arbitrary code execution. The endgame is Babuk-derived ransomware deployed on the hypervisor management layer.

Broadcom shipped the fix on July 29, 2026. Exploitation began five calendar days after public disclosure.

Why vCenter is the wrong thing to lose

An attacker with root on a vCenter Server Appliance and membership in the vSphere SSO Administrators group owns every workload domain, every datastore, and every VM the appliance manages. Ransomware at that layer does not encrypt one server. It encrypts the platform the servers run on.

Attribution indicators

QUIRSO researchers Maike Orlikowski, Cagatay Yurekli, and Denis Szadkowski assess with moderate confidence that a Chinese-speaking actor operating in UTC+08:00 runs the campaign. The assessment rests on converging indicators:

• •
  Chinese-language artifacts embedded in attacker-created scripts
• •
  Apparent reuse of exploitation research published by a Chinese security outlet
• •
  Repeated operational use of Chinese-language tooling and management software
• •
  Victimology that excludes mainland China
• •
  Activity patterns consistent with UTC+08:00 working hours

Moderate confidence means the indicators align but alternative explanations survive. Treat this as a threat actor profile to hunt against, not a diplomatic conclusion.

The exploit chain: syslog to cron to root

The initial artifact is a malformed cron file that crond logged as zz-poc59310-syslog.log. The name references the CVE directly and indicates a proof of concept built after public disclosure. QUIRSO's assessment is that the actor abused the vCSA syslog server as a write primitive to drop files into a privileged execution path. The file lands in /etc/cron.d rather than the configured syslog output directory. Several files were malformed and never ran, but at least one executed successfully.

That execution issued a curl fetch against 5.34.177.38:9861 to retrieve and run a backdoor, then deleted the cron log file behind it.

The linuxFile implant

The payload, tracked as linuxFile and also seen as systemlog and linux_x86, is a compact remote command execution implant. It opens a WebSocket channel to its controller, receives instructions, executes them through /bin/sh, and returns output over the same channel.

The tradecraft is better than commodity. The C2 address is XOR-obfuscated and decoded at runtime. Communications use the malware's own application-layer cryptography despite riding unencrypted ws:// transport. That combination defeats naive string extraction and blunts TLS inspection dependent detection at the same time. The implant reconnects automatically on failure and carries built-in persistence routines for both systemd and cron. One observed C2 endpoint: ws://intel.se9ly9upbhay.shop:8080/ws.

Persistence disguised as VMware telemetry

The actor leaned heavily on cron and named jobs to blend into vCenter's own performance and statistics tasks. Three impersonating cron jobs were observed:

• •
  vmware-vpxd-stats-*: appends the attacker's SSH public key to authorized_keys, establishing an SSH remote access channel
• •
  vmware-perf-collect-*: drops a JSP web shell named vmware-perf-update.jsp
• •
  vmware-perf-sync-*: drops the same web shell, then runs a Base64-encoded script that performs credential access and creates an adminuser account added to the vSphere SSO Administrators group

Additional accounts including vcadmin were added to vSphere. Separate cron jobs fetched a shell script named esxi.sh from 185.144.28.120:3232, which acts as a downloader and persistence installer for an architecture-specific reverse_ssh binary pulled from the same infrastructure.

Two CVEs, one appliance, two operators

On at least one compromised vCenter Server Appliance, QUIRSO found evidence of a second flaw in play: CVE-2026-59309, an authentication bypass also drawing active internet-wide scanning. Activity consistent with CVE-2026-59309 exploitation appears as early as August 1, 2026, followed by creation of a vCenter administrative account named vcenter_admin from 146.59.252.178. No login events were logged for the legitimate administrative account credited with creating it, which is the signature of an authentication bypass rather than credential theft.

On August 3 the same operator enumerated vSphere via the REST API using the User-Agent string GoodMoodle-VCFleet/1.0, a deliberate imitation of VCF Fleet, the centralized multi-instance management capability Broadcom introduced in VMware Cloud Foundation 9.0. QUIRSO found no overlap between this activity and the CVE-2026-59310 chain that started on the same host that same day. Two distinct operators, one appliance, inside 72 hours.

A vCenter appliance exposed long enough to be hit by CVE-2026-59310 was almost certainly also scanned for CVE-2026-59309. Scoping an incident around a single CVE will leave a second actor's persistence in place.

Detection and hunting guidance

Cron job hunt: Grep /etc/cron.d for entries matching vmware-vpxd-stats-, vmware-perf-collect-, and vmware-perf-sync-, plus any file matching zz--syslog.log.

Web shell hunt: Look for vmware-perf-update.jsp on the appliance filesystem.

SSH key audit: Check root's authorized_keys for unexpected entries.

Account audit: Enumerate every account in the vSphere SSO Administrators group and correlate creation events against actual authentication logs for the creating account. Look for accounts named vcenter_admin, adminuser, and vcadmin.

Systemd services: Check for unrecognized systemd services on the vCSA.

Network egress: Block and alert on the listed IPs (5.34.177.38, 185.144.28.120, 146.59.252.178, 192.255.141.13, 5.34.176.100) and on ws:// egress from vCenter appliances, which should never initiate outbound WebSocket connections.

Remediation

Patch CVE-2026-59310 with Broadcom's July 29, 2026 release and apply the CVE-2026-59309 authentication bypass fix in the same window. Then accept that patching an appliance compromised on or after August 3 evicts nothing: the SSH keys, systemd services, cron jobs, JSP web shell, and rogue SSO accounts all survive a patch.

Treat any vCenter appliance that was internet-reachable during the exposure window as needing full compromise assessment. Pull vCenter management off any network path an attacker can reach from the internet. A five-day gap between disclosure and mass exploitation is the operating tempo now, and vCenter is not a system that can be patched on a monthly cycle.