{
	"id": "1b97b0b1-45fc-4c75-8a5f-836ddd815489",
	"created_at": "2026-04-06T00:20:19.031521Z",
	"updated_at": "2026-04-10T03:29:54.656963Z",
	"deleted_at": null,
	"sha1_hash": "630d8558d14003645936fd5f7556ea99048ca914",
	"title": "VMware ESXi Zero-Day Used by Chinese Espionage Actor to Perform Privileged Guest Operations on Compromised Hypervisors | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1126415,
	"plain_text": "VMware ESXi Zero-Day Used by Chinese Espionage Actor to\r\nPerform Privileged Guest Operations on Compromised\r\nHypervisors | Mandiant\r\nBy Mandiant\r\nPublished: 2023-06-13 · Archived: 2026-04-05 17:20:19 UTC\r\nWritten by: Alexander Marvi, Brad Slaybaugh, Ron Craft, Rufus Brown\r\nRequires access to the hypervisor to exploit the vulnerability (e.g. through stolen ESXi credentials)\r\nAs Endpoint Detection and Response (EDR) solutions improve malware detection efficacy on Windows and\r\nLinux systems, certain state-sponsored threat actors have shifted to developing and deploying malware on systems\r\nthat do not generally support EDR such as network appliances, SAN arrays, and VMware ESXi hosts.\r\nIn late 2022, Mandiant published details surrounding a novel malware system deployed by UNC3886, a Chinese\r\ncyber espionage group, which impacted VMware ESXi hosts, vCenter servers, and Windows virtual machines\r\n(VM). Through continued security research and investigations over the past year, Mandiant has discovered\r\nadditional techniques UNC3886 has utilized across multiple organizations to keep out of the sights of EDR\r\nsolutions including:\r\nHarvesting credentials for service accounts from a vCenter Server for all connected ESXi hosts from the\r\nembedded vPostgreSQL server built into vCenter Server Appliance\r\nExploiting a zero-day vulnerability (CVE-2023-20867) that enabled the execution of privileged commands\r\nacross Windows, Linux, and PhotonOS (vCenter) guest VMs without authentication of guest credentials\r\nfrom a compromised ESXi host and no default logging on guest VMs\r\nDeploying backdoors on ESXi hosts using an alternative socket address family, VMCI, for lateral\r\nmovement and continued persistence. This address family enabled direct reconnection from any guest VM\r\nto the compromised ESXi host’s backdoor regardless of network segmentation or firewall rules in place.\r\nContinuing to tamper with and disable logging services on impacted systems, presenting additional\r\nchallenges to investigating UNC3886 in a compromised environment.\r\nThis blog post describes an expanded understanding of the attack path seen in Figure 1 and highlights the\r\nimplications of both the zero-day vulnerability (CVE-2023-20867) and VMCI communication sockets the attacker\r\nleveraged to complete their goal. In a followup post, we will provide artifacts present on hosts, which indicate\r\nhistorical attacker activity, optional logging to track Guest Operations at the guest level, and hardening\r\nsuggestions for both vCenter and ESXi solutions.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 1 of 12\n\nFigure 1: Expanded UNC3886 attack path\r\nBefore diving into how UNC3886 was able to harvest service account credentials for ESXi hosts on vCenter\r\nservers, the following section describes what is currently known about the threat actor associated with the attack\r\npath in Figure 1.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 2 of 12\n\nAttribution\r\nUNC3886 is a highly adept Chinese cyber espionage group that has targeted and exploited zero-day vulnerabilities\r\nin firewall and virtualization technologies, which do not support EDR solutions. UNC3886 has primarily targeted\r\ndefense, technology, and telecommunication organizations located in the US and APJ regions. Mandiant continues\r\nto observe UNC3886 leverage novel malware families and utilities that indicate the group has access to extensive\r\nresearch and support for understanding the underlying technology of appliances being targeted.\r\nWhile past Mandiant blog posts related to UNC3886 have shared atomic indicators like file names and hashes,\r\nthis particular attacker has been observed replacing indicators mentioned in publications in under a week after\r\ntheir release. For this reason, this blog post focuses on highlighting the tactics and methodologies utilized by the\r\nattacker with the aim to be able to detect and respond to this attack path regardless of the exact malware being\r\ndeployed or commands being run.\r\nThe following section ties in the usage of the vpxuser mentioned in this blog post and describes how the attacker\r\ngained these service account credentials for ESXi machines by targeting the vCenter server the ESXi hosts were\r\nconnected to.\r\nvCenter Exploitation\r\nIn Mandiant’s previous ESXi blog post, Figure 2 visualized how UNC3886 leveraged compromised ESXi hosts to\r\nexecute commands on guest VMs. The attack path shows the attacker using the vpxuser account credentials\r\nalong with the command it intended to execute on a guest VM as parameters to a Python script, e.py .\r\nFigure 2: vpxuser account usage\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 3 of 12\n\nMandiant has identified additional attacker scripts that enabled UNC3886 to obtain vpxuser credentials,\r\nenumerate ESXi hosts and their guest VMs, and manipulate connected ESXi host firewall rules. These scripts\r\nenabled the attacker to perform the following actions:\r\nObtain the cleartext passwords of all connected ESXi host’s vpxuser service accounts from a\r\ncompromised vCenter server through the connected vPostgreSQL database\r\nList all ESXi hosts that are attached to a vCenter server as well as the guest VMs that are hosted on each of\r\nthe attached ESXi hosts\r\nAdd or delete from the list of allowed IPs for a specified service (Default sshServer) across all connected\r\nESXi hosts\r\nEach of these scripts will be described in more detail in the following sections starting with how the attacker\r\nharvested the vpxuser credentials.\r\nvpxuser Credential Harvesting\r\nThe vpxuser account is a privileged service account created on an ESXi host automatically when it is first\r\nconnected to a vCenter server. The password for this user is encrypted and stored in the vPostgreSQL database on\r\na vCenter server and by default rotates automatically every 30 days. vCenter primarily uses this service account\r\nfor administrative actions such as moving VMs between different ESXi hosts and modifying the configurations of\r\nrunning VMs. UNC3886 utilized this service account to deploy malicious vSphere Installation Bundles (VIB) that\r\ncontained either the VIRTUALPITA or VIRTUALPIE backdoor.\r\nIn March 2022, Pentera researcher Yuval Lazar published guidance related to the privilege escalation\r\nvulnerability, CVE-2022-22948, which described how the vpxuser credentials can be harvested on a vCenter\r\nserver. While this vulnerability has been patched since the guidance was released, it is still possible to retrieve the\r\nencrypted credentials of the vpxuser and crack them if the attacker was able to gain root access to the vCenter\r\nserver.\r\nESXi Host and Guest Machine Enumeration\r\nOnce the vpxuser credentials were acquired, the attacker used an additional script to map out the ESXi hosts and\r\ntheir respective guest VMs. The contents of the recovered Python script utilized the same vPostgreSQL database\r\nwhere the vpxuser credentials are stored to list all ESXi hosts that are attached to the vCenter server as well as\r\nthe guest VMs that are hosted on each ESXi host.\r\nvCenter to ESXi Host Firewall Manipulation\r\nWith the available ESXi hosts and guest VMs identified, another attacker python script was used to update the\r\nallowed list of IP addresses for any service across all ESXi hosts connected to the vCenter server this script was\r\nrun against. This allowed the attacker to make quick changes to multiple ESXi hosts firewalls’ at once and by\r\ndefault would enable IP addresses provided to SSH directly to the ESXi hosts. It also provided the attacker with an\r\neasy way to cover their tracks by removing that same IP address once a malicious VIB was deployed, offering\r\nalternative means to reconnect later.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 4 of 12\n\nWith the attacker’s remote SSH access and the credentials for the vpxuser service account, the ESXi hosts were\r\nconnected to and persistent backdoors were deployed. The attacker deployed these backdoors through VIB, which\r\nenabled the malware packaged inside to be executed each time the ESXi host was restarted. The VIBs contained\r\nthe VIRTUALPITA and VIRTUALPIE backdoors, which listened on either TCP or VMCI ports.\r\nThe attacker scripts used to install these VIBs, perform anti-forensics to hide these installations, and exploit CVE-2023-20867 to perform unauthenticated Guest Operations are described in the following section.\r\nESXi Host Exploitation\r\nMalicious VIB Installation\r\nAs additional investigations into UNC3886 progressed, Mandiant recovered installation scripts that UNC3886\r\nused to deploy malicious VIBs to ESXi hosts. While previous blog posts Mandiant released suggested that the\r\nattacker utilized timestomping to hide their activity, as seen through specific events in the vmkwarning.log , the\r\nscripts discovered by Mandiant were able to confirm exactly how the attackers derived the time that was used to\r\ntimestomp before installing the malicious VIBs.\r\nThe installation scripts performed the following actions on the targeted ESXi host:\r\n1. Saved the current firewall state and system time\r\n2. Disabled the firewall\r\n3. Set the VIB acceptance level to PartnerSupported\r\n4. Retrieved the VIB install time from the file: /var/db/esximg/vibs/esx-base-*.xml\r\n5. Set the system clock to the retrieved VIB install time\r\n6. Installed the malicious VIB(s) with the command: esxcli software vib install -f --no-sig-check\r\n7. Re-enabled the firewall\r\n8. Set the system clock back to the current date and time\r\nMandiant previously noted in 2022 that it did not identify evidence of a CVE being exploited during past\r\ninvestigations. As investigations into UNC3886 activity continued in 2023, Mandiant discovered that the attacker\r\nutilized a zero-day vulnerability, CVE-2023-20867, to execute commands and transfer files to and from guest\r\nVMs from a compromised ESXi host without the need for guest credentials. Additionally, the use of CVE-2023-\r\n20867 does not generate an authentication log event on the guest VM when commands are executed from the\r\nESXi host. Mandiant worked closely with VMware to responsibly disclose this vulnerability. For more\r\ninformation on this vulnerability, please see VMware’s advisory, VMSA-2023-0013.\r\nBefore explaining how CVE-2023-20867 impacted ESXi hosts and connected guest machines, the concept of\r\nVMware Guest Operations, the API that this exploit impacts, is explained in further detail as follows.\r\nVMware Guest Operations Explained\r\nTo interact with guest VMs running on compromised ESXi hosts, the attackers utilized VMware tools (vmtools)\r\nGuest Operations to interact with the VMs provisioned through the ESXi host. Vmtools Guest Operations are a\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 5 of 12\n\nfeature of the vSphere API, which allow for different types of host-to-guest interactions. A list of all different\r\nGuest Operations can be seen in Table 1. (Here is a full list of GuestOperationsManager API Calls.)\r\nManaged Object Methods Description\r\nGuestAliasManager\r\nAddGuestAlias define alias for guest account\r\nListGuestAliases list guest aliases for specified user\r\nListGuestMappedAliases list alias map for in-guest user\r\nRemoveGuestAliasByCert\r\nremove certificate associated\r\naliases\r\nGuestAuthManager\r\nAcquireCredentialsInGuest authenticate, return session object\r\nReleaseCredentialsInGuest release session object\r\nValidateCredentialsInGuest\r\ncheck authentication data or\r\ntimeout\r\nGuestFileManager\r\nChangeFileAttributesInGuest change attributes of file in guest\r\nCreateTemporaryDirectoryInGuest make a temporary directory\r\nCreateTemporaryFileInGuest create a temporary file\r\nDeleteDirectoryInGuest remote directory in guest OS\r\nDeleteFileInGuest remove file in guest OS\r\nInitiateFileTransferFromGuest start file transfer from guest OS\r\nInitiateFileTransferToGuest start file transfer to guest OS\r\nListFilesInGuest list files or directories in guest\r\nMakeDirectoryInGuest make a directory in guest\r\nMoveDirectoryInGuest\r\nmove or rename a directory in\r\nguest\r\nMoveFileInGuest rename a file in guest\r\nGuestWindowsRegistryManager CreateRegistry KeyInGuest create a registry key\r\nDeleteRegistryKeyInGuest delete a registry key\r\nDeleteRegistryValueInGuest delete a registry value\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 6 of 12\n\nListReeistryKeysInGuest list registry subkeys for a given key\r\nListRegistryValuesInGuest list registry values for a given key\r\nSetRegistryValueInGuest set or create a registry value\r\nGuestProcessManager\r\nListProcessesInGuest list processes running in guest OS\r\nReadEnvironmentVariableInGuest read environment variable in guest\r\nStartProgramInGuest start running program in guest\r\nTerminateProcessInGuest stop a running process in guest\r\nTable 1: List of vmtools Guest Operations\r\nNormally, to run a Guest Operation, an administrator would need to authenticate with the guest machine through\r\none of the following methods:\r\nNamePasswordAuthentication\r\nSAMLTokenAuthentication\r\nSSPIAuthentication\r\nTicketedSessionAuthentication\r\nMandiant noted that UNC3886 conducted Guest Operations API calls when interacting with VMs from the ESXi\r\nhost. During those investigations, Mandiant did not find evidence of authentication events, such as a Windows\r\n4624 Event ID in the Security log, when the attacker interacted with guest VMs from the ESXi host. As\r\ninvestigations into UNC3886 intrusions continued, Mandiant found new evidence that the attacker was able to\r\nbypass authenticating with guest VMs on the ESXi host when performing guest operations, and therefore, not\r\ngenerating any authentication events in available logs upon successful exploitation. This information was\r\nresponsibly disclosed to VMware and, once a patch was created, was designated the label CVE-2023-20867,\r\nwhich is described in further detail in the following section.\r\nCVE-2023-20867 — Unauthenticated Guest Operations from ESXi Host to Guest Machine\r\nCVE-2023-20867 allowed the attacker to execute privileged Guest Operations on guest VMs from a compromised\r\nESXi host without the need to authenticate with the guest VM by targeting the authentication check mechanism.\r\nAdditionally, the exploit bypasses traditional logging actions performed on either the ESXi host or the guest VM.\r\nThe only requirements needed to exploit this vulnerability are as follows:\r\nThe attacker has privileged account access (such as root or the vpxuser ) to the ESXi host\r\nThe target guest machine has VMware Tools software installed\r\nThis exploit was able to perform successful unauthenticated Guest Operations on both Windows, Linux, and\r\nPhotonOS (vCenter) guests. The attacker accomplished the exploit by running a Python script, which injects into\r\nthe running /bin/vmx process, specifically targeting the userCredentialType that performs the authentication\r\nchecks before executing a guest operation.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 7 of 12\n\nFigure 3 displays the source code of vixCommand.h from GitHub and defines 10 authentication types built into\r\nvmtools. The default challenge produced when attempting to perform a guest operation requires a username and\r\npassword (VIX_USER_CREDENTIAL_NAME_PASSWORD - Type 1) before the Guest Operation can be\r\ncompleted. The exploit changes the userCredentialType challenge to Type 3, which does not perform any\r\nauthentication checks before performing the Guest Operation.\r\nFigure 3: VixCommand userCredentialTypes\r\nMandiant’s investigation into UNC3886 uncovered additional Python scripts, which enabled them to execute\r\nactions across the guest VMs from the compromised ESXi hosts. The attacker used the Python scripts seen in\r\nTable 2 to modify the /bin/vmx process and perform multiple types of Guest Operations.\r\nFilename Description\r\ne.py StartProgramInGuest - Executes commands on a guest VM from an ESXi host\r\nd.py\r\nInitiateFileTransferFromGuest - Download files from a specified directory on a guest VM to the\r\nESXi host\r\nl.py\r\nlf.py\r\nListFilesInGuest - List all files in a specified directory on a guest VM from an ESXi host\r\nlp.py ListProcessesInGuest - List all running processes on a guest VM from an ESXi host\r\np.py\r\nExploits CVE-2023-20867 by modifying a single byte in the /bin/vmx process to bypass\r\nauthentication on the guest VM when interacting with it from the host\r\npall.py Similar functionality to p.py with extended compatibility for ESXi versions prior to 6.0\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 8 of 12\n\nu.py\r\nInitiateFileTransferToGuest – Uploads a file to a specified directory on a guest VM from an\r\nESXi host\r\nTable 2: List of attacker Python scripts utilizing VMware Tools Guest Operation API calls\r\nAs mentioned, access to an administrative account such as the vpxuser or root account of the ESXi host and\r\nvmtools installed on the guest VM are required for this exploit to succeed. The p.py script discovered during\r\nUNC3886 investigations allows the attacker to exploit CVE-2023-20867 to bypass authentication on the guest\r\nVM from the compromised ESXi host. Meanwhile, any guest VM that the attacker attempts to access through this\r\nvulnerability that doesn’t have vmtools installed will result in a failed login attempt. However, once the attacker\r\nhas privileged access to the ESXi host, the attacker has the capability to install vmtools on any of the guest VMs.\r\nCurrently, no logging events are generated by default when CVE-2023-20867 is successfully exploited. A\r\nsuccessful execution of Guest Operations on a Windows guest VM does not generate a 4624 or 4634 Windows\r\nEvent ID within Windows since the exploit bypasses any requirement for authentication checks on the guest VM.\r\nOn Linux, the successful execution of Guest Operations using this exploit results in no actions being logged in the\r\nLinux access logs.\r\nFurther guidance on how to enable logging and detect both failed and successful attempts of exploitation will be\r\nfound in the followup to this blog post.\r\nVMCI Socket Abuse\r\nWhat is a VMCI Socket?\r\nOver the past year Mandiant has observed UNC3886 deploy multiple backdoors (VIRTUALGATE and\r\nVIRTUALPITA) using VMCI sockets for lateral movement and continued persistence. While this topic was\r\ncovered briefly when defining VIRTUALGATE in the previous blog post, Mandiant conducted additional research\r\nto highlight what VMCI sockets are, what unique capabilities they provide the attacker, and options to potentially\r\ndetect them.\r\nAt a high level, VMCI sockets are end points that enable low latency and high throughput communication\r\nbetween the ESXi host and its guest VMs over a channel localized on the bare metal machine running the ESXi\r\nhost. Since this traffic is localized to the bare metal machine, there are no security mechanisms restricting any\r\nguest VM or ESXi host from initiating a connection with the other, as seen in Figure 4. Additionally, no traffic can\r\nbe monitored outside of the guest VM’s and ESXi hosts present in the virtualized environment. While the\r\nclient/server communication socket has connection-oriented and connectionless variants very similar to TCP and\r\nUDP, it is invisible to commonly used networking tools such as tcpdump, netstat, nmap, and Wireshark without\r\ncustom configurations as it belongs to a different socket address family.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 9 of 12\n\nFigure 4: Overview of attacker’s use of ESXi Hypervisor VMCI Communications\r\nBefore diving into VMCI routing and communications, the following section provides some background context\r\nthat needs to be provided on what sockets are and how they are further categorized with address families to\r\nunderstand why default configurations on networking tools do not pick up VMCI activity.\r\nSocket Address Family Definition\r\nA socket is a two-way communication channel that acts as an endpoint to send and receive data between multiple\r\nprocesses within one machine or across multiple machines within a network.\r\nSince sockets only send and receive information, standards needed to be formulated so information received could\r\nbe interpreted correctly. Socket address families were created as standardized data structure formats to produce\r\nagnostic communications over data sockets. Common address families include AF_INET and AF_UNIX, though\r\nVMCI sockets fall within their own address family. What is important to remember is that a program must have\r\ncode to interpret and acknowledge information being passed to sockets, if the information does not meet the\r\ncriteria of the address family being expected, it will likely be dropped/ignored. \r\nVMCI Routable Identifiers \r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 10 of 12\n\nSimilar to how private IP addresses are used to uniquely identify endpoints on a local network, VMCI sockets\r\nutilize an endpoint identifier called a Context ID (CID) to route traffic throughout the virtualized environment.\r\nThe ESXi host will always have two static CIDs:  \r\n0 – The CID with VMCI sockets only visible to the ESXi host  \r\n2 – The CID that is routable to and from the guest machines when a VMCI socket is open \r\nThe CID for each guest virtual machine can be found on the ESXi host within the .vmx file for the virtual machine\r\nunder  /vmfs/volume/\u003cVolume-ID\u003e/\u003cVirtual-Machine-Name\u003e.vmx . The following lines within the .vmx file can be\r\nused to acquire the CID of the VM:\r\nvmci0.id = \"\u003cCID\u003e\"\r\nHow Can the Attacker Utilize This? \r\nMandiant has confirmed UNC3886’s use of multiple VMCI backdoors deployed as malicious VIBs on ESXi\r\nhosts. This open communication channel between guest and host, where either role can act as client or server, has\r\nenabled a new means of persistence to regain access on a backdoored ESXi host as long as a backdoor is deployed\r\nand the attacker gains initial access to any guest machine. This is attractive to the attacker for a multitude of\r\nreasons including but not limited to: \r\nThe ability to bypass network segmentation normally needed to access the ESXi host  \r\nCircumventing most security reviews for open listening ports and odd NetFlow behavior \r\nRegaining access to the ESXi host only requires access to any virtual machine \r\nIn conjunction with the CVE-2023-20867, once the attacker regains access to the ESXi host they can\r\nperform unauthenticated actions with the highest privileged accounts across any virtual machine running\r\nunderneath that ESXi host \r\nIf a vCenter exists as a virtual machine underneath the ESXi host, the attacker can proceed to harvest all\r\nconnected vpxuser credentials for all ESXi hosts connected to the vCenter and continue to laterally pivot\r\nacross the environment. \r\nConclusion \r\nAs Mandiant continues to investigate UNC3886, this blog post further reinforces UNC3886's deep understanding\r\nand technical knowledge of ESXi, vCenter and VMware’s virtualization platform. UNC3886 continues to target\r\ndevices and platforms that traditionally lack EDR solutions and make use of zero-day exploits on those platforms.\r\nUNC3886 continues to present challenges to investigators by disabling and tampering with logging services,\r\nselectively removing log events related to their activity. The threat actors’ retroactive cleanup performed within\r\ndays of past public disclosures on their activity indicates how vigilant they are. Organizations must remain\r\nvigilant and ensure that they’re not only monitoring their network at the operating system layer, but also continue\r\nto patch, maintain, and monitor the appliances that are running the underlying infrastructure. \r\nAcknowledgements \r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 11 of 12\n\nSpecial thanks to Moritz Raabe, Joshua Kim, Matthew Maczko, Maegan Palombo, DJ Palombo, Jeremy Koppen,\r\nand Charles Carmakal for their assistance with the investigation, technical review, and creating detections for the\r\nmalware families discussed in this blog post. In addition, we would also like to thank VMware for their\r\ncollaboration and assistance with this research.\r\nPosted in\r\nThreat Intelligence\r\nSource: https://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://cloud.google.com/blog/topics/threat-intelligence/vmware-esxi-zero-day-bypass/"
	],
	"report_names": [
		"vmware-esxi-zero-day-bypass"
	],
	"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": 1775434819,
	"ts_updated_at": 1775791794,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/630d8558d14003645936fd5f7556ea99048ca914.pdf",
		"text": "https://archive.orkl.eu/630d8558d14003645936fd5f7556ea99048ca914.txt",
		"img": "https://archive.orkl.eu/630d8558d14003645936fd5f7556ea99048ca914.jpg"
	}
}