Summary:
In early 2025, Sygnia identified and investigated a sophisticated cyber-espionage campaign known as Fire Ant, which targeted VMware ESXi hosts, vCenter servers, and network appliances. The threat actor operated with stealth and persistence, leveraging hypervisor-level techniques to maintain access while evading traditional detection. Initial access was often gained through exploitation of CVE-2023-34048, an out-of-bounds write vulnerability in the vCenter DCERPC protocol that allowed unauthenticated remote code execution. After compromising vCenter, Fire Ant extracted credentials for the privileged ‘vpxuser’ account, enabling control over ESXi hosts and bypassing lockdown restrictions. The actor deployed persistent backdoors using unsigned VIBs and modified system startup scripts while disabling logging services to obscure forensic evidence.

Fire Ant used CVE-2023-20867 to execute commands on guest VMs without credentials via PowerCLI, tampered with endpoint detection tools like SentinelOne, and extracted credentials from memory snapshots using a customized version of the Volatility Framework. They also deployed V2Ray for encrypted tunneling and launched unregistered VMs manually, effectively bypassing vCenter’s inventory and visibility. To navigate segmented networks, Fire Ant compromised F5 load balancers via CVE-2022-1388, planted tunneling webshells on internal web servers using Neo-reGeorg, and installed the Medusa rootkit on Linux pivot points. The actor also abused trusted administrator workstations using netsh portproxy, exposed VMs to public networks, and exploited overlooked IPv6 pathways to bypass firewall rules


Security Officer Comments:
Despite eradication efforts, Fire Ant demonstrated strong operational resilience. They re-compromised systems, altered toolsets, and mimicked forensic tools to hinder investigation and maintain access. The group’s techniques, toolsets, and target profile—particularly the focus on VMware environments—closely resemble past campaigns attributed to the Chinese-nexus threat actor UNC3886. While Sygnia stops short of formal attribution, the overlaps in malware, exploitation methods, and working patterns suggest a high degree of alignment. Fire Ant exemplifies the growing threat of infrastructure-level intrusions where traditional security tools lack visibility, especially within hypervisor and virtualization environments. This campaign underscores the need for enhanced monitoring of ESXi and vCenter activity, including tamper detection and log integrity validation.


Suggested Corrections:

Researchers at Sygnia have recommended the following mitigations:


Monitoring for Fire Ant Activity

1. Unexpected Termination of ‘vmsyslogd’ Process: Termination of the vmsyslogd process, as observed to be performed by the threat actor, will result with complete stop of syslog forwarded by the affected ESXi. Monitoring for sudden stop of syslog flow can indicate such termination.
2. Unauthorized Execution of ‘vim-cmd’ or ‘esxcli’ Commands: Alert on use of snapshot-related or host management commands issued from non-standard users or outside approved automation windows.
3. Unique Process Execution on ESXi Hosts: ESXi systems have a highly consistent process baseline due to their closed architecture. New or unexpected binaries, especially in paths like ‘/tmp', '/scratch‘, or other writable locations, should be treated as suspicious. Monitor for execution of uncommon ELF files (e.g., tools, update, ksmd) or any process names not found in a known-good baseline.
4. Rogue Virtual Machine Execution via ‘vmx -x’: Monitor for direct execution of the ‘/bin/vmx‘ binary with the ‘x‘ argument, which can launch virtual machines outside of vCenter’s visibility. This method bypasses standard registration workflows, making VMs invisible to inventory systems and administrative interfaces. Such executions are rare in legitimate operations and should be flagged for immediate investigation.
5. Guest Command Execution with ‘vmtoolsd[.]exe‘ as Parent Process: In guest virtual machines, monitor for process creation events where ‘cmd[.]exe’ or ‘powershell.exe’ is spawned with ‘vmtoolsd.exe’ as the parent process. This pattern is indicative of host-to-guest command injection and is uncommon in normal operations. This behavior should trigger alerts, especially when accompanied by encoded commands or unusual script execution.
6. Stale EDR Agents on Active Virtual Machines: Monitor for virtual machines that appear active and running but show no recent telemetry from their EDR agents. Cross-reference VM inventory, vCenter status or Active Directory logs with EDR check-ins to identify discrepancies that may indicate tampering or targeted visibility disruption.

Hardening and Prevention Strategies
In response to the attack techniques leveraging VMware ESXi and vCenter infrastructure for espionage operations, defenders must adopt a proactive and layered security approach. The following strategies are aimed at reducing the attack surface, preventing unauthorized access, and ensuring stronger operational security of virtualization assets.

1. Apply security patches
   • Ensure ESXi and vCenter servers are running up-to-date software with the latest security patches.
2. Enforce strong and regularly rotated passwords
   • Use unique and secure passwords.
   • Assign unique, non-reused, complex passwords to all ESXi root accounts and vCenter administrative users.
   • Store break-glass account credentials securely in a password vault, ensuring emergency accessibility without daily exposure.
   • Implement regular password rotation
   • Use a Privileged Identity Management (PIM) solution to automate regular password rotation and audit access.
   • Where automation is not feasible, establish a documented manual rotation process for administrative and break-glass accounts, with a maximum interval of 180 days.
3. Enforce segmentation and isolation
   • Limit direct access to ESXi hosts by enforcing administrative interactions through vCenter wherever possible.
   • Apply firewall rules to restrict vCenter access exclusively to designated jump servers, PAM solution or administrative subnets.
4. Enable Lockdown Mode on ESXi hosts
   • Apply Normal Lockdown Mode to prevent direct SSH, HTTPS and DCUI access, requiring administrative actions to flow through vCenter.
   • Maintain a minimal list of authorized exception users (e.g., for backup tools), and review it regularly.
5. Enable Secure Boot on ESXi hosts
   • Enable Secure Boot on ESXi hosts to prevent installation of unsigned and unauthorized VIBs.

Link(s):
https://www.infosecurity-magazine.com/news/chinese-espionage-targets-vmware/