{
	"id": "b56ed5db-61b3-494d-9788-9fa183725734",
	"created_at": "2026-04-06T01:30:28.048682Z",
	"updated_at": "2026-04-10T03:29:54.68001Z",
	"deleted_at": null,
	"sha1_hash": "712d50a4fba826d692e7b2587e09eeb22372e4a3",
	"title": "Fire Ant: A Deep-Dive into Hypervisor-Level Espionage",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 728151,
	"plain_text": "Fire Ant: A Deep-Dive into Hypervisor-Level Espionage\r\nBy Sygnia\r\nPublished: 2025-07-24 · Archived: 2026-04-06 00:31:35 UTC\r\nExecutive Summary\r\nSince early 2025, Sygnia tracked and responded to a prolonged espionage campaign, designated Fire Ant,\r\ntargeting virtualization and networking infrastructure. Primarily VMware ESXi and vCenter environments\r\nas well as network appliances.\r\nThe threat actor leveraged combinations of sophisticated and stealthy techniques creating multilayered\r\nattack kill chains to facilitate access to restricted and segmented network assets within presumed to be\r\nisolated environments.\r\nThe attacker demonstrated a high degree of persistence and operational maneuverability, operating through\r\neradication efforts, adapting in real time to eradication and containment actions to maintain access to the\r\ncompromise infrastructure.\r\nSygnia identified tooling and techniques that closely align with prior campaigns attributed to UNC3886.\r\nTechnical overlap including specific binaries and exploitation of vCenter and ESXi vulnerabilities as well\r\nas targeted verticals.\r\nThis campaign underscores the importance of visibility and detection within the hypervisor and\r\ninfrastructure layer, where traditional endpoint security tools are ineffective.\r\nBackground\r\nSince early 2025, Sygnia tracked and responded to incidents attributed to a threat actor we designate Fire Ant. The\r\ngroup demonstrates consistent targeting of virtualization and network infrastructure, using these systems as\r\nfootholds for initial access, lateral movement, and long-term persistence. Fire Ant’s operations are characterized\r\nby infrastructure-centric TTPs, enabling activity beneath the detection threshold of traditional endpoint controls,\r\nhighlighting critical blind spots of conventional security stacks.\r\nFire Ant established strong control over victims’ VMware ESXi hosts and vCenter servers, then pivoted into guest\r\nenvironments using unauthenticated host-to-guest command execution and credential access directly from the\r\nvirtualization host. The actor consistently bypassed network segmentation by compromising network appliances\r\nand tunneling across segments, carefully navigating through legitimate approved paths.\r\nSygnia observed high levels of operational resilience. Fire Ant actively adapted to eradication and containment\r\nefforts, replacing toolsets, deploying redundant persistence backdoors, and manipulating network configurations\r\nto re-establish access.\r\nThis report presents a technical breakdown of Fire Ant’s infrastructure-level capabilities, derived from Sygnia’s\r\ninvestigations.\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 1 of 12\n\nTechnical Breakdown\r\nThe earliest detection came from a single malicious process, executed inside a guest virtual machine which\r\ntriggered an alert. What stood out was the parent process ‘vmtoolsd.exe’, part of VMware Tools. This detail\r\nsuggested the command had not been launched from within the guest, but rather injected from the host. This\r\nanomaly shifted the investigation toward the virtualization layer and led to the discovery of the broader campaign.\r\nIn the following breakdown, we cover Fire Ant’s campaign across three focus areas: the toolset used to\r\ncompromise and control virtualization infrastructure, the techniques leveraged for cross-segment lateral movement\r\nand network access, and the notable approach of the threat actor to maintain persistence through active eradication\r\nefforts.\r\nThreat Actor Capabilities in VMware Virtualization Environments\r\nThe threat actor demonstrated strong capabilities in compromising and leveraging VMware infrastructure, using a\r\nstructured approach:\r\n1. vCenter Initial Compromise: They exploited CVE-2023-34048 to achieve unauthenticated remote code\r\nexecution on vCenter, gaining control over the virtualization management layer.\r\n2. Lateral Movement to ESXi hosts and Persistence: From vCenter, they extracted the ‘ vpxuser ’ service\r\naccount credentials and used them to access connected ESXi hosts. They deployed multiple persistent\r\nbackdoors on both ESXi hosts and the vCenter to maintain access across reboots.\r\n3. Guest VM Access and Exploitation: With control over the hypervisor, the attacker interacted directly with\r\nguest virtual machines. They manipulated VMX processes and used CVE-2023-20867 to execute\r\ncommands via PowerCLI without in-guest credentials, tampered with security tools, and extracted\r\ncredentials from memory snapshots, including domain controllers.\r\nThis approach enabled full-stack compromise, providing persistent, covert access from the hypervisor to guest\r\noperating systems.\r\nCompromising the Virtualization Infrastructure\r\nvCenter Exploitation Using  CVE-2023-34048\r\nUnexpected crashes of the ‘ vmdird ’ process on vCenter servers shortly before the first signs of malicious activity\r\nsuggest exploitation of CVE-2023-34048.\r\nCVE-2023-34048 is an out-of-bounds write vulnerability in vCenter Server’s DCERPC protocol implementation,\r\nwhich allows a remote attacker with network access to achieve unauthenticated remote code execution.\r\nFigure 1: vMonCoreDumper.log\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 2 of 12\n\nThis finding aligns with reporting by Google Cloud Threat Intelligence, which documented the use of CVE-2023-\r\n34048 by UNC3886 to exploit vCenter (link).\r\nvCenter User Interface Access via Cookie Generation\r\nThe threat actor leveraged access to the compromised vCenter to generate a forged authentication cookie using the\r\nopen source script vCenter_GenerateLoginCookie.py, which abuses vCenter’s certificate trust mechanism to\r\nbypass authentication.\r\nThe script requires a set of inputs, including the target address, hostname, domain, and paths to three certificate\r\nfiles: ‘ idp_cert.txt ’, ‘ trusted_cert_1.txt ’, and ‘ trusted_cert_2.txt ’. All three certificates were extracted\r\nby the threat actor using the open source script vCenter_ExtraCertFromMdb.py and were found under\r\n‘ /var/tmp/ ’ on compromised hosts. By executing the script with these inputs, the threat actor generated a valid\r\nsession cookie, enabling authenticated administrator access to the vCenter user interface without credentials or\r\nlogin events.\r\nvCenter ‘vpxuser’ Credentials Harvesting\r\nThe threat actor leveraged access to the compromised vCenter to retrieve credentials for the ‘ vpxuser ’ accounts,\r\nsystem accounts automatically created by vCenter to manage ESXi hosts with full administrative privileges. As\r\n‘ vpxuser ’ is used by vCenter for core management tasks, it is exempt from lockdown mode restrictions. This\r\nallowed the threat actor to retain host-level access even when direct logins were disabled, gaining control over all\r\nconnected ESXi hosts.\r\nPersistent Backdoor on vCenter\r\nThe threat actor deployed a persistent backdoor binary on vCenter servers across the environment named ‘ ksmd ‘,\r\nlocated at ‘ /usr/libexec/setconf/ksmd ’. The binary was configured to listen on TCP port 7475 and enabled\r\nremote command execution and file operations.\r\nThe backdoor was deployed immediately after a remote login event and remained active across system reboots.\r\nThe backdoor filename, hash and deployment technique aligned the VIRTUALPITA malware family, previously\r\ndocumented by Google Cloud Threat Intelligence and attributed to UNC3886.\r\nESXi Persistence with Unsigned VIBs\r\nThe threat actor used malicious vSphere Installation Bundles (VIBs) to establish persistent backdoors on multiple\r\nESXi hosts. VIBs are VMware’s packaging format for distributing drivers, updates, and third-party software.\r\nThree unauthorized VIBs were discovered containing configuration files that referenced binaries deployed to\r\n‘ /bin ‘ folder and custom scripts embedded in ‘ /etc/rc.local.d/' , enabling execution at system startup.\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 3 of 12\n\nFigure 2: malicious VIB xml file showing the deployed files and the acceptance-level\r\nAcceptance-level of the three identified VIBs was set to ‘ partner ‘ and they were deployed with the\r\nflag ‘– force ‘, bypassing signature validation.\r\nThe backdoors filenames and hashes as well as deployment techniques aligned the VIRTUALPITA malware\r\nfamily, previously documented by Google Cloud Threat Intelligence and attributed to UNC3886.\r\nESXi Persistence with ‘ local.sh ’ Modification\r\nIn addition to unsigned VIBs, the threat actor directly modified ‘ /etc/rc.local.d/local.sh ’ on ESXi hosts to\r\nexecute a Python script located at ‘ /bootbank/autobackup.bin ’.\r\nFigure 3: modified local.sh showing the execution of the python script ‘autobackup.bin’\r\nThis Python script acts as a HTTP-based backdoor, running a local web server on port 8888.\r\nFigure 4: ‘autobackup.bin’ code binding to port 8888\r\nIt provides remote command execution, file download, and upload capabilities.\r\nFigure 5: ‘autobackup.bin’ code showing the implementation of the command execution capability\r\nThe script is compatible with both Python 2 and Python 3, and it runs in the background as a daemon.\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 4 of 12\n\nThe Python based backdoor uses double-fork to detach from terminal and run in the background and redirects\r\nstdin, stdout, stderr to ‘ /dev/null ’.\r\nESXi Log Tampering\r\nThe threat actor tampered with logging on ESXi hosts by terminating the ‘ vmsyslogd ’ process, VMware’s native\r\nsyslog daemon responsible for forwarding system logs. This action disabled both local log writing and remote log\r\nforwarding, effectively cutting off audit trails at the source. By suppressing system-level logging early in the\r\nintrusion, the threat actor limited forensic visibility and challenged both real-time detection and retrospective\r\nforensic analysis.\r\nLeveraging Hypervisor Access\r\nGuest Command Execution via PowerCLI and VMX Process Modification (CVE-2023-20867)\r\nThe threat actor leveraged PowerCLI to execute commands inside guest virtual machines without the required in-guest authentication. This was achieved through the exploitation of CVE-2023-20867, a vulnerability in VMware\r\nTools that permits unauthenticated host-to-guest operations including command execution.\r\nUsing the PowerCLI ‘ Invoke-VMScript ’ cmdlet, the threat actor executed encoded PowerShell commands on the\r\nguest machines.\r\nFigure 6: Snippet from Broadcom documentation, showing an example usage of Invoke-VMScript\r\ncmdlet for PowerCLI.\r\nThese commands are routed through ‘ vmtoolsd.exe ’ and the output is redirected to temporary files under\r\n‘ C:\\Windows\\TEMP\\vmware-system\\powerclivmware* ‘, facilitating retrieval without generating additional user\r\nactivity.\r\nTo enable the command execution path without authentication to the guest machine, the threat actor deployed an\r\nELF binary named ‘ tools ’ to modify memory within the ESXi host’s VMX process. The binary accepted\r\narguments including a cartel ID (linked to the VMX process ID), memory address, and operation mode. When\r\nexecuted, it patched the control logic within the VMX process, allowing the PowerCLI-issued commands to\r\nbypass guest authentication entirely.\r\nCredential Dumping from Memory Snapshots\r\nThe threat actor directly accessed virtual memory files(.vmem) to extract credentials from suspended or\r\nsnapshotted virtual machines. The attacker created snapshots using ‘ vim-cmd vmsvc/snapshot.create ‘, ensuring\r\nmemory was captured.\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 5 of 12\n\nThe threat actor then executed a binary named ‘ UpdateApp ’, which is a compiled variant of the open-source\r\nVolatility Framework. Commands such as hashdump and lsadump were used to extract NTLM hashes and\r\ncredentials from guest operating systems, specifically targeting high-value systems like domain controllers.\r\nFigure 7: Snippet from shell.log, showing the execution of ‘UpdateApp’ with hashdump and\r\nlsadump command-line options.\r\nOnce extraction was complete, the attacker removed the snapshot using ‘ vim-cmd vmsvc/snapshot.remove ‘,\r\nminimizing forensic evidence. This method allowed credential access without any in-guest artifacts or process\r\ncreation.\r\nGuest EDR Tempering\r\nThe threat actor leveraged PowerCLI unauthenticated guest operations to deploy and execute a custom executable\r\nnamed ‘ updatelog.exe ‘ on virtual machines. The tool was invoked with ‘ SentinelMonitor.sys ‘ as its first\r\nargument, using the following command:\r\nFigure 8: powershell command executed by vmtoolsd, executing the ‘updatelog.exe’ binary\r\nAlthough the executable was deleted post-execution and unavailable for direct analysis, ‘ updatelog.exe ’ was the\r\nfinal process creation event recorded by the SentinelOne agent. Process creation telemetry continued to be\r\ncollected by additional monitoring tools deployed on the machine, strongly suggesting the system remained\r\noperational and that only SentinelOne’s visibility was disrupted.\r\nGuest Network Tunneling with V2Ray\r\nAdditionally, the threat actor leveraged PowerCLI unauthenticated guest operations to deploy and execute a binary\r\nnamed ‘ update.exe ’ on virtual machines. This binary was identified as V2Ray framework, an open-source\r\nplatform used to create encrypted tunnels for proxy-based communication. Alongside the binary, a configuration\r\nfile was present specifying a listener on TCP port 58899 and defining upstream proxy settings for command-and-control routing for network restricted assets.\r\nFigure 9: V2Ray configuration file configuring listening on port 58899\r\nRogue VM Deployment\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 6 of 12\n\nThe threat actor deployed unregistered virtual machines directly on multiple ESXi hosts by manually launching\r\nthem using the ‘ /bin/vmx ’ native binary with the argument ‘ -x ’ affectively launching a VM directly from its\r\n.vmx file, bypassing vCenter registration.\r\nThis method bypasses standard VM registration workflows, allowing the rogue VMs to run outside of vCenter\r\nawareness and remain hidden from administrative interfaces. The virtual machines operated in the background and\r\nwere not reflected in inventory tools or standard monitoring.\r\nEach instance was assigned MAC addresses outside the typical VMware virtual NIC range. This MAC spoofing\r\nchallenged the correlation of the rogue VMs with the hosting ESXi. In such cases, identifying compromised\r\nsystems required inspecting physical switch MAC tables or scanning all ESXi hosts within the subnet to uncover\r\nthe unregistered virtual machine.\r\nNetwork Infrastructure Manipulation\r\nThe threat actor demonstrated a deep understanding of the target environment’s network architecture and policies,\r\neffectively navigating segmentation controls to reach internal, presumably isolated assets. By compromising\r\nnetwork infrastructure and tunneling through trusted systems, the threat actor systematically bypassed\r\nsegmentation boundaries, reached isolated networks and established cross-segments persistence.\r\nBridging via Compromised Infrastructure\r\nF5 Load Balancers\r\nThe threat actor compromised F5 load balancers by exploiting CVE-2022-1388, a critical vulnerability in the\r\niControlREST API that allows unauthenticated command execution. Using the vulnerability, the threat actor\r\ndeployed a staging webshell to ‘ usr/local/www/xui/common/css/css.php ‘\r\nfigure 10: command executed using iControlRest F5 API to deploy the staging webshell\r\nfigure 11: the decoded webshell content\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 7 of 12\n\nThe threat actor used the deployed webshell to deploy additional webshells in the ‘ /xui/common/css/ ’ directory,\r\nincluding a tunneling webshell that enabled bridging between networks connected to the load balancer.\r\nWeb Servers\r\nInternal web servers running java-based were used by the threat actor to host tunneling webshells based on the\r\nopen-source project Neo-reGeorg http://github.com/L-codes/Neo-reGeorg.\r\nThis gave the threat actor additional access to internal networks over encrypted, persistent application-layer\r\ntunnels, allowed by firewalls policies.\r\nLinux Pivot Hosts with Medusa Rootkit\r\nTo maintain long-term access across the environment, the threat actor established stealthy persistence on key\r\nLinux pivot points by deploying a variant of the open-source Medusa rootkit.\r\n(https://github.com/ldpreload/Medusa/tree/main)\r\nThe Medusa rootkit enables an interactive shell and logs SSH credentials to a file named ‘ remote.txt ’,\r\nsupporting both a backdoor to the compromised device and a credential harvesting mechanism.\r\nTunneling via Trusted Endpoints\r\nThe threat actor used ‘ netsh portproxy ’ commands to enable port forwarding on both servers and\r\nadministrators’ workstations, bypassing strict access control lists (ACLs) that limited direct communication with\r\nsensitive systems. By routing traffic through trusted endpoints, they were able to reach network-restricted assets\r\nwithout triggering firewall rules or segmentation controls.\r\nBypassing Network Controls\r\nExposing Assets to Public Networks\r\nWithin the compromised virtualization infrastructure, the threat actor configured publicly exposed network\r\ninterfaces on select virtual machines under their control. This setup established additional entry vectors into the\r\nnetwork, allowing direct external access to compromised systems, bypassing network security controls.\r\nIPtables Bypass with IPv6 Traffic\r\nThe threat actor leveraged IPv6 to bypass filtering rules that were configured for IPv4, exploiting the common gap\r\nin dual-stack environments where IPv6 traffic is often left unmonitored and unfiltered.\r\nBy embedding tunnels within critical infrastructure, abusing trusted administrator paths, and exploiting gaps in\r\nenforcement, Fire Ant created multiple redundant bridges between isolated networks, allowing freedom of\r\nmovement even under active response efforts.\r\nEradication Resilience\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 8 of 12\n\nThe threat actor actively maneuvered through eradication efforts by leveraging pre-established redundant access\r\npaths into internal networks. As defenders cleaned systems and removed tools and persistence, the threat actor re-compromised assets.\r\nAfter re-compromising assets, the threat actor rotated the deployed toolsets, altered execution methods, and\r\nrenamed binaries to avoid detection.\r\nIn addition, the threat actor investigated the response itself, reviewing logs, examining forensic tools, and in some\r\ninstances renaming their payloads to impersonate the identified forensic tools. The threat actor’s actions\r\ndemonstrated the need for a coordinated, system-wide eradication effort that eliminates all access vectors in a\r\nsingle, controlled operation, followed by thorough tailored monitoring to alert on any re-entry attempts\r\nAttribution and overlap with UNC3886\r\nWhile Sygnia refrains from conclusive attribution, multiple aspects of Fire Ant’s campaign and most notably its\r\nunique tool set and attack vector targeting the VMware virtualization infrastructure strongly align with previous\r\nresearch on the threat group UNC3886.\r\nThe active working hours of the threat group throughout the incidents and minor input errors observed during\r\ncommand execution aligned with Chinese-language keyboard layouts, consistent with prior regional activity\r\nindicators.\r\nDetecting \u0026 Defending Against Fire Ant\r\nStrategic Risks Highlighted by Fire Ant’s Campaign\r\nTrusted Infrastructure Blind Spots\r\nFire Ant consistently targeted infrastructure systems such as ESXi hosts, vCenter servers and F5 load balancers.\r\nThe targeted systems are rarely integrated into standard detection and response programs. These assets lack\r\ndetection and response solutions and generate limited telemetry, making them ideal long-term footholds for\r\nstealthy operation.\r\nNetwork Segmentation Bypassing\r\nFire Ant moved laterally by compromising infrastructure components that naturally bridge network boundaries.\r\nBy tunneling through trusted services and pivoting from one network to another via legitimate paths, the threat\r\nactor reached highly restricted environments while evading traditional ACLs, firewall policies, and segmentation\r\ncontrols. By bridging these segmented environments, the threat actor gained the ability to operate freely within\r\nnetworks that were otherwise considered secure and trusted, effectively collapsing internal trust boundaries.\r\nOperational Resilience to Eradication\r\nFire Ant treated remediation as a temporary disruption rather than an end state. The group re-entered environments\r\nvia redundant access points, retooled binaries to evade detection, and actively monitored defender activity to\r\nadjust tactics. In several cases, they re-compromised assets shortly after cleanup and used renamed tools to blend\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 9 of 12\n\ninto forensic workflows, highlighting the need for coordinated, simultaneous eradication and complementing\r\nmonitoring.\r\nMonitoring and Detection Strategies\r\nThe activity uncovered in Fire Ant’s campaign underscores the urgent need to both harden and monitor\r\nvirtualization infrastructure. Traditional security controls often overlook ESXi, vCenter, and related components,\r\nleaving critical gaps in visibility and response. Defenders must treat these systems as part of the active threat\r\nsurface and ensure they are monitored and protected.\r\nEnhancing Visibility on ESXi hosts\r\nFor detailed guidance on configuring ESXi log forwarding, refer to Sygnia’s blog on ESXi defense strategies,\r\nwhich outlines how to enable persistent logging and forward logs to a centralized syslog server. This setup is\r\nessential for ensuring visibility.\r\nMonitoring for Fire Ant Activity\r\n1. Unexpected Termination of ‘ vmsyslogd ’ Process – Termination of the vmsyslogd process, as observed\r\nto be performed by the threat actor, will result with complete stop of syslog forwarded by the affected\r\nESXi. Monitoring for sudden stop of syslog flow can indicate such termination.\r\n2. Unauthorized Execution of ‘ vim-cmd ’ or ‘ esxcli ’ Commands\r\nAlert on use of snapshot-related or host management commands (e.g., ‘ vim-cmd\r\nvmsvc/snapshot.create ‘) issued from non-standard users or outside approved automation windows.\r\n3. Unique Process Execution on ESXi Hosts\r\nESXi systems have a highly consistent process baseline due to their closed architecture. New or\r\nunexpected binaries, especially in paths like ‘ /tmp', '/scratch ‘, or other writable locations, should be\r\ntreated as suspicious. Monitor for execution of uncommon ELF files (e.g., tools , update , ksmd ) or\r\nany process names not found in a known-good baseline.\r\n4. Rogue Virtual Machine Execution via ‘ vmx -x ’\r\nMonitor for direct execution of the ‘ /bin/vmx ‘ binary with the ‘ -x ‘ argument, which can launch virtual\r\nmachines outside of vCenter’s visibility. This method bypasses standard registration workflows, making\r\nVMs invisible to inventory systems and administrative interfaces. Such executions are rare in legitimate\r\noperations and should be flagged for immediate investigation.\r\n5. Guest Command Execution with ‘ vmtoolsd.exe ‘ as Parent Process\r\nIn guest virtual machines, monitor for process creation events where ‘ cmd.exe ’ or ‘ powershell.exe ’ is\r\nspawned with ‘ vmtoolsd.exe ’ as the parent process. This pattern is indicative of host-to-guest command\r\ninjection and is uncommon in normal operations. This behavior should trigger alerts, especially when\r\naccompanied by encoded commands or unusual script execution.\r\n6. Stale EDR Agents on Active Virtual Machines\r\nMonitor for virtual machines that appear active and running but show no recent telemetry from their EDR\r\nagents. Cross-reference VM inventory, vCenter status or Active Directory logs with EDR check-ins to\r\nidentify discrepancies which may indicate tampering or targeted visibility disruption.\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 10 of 12\n\nHardening and Prevention Strategies\r\nIn response to the attack techniques leveraging VMware ESXi and vCenter infrastructure for espionage\r\noperations, defenders must adopt a proactive and layered security approach. The following strategies are aimed at\r\nreducing the attack surface, preventing unauthorized access, and ensuring stronger operational security of\r\nvirtualization assets. \r\n1. Apply security patches\r\nEnsure ESXi and vCenter servers are running up-to-date software with the latest security patches.\r\n2. Enforce strong and regularly rotated passwords\r\nUse unique and secure passwords.\r\nAssign unique, non-reused, complex passwords to all ESXi root accounts and vCenter\r\nadministrative users. \r\nStore break-glass account credentials securely in a password vault, ensuring emergency accessibility\r\nwithout daily exposure. \r\nImplement regular password rotation \r\nUse a Privileged Identity Management (PIM) solution to automate regular password rotation and\r\naudit access. \r\nWhere automation is not feasible, establish a documented manual rotation process for\r\nadministrative and break-glass accounts, with a maximum interval of 180 days. \r\n3. Enforce segmentation and isolation\r\nLimit direct access to ESXi hosts by enforcing administrative interactions through vCenter\r\nwherever possible. \r\nApply firewall rules to restrict vCenter access exclusively to designated jump servers, PAM solution\r\nor administrative subnets. \r\n4. Enable Lockdown Mode on ESXi hosts\r\nApply Normal Lockdown Mode to prevent direct SSH, HTTPS and DCUI access, requiring\r\nadministrative actions to flow through vCenter. \r\nMaintain a minimal list of authorized exception users (e.g., for backup tools), and review it\r\nregularly. \r\n5. Enable Secure Boot on ESXi hosts\r\nEnable Secure Boot on ESXi hosts to prevent installation of unsigned and unauthorized VIBs.\r\nFor more information on advanced mitigation strategies and comprehensive hardening of VMware infrastructure,\r\nsee the following Sygnia’s blog posts:\r\nESXi Ransomware Attacks: Evolution, Impact, and Defense Strategy\r\nBreaking the Virtual Barrier: From Web-Shell to Ransomware\r\nBy implementing these layered hardening strategies, organizations can significantly reduce their exposure to\r\nmodern attack techniques targeting virtualization infrastructure. These controls raise the cost and complexity of\r\ncompromise for both espionage-focused APTs and financially motivated ransomware operators, particularly in\r\nhigh-risk sectors such as telecommunications. \r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 11 of 12\n\nIf you were impacted by this attack or are seeking guidance on how to prevent similar attacks, please contact us at\r\ncontact@sygnia.co or our 24-hour hotline +1-877-686-8680.\r\nContributors: Sygnia IR and ES Teams\r\nThis advisory and any information or recommendation contained herein has been prepared for general\r\ninformational purposes and is not intended to be used as a substitute for professional consultation on facts and\r\ncircumstances specific to any entity. While we have made attempts to ensure the information contained herein has\r\nbeen obtained from reliable sources and to perform rigorous analysis, this advisory is based on initial rapid study,\r\nand needs to be treated accordingly. Sygnia is not responsible for any errors or omissions, or for the results\r\nobtained from the use of this Advisory. This Advisory is provided on an as-is basis, and without warranties of any\r\nkind.\r\nSource: https://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nhttps://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/"
	],
	"report_names": [
		"fire-ant-a-deep-dive-into-hypervisor-level-espionage"
	],
	"threat_actors": [
		{
			"id": "9df8987a-27fc-45c5-83b0-20dceb8288af",
			"created_at": "2025-10-29T02:00:51.836932Z",
			"updated_at": "2026-04-10T02:00:05.253487Z",
			"deleted_at": null,
			"main_name": "UNC3886",
			"aliases": [
				"UNC3886"
			],
			"source_name": "MITRE:UNC3886",
			"tools": [
				"MOPSLED",
				"VIRTUALPIE",
				"CASTLETAP",
				"THINCRUST",
				"VIRTUALPITA",
				"RIFLESPINE"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "a08d93aa-41e4-4eca-a0fd-002d051a2c2d",
			"created_at": "2024-08-28T02:02:09.711951Z",
			"updated_at": "2026-04-10T02:00:04.957678Z",
			"deleted_at": null,
			"main_name": "UNC3886",
			"aliases": [
				"Fire Ant"
			],
			"source_name": "ETDA:UNC3886",
			"tools": [
				"BOLDMOVE",
				"CASTLETAP",
				"LOOKOVER",
				"MOPSLED",
				"RIFLESPINE",
				"TABLEFLIP",
				"THINCRUST",
				"Tiny SHell",
				"VIRTUALGATE",
				"VIRTUALPIE",
				"VIRTUALPITA",
				"VIRTUALSHINE",
				"tsh"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "1c91699d-77d3-4ad7-9857-9f9196ac1e37",
			"created_at": "2023-11-04T02:00:07.663664Z",
			"updated_at": "2026-04-10T02:00:03.385989Z",
			"deleted_at": null,
			"main_name": "UNC3886",
			"aliases": [],
			"source_name": "MISPGALAXY:UNC3886",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775439028,
	"ts_updated_at": 1775791794,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/712d50a4fba826d692e7b2587e09eeb22372e4a3.pdf",
		"text": "https://archive.orkl.eu/712d50a4fba826d692e7b2587e09eeb22372e4a3.txt",
		"img": "https://archive.orkl.eu/712d50a4fba826d692e7b2587e09eeb22372e4a3.jpg"
	}
}