Cybersecurity researchers have attributed the exploitation of a newly patched security flaw in Broadcom VMware vCenter to a suspected China-nexus advanced persistent threat (APT).
The attacks involve the exploitation of CVE-2026-59310 (CVSS score: 9.8), a severe directory-traversal vulnerability in the VMware vCenter server that could be weaponized by a malicious actor to execute arbitrary code. A fix for the flaw was released by Broadcom on July 29, 2026.
German incident response company QUIRSO assessed with moderate confidence that the exploitation campaign aimed at CVE-2026-59310 is operated by a Chinese-speaking threat actor, likely working in the UTC+08:00 time zone, which is predominantly used in Chinese-speaking regions.
“This assessment is based on the convergence of Chinese-language artifacts in attacker-created scripts, apparent reuse of research from a Chinese security publication, repeated operational use of Chinese-language tools and management software, victimology excluding mainland China, and activity patterns compatible with UTC+08:00 working hours,” QUIRSO researchers Maike Orlikowski, Çağatay Yürekli, and Denis Szadkowski said.
The activity, which commenced five calendar days after public disclosure of the flaw, is estimated to have compromised 361 unique victim IP addresses across 47 countries, with most of the infections scattered across Germany (55), the U.S. (41), Turkey (38), Iran (26), and France (25).
Exploitation of CVE-2026-59309
One compromised vCenter Server Appliance analyzed by QUIRSO is said to have been targeted by both CVE-2026-59310 and CVE-2026-59309, an authentication bypass that has also witnessed active scanning efforts. Evidence shows malicious activity consistent with the exploitation of CVE-2026-59309 as early as August 1, 2026, followed by the creation of an administrative account on vCenter.
That said, no login events have been observed for the legitimate administrative account that was used to create this new account. The account creation originated from the IP address 146.59.252[.]178 and also involved vSphere discovery via the REST API on August 3 using User-Agent strings like “GoodMoodle-VCFleet/1.0,” in an attempt to masquerade it as VMware-related activity.
It’s worth noting that VCF Fleet is a centralized management capability introduced by Broadcom in ware Cloud Foundation (VCF) in version 9.0 to deploy, scale, patch, and operate multiple VCF instances. It encompasses multiple components, including VCF Operations, VCF Automation, vCenter, NSX Manager, vSphere Cluster, and workload domains.
QUIRSO said there is no overlap between this activity and the chain of events involving the abuse of CVE-2026-59310 on the same system starting August 3, adding the newly created “vcenter_admin” administrator account was not used in subsequent phases of the attack.
Exploitation of CVE-2026-59310
As for the exploitation of CVE-2026-59310, the first activity involved the cron daemon (aka crond) logging a malformed cron file called “zz-poc59310-syslog.log.” In the next step, a curl command (or alternatively a wget command) is executed to retrieve a backdoor from “5.34.177[.]38:9861” and execute it, and then remove the log file.
The naming convention of the log file is significant as it is a direct reference to the CVE identifier and that it was a proof-of-concept (PoC) devised after details of the flaw became public knowledge.
“The ‘-syslog.log’ suffix also mirrors the vCSA remote syslog file naming convention, but the file appears under /etc/cron.d rather than the configured syslog output directory,” QUIRSO explained. “This suggests that the vCSA syslog server was abused to place files in a privileged execution location. While some files were malformed and not executed by cron, at least one file successfully executed and placed the ‘linuxFile’ backdoor on the system.”
The linuxFile implant is designed to provide remote command execution capabilities to the attacker. It establishes a connection to its controller over a WebSocket channel to receive instructions, executes them through /bin/sh, and transmits the results back to the attacker.
“The C2 [command-and-control] address is XOR-obfuscated and decoded at run-time, while communications are protected using the malware’s own application-layer cryptography despite using an unencrypted ws:// transport,” Szadkowski told The Hacker News via email. “It also automatically reconnects on failure and contains routines for establishing persistence through systemd and cron.”
The threat actor behind the operation also relied extensively on cron to execute malicious payloads, including to fetch and run a shell script (“esxi.sh”) from the IP address “185.144.28[.]120:3232.” The shell script then serves as a downloader and persistence installer for an architecture-specific reverse SSH (“reverse_ssh”) binary that’s retrieved from the same infrastructure.
Other cron jobs related to creating staging directories, downloading executables, changing their permissions, and running them, while referencing servers at “192.255.141[.]13:8080” and “5.34.176[.]100:5244.” In what appears to be an operational security blunder, the latter has been found to expose the reverse SSH binaries toolset via an AList directory listing.
A brief description of some of the various actions carried out by the threat actor is as follows –
- Deploying “linuxFile” (aka systemlog or linux_x86), which connects to “ws://intel.se9ly9upbhay.shop:8080/ws” and establishes persistence via a systemd service.
- Setting three cronjobs impersonating legitimate VMware services: vmware-vpxd-stats-* (facilitates an SSH-based remote access channel by adding the attacker’s SSH public key to the authorized keys file), vmware-perf-collect-* (drops a JSP web shell named “vmware-perf-update.jsp”), and vmware-perf-sync-* (drops the same web shell and runs a Base64-encoded script that performs credential access and sets up a new account called “adminuser,” which is then added to the vSphere SSO Administrators group.
- Creating two additional accounts: adding “vcadmin” to vSphere with a Base64-encoded Python script dropped on disk via bash commands run in a cronjob and creating a vSphere admin account via an external LDAP “Add” operation against vCenter’s VMware Directory Service (vmdir) from a remote client by using a pre-existing but compromised administrative account.
- Creating a file named “/etc/sudoers.d/vmware-perf” with a configuration that grants the “perfcharts” service account unrestricted, non-interactive passwordless sudo access to root.
- Running shell scripts like “/tmp/.vmware-perf-upd.sh” to obtain credentials for vmdir by querying the HKEY_THIS_MACHINEservicesvmdir registry location. If this method fails, it searches for VMware’s vmafd Python module and calls GetMachineName(), GetMachinePassword(), and GetDomainName() to get the distinguished name and password associated with the vCenter machine account. The stolen credentials are used to conduct privileged directory modifications, including adding the aforementioned “adminuser” identity to the Administrators group.
- Using vSphere API to perform discovery operations and “esxi.sh” to deploy the reverse_ssh client.
- Creating local accounts on the ESXi hosts (e.g., “adminuser”) to enable ransomware encryption.
- Taking steps to evade detection, reduce forensic visibility, and blend into the VMware environment.
The attack ultimately paves the way for the deployment of a ransomware on ESXi hosts that encrypts files with the “.babyk” extension, which is typically associated with Babuk-derived ransomware. It’s not clear if this was the end goal of the campaign, or if the Babuk-derived payload was “selected opportunistically or even intentionally” to confuse attribution efforts.
QUIRSO told the publication it cannot assess at this stage if the ransomware strain was deployed across other compromised systems as the analysis was limited to only one of the infected systems. However, based on the investigation so far, it’s suspected that the deployment of the locker may not have been the primary objective of the campaign.
Szadkowski likened the deployment to a smokescreen engineered to distract defenders from the main intrusion and thwart analysis by encrypting the ESXi log files, thereby preventing access to telemetry data that could have offered more insights into threat actor activity.
“Exploitation of CVE-2026-59310 provided the actor with immediate, non-interactive code execution in a root context on the vCenter Server appliance,” the researchers said. “Subsequent commands recorded by CROND were therefore already being executed as root, giving the actor unrestricted access to the underlying VCSA without first having to compromise an unprivileged local account and escalate from it.”
