{
	"id": "df11a387-b4a4-4dce-ba61-b5c1ca9a9c08",
	"created_at": "2026-04-06T00:21:56.658708Z",
	"updated_at": "2026-04-10T03:29:54.635841Z",
	"deleted_at": null,
	"sha1_hash": "daee4474bc83516f30465f644b30487d68022109",
	"title": "Malware Persistence Within ESXi Hypervisors | Malicious VIBs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 800434,
	"plain_text": "Malware Persistence Within ESXi Hypervisors | Malicious VIBs\r\nBy Mandiant\r\nPublished: 2022-09-29 · Archived: 2026-04-05 20:26:23 UTC\r\nWritten by: Alexander Marvi, Jeremy Koppen, Tufail Ahmed, Jonathan Lepore\r\nAs endpoint detection and response (EDR) solutions improve malware detection efficacy on Windows systems,\r\ncertain state-sponsored threat actors have shifted to developing and deploying malware on systems that do not\r\ngenerally support EDR such as network appliances, SAN arrays, and VMware ESXi servers.\r\nEarlier this year, Mandiant identified a novel malware ecosystem impacting VMware ESXi, Linux vCenter servers,\r\nand Windows virtual machines that enables a threat actor to take the following actions:\r\n1. Maintain persistent administrative access to the hypervisor\r\n2. Send commands to the hypervisor that will be routed to the guest VM for execution\r\n3. Transfer files between the ESXi hypervisor and guest machines running beneath it\r\n4. Tamper with logging services on the hypervisor\r\n5. Execute arbitrary commands from one guest VM to another guest VM running on the same hypervisor\r\nThis malware ecosystem was initially detected when Mandiant Managed Defense identified attacker commands\r\nsourced from the legitimate VMware Tools process, vmtoolsd.exe , on a Windows virtual machine hosted on a\r\nVMware ESXi hypervisor. Mandiant analyzed the boot profile for the ESXi hypervisors and identified a never-before-seen technique in which a threat actor leveraged malicious vSphere Installation Bundles (“VIBs”) to install\r\nmultiple backdoors on the ESXi hypervisors. We call these backdoors VIRTUALPITA and VIRTUALPIE (Figure\r\n1).\r\nFigure 1: Visualization of ESXi attack path\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 1 of 14\n\nIt is important to highlight that this is not an external remote code execution vulnerability; the attacker needs admin-level privileges to the ESXi hypervisor before they can deploy malware. Mandiant has no evidence of a zero-day\r\nvulnerability being used to gain initial access or deploy the malicious VIBs at the time of writing this post.\r\nDetails on how to manually detect if malicious or anomalous VIBs are currently installed in your ESXi environment\r\nare outlined in our hardening blog post. VMware has released additional information on protecting vSphere. \r\nvSphere Installation Bundles (VIB)\r\nMandiant identified two (2) new malware families installed through malicious vSphere Installation Bundles (VIBs),\r\nwhich we have named VIRTUALPITA and VIRTUALPIE.\r\nVMware VIBs are collections of files that are designed to facilitate software distribution and virtual system\r\nmanagement. Since ESXi utilizes an in-memory filesystem, file edits are not saved across reboots. A VIB package\r\ncan be used to create startup tasks, custom firewall rules, or deploy custom binaries upon the restart of an ESXi\r\nmachine. These packages are generally utilized by administrators to deploy updates and maintain systems; however,\r\nthis attacker was seen leveraging the packages as a persistence mechanism to maintain access across ESXi\r\nhypervisors.\r\nVIBs can be broken down into three (3) components:\r\nAn XML descriptor file\r\nA “VIB payload” (.vgz archive)\r\nA signature file – A digital signature used to verify the host acceptance level of a VIB\r\nThe XML Descriptor File is a config which contains references to the following:\r\nThe payload to be installed\r\nVIB metadata, such as the name and install date\r\nThe signature file that belongs to the VIB\r\nThe VIB payload is a .vgz archive which contains directories and files that will be created on the ESXi machine\r\nthrough the VIB. These files can then be called on to execute on boot when the VIBs are loaded.\r\nThe signature file is used to verify the host acceptance level of a VIB. The acceptance level is the digital signature\r\nsystem used by VMware to specify what testing has been done by VMware or partners before a VIB is published.\r\nAcceptance levels are set for hosts, image profiles, and individual VIBs. The four (4) acceptance levels along with\r\ntheir XML Descriptor short names are listed below:\r\nVMWareCertified (certified)\r\nVMwareAccepted (accepted)\r\nPartnerSupported (partner)\r\nCommunitySupported (community)\r\nPer VMware documentation, the default minimum acceptance level a VIB needs to be installed on a ESXi host is\r\nPartnerSupported . This acceptance level indicates the VIBs are published by a partner that VMware trusts. While\r\nthis is the default acceptance level, it can be changed manually by an ESXi administrative account. The command\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 2 of 14\n\nused to install VIBs esxcli software vib install does not normally allow installations below the minimum\r\nacceptance level, but the --force flag can be used to ignore any systems acceptance level requirements when\r\ninstalling the VIB.\r\nThe malicious VIBs observed were labelled as PartnerSupported . Mandiant’s review of the Signature Files\r\ndetermined they were empty, and that an attacker modified the XML descriptor file to change the acceptance-level field from community to partner . A CommunitySupported acceptance-level indicates that the VIB was\r\ncreated by a third party which was not reviewed nor signed by VMware or its trusted partners. This indicated the\r\nattacker masqueraded these VIB files as PartnerSupported even though they only met the requirements of a\r\nCommunitySupported VIB. This also indicated that the VIB was created by an individual or company outside of\r\nVMware partner programs and has not gone through any VMware-approved testing program. Figure 2 contains an\r\nexcerpt of the modified XML descriptor file that was identified.\r\nFigure 2: Modified Descriptor XML\r\nWhile the acceptance-level field was modified in the Descriptor XML by the attacker, the ESXi system still did\r\nnot allow for a falsified VIB file to be installed below the minimal set acceptance level. To circumvent this, the\r\nattacker abused the --force flag to install malicious CommunitySupported VIBs.\r\nTesting confirmed that modified fields from the XML descriptor file reflected the changes made in the output of\r\ncommands used to list and verify VIBs. This included the modification of the \u003cacceptance-level\u003e field which\r\ntricks the command, esxcli software vib list , into displaying the incorrect acceptance level of the installed\r\nVIBs. The VMware command, esxcli software vib signature verify , verifies the signatures of installed VIB\r\npackages and displays the following fields:\r\nVIB Name\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 3 of 14\n\nVersion\r\nVendor\r\nAcceptance Level\r\nThe result of the VIB’s signature verification\r\nMandiant confirmed that this command detected when these acceptance levels were falsified, which identified the\r\nmalicious VIBs. This command displays the acceptance level specified by the XML descriptor file, but the\r\nSignature Verification column clarifies if the signature file did not match the respective Descriptor XML. If the\r\nsignature cannot be verified, the Signature Verification column will contain the value Signature Not\r\nAvailable: Host may have been upgraded from an older ESXi version . An example of this can be seen in Figure\r\n3.\r\nFigure 3: Example of falsified VIB acceptance level being seen in esxcli software vib signature verify\r\nVIRTUALPITA (VMware ESXi)\r\nVIRTUALPITA is a 64-bit passive backdoor that creates a listener on a hardcoded port number on a VMware ESXi\r\nserver. The backdoor often utilizes VMware service names and ports to masquerade as a legitimate service. It\r\nsupports arbitrary command execution, file upload and download, and the ability to start and stop vmsyslogd .\r\nDuring arbitrary command execution, the malware also sets the environmental variable  HISTFILE to 0 to further\r\nhide activity that occurred on the machine. Variants of this malware were found to listen on a Virtual Machine\r\nCommunication Interface (VMCI) and log this activity to the file sysclog .\r\nVIRTUALPIE (VMware ESXi)\r\nVIRTUALPIE is a lightweight backdoor written in Python that spawns a daemonized IPv6 listener on a hardcoded\r\nport on a VMware ESXi server. It supports arbitrary command line execution, file transfer capabilities, and reverse\r\nshell capabilities. Communications use a custom protocol and are encrypted using RC4.\r\nThe first malicious VIB named lsu-lsi-lsi-mrarpid-plugin referenced the payload lsu_lsi_.v05 (MD5:\r\n2716c60c28cf7f7568f55ac33313468b) which contained the following three (3) files for which details can be found\r\nin Table 1:\r\n/etc/rc.local.d/vmware_local.sh (MD5: bd6e38b6ff85ab02c1a4325e8af29ce4)\r\n/bin/rdt (MD5: 8e80b40b1298f022c7f3a96599806c43)\r\n/bin/vmsyslog.py (MD5: 61ab3f6401d60ec36cd3ac980a8deb75)\r\nFile Name Description\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 4 of 14\n\nvmware_local.sh\r\nA bash installation script to be placed into /etc/rc.local.d/ to ensure its actions will be\r\nexecuted upon each bootup of ESXi. Uses the esxcli command line utility to enable a\r\nfirewall rule for backdoor traffic, execute both backdoors, and remove every file created by\r\nthe VIB from the disk.\r\nrdt\r\nAn ELF backdoor (VIRTUALPITA) that creates a listener on the hard coded TCP port\r\n2233. Capable of arbitrary command execution, file transfer capabilities and the ability to\r\nstart/stop vmsyslogd . VMWare documentation recorded this port is normally utilized by\r\nthe vSAN reliable datagram transport (RDT) service on the ESXi version which was\r\nreviewed.\r\nvmsyslog.py\r\nA lightweight backdoor (VIRTUALPIE) written in Python that spawns a daemonized IPv6\r\nlistener the hardcoded port 546. Capable of arbitrary command line execution, file transfer\r\ncapabilities, and reverse shell capabilities. Communications use a custom protocol and are\r\nencrypted using RC4.\r\nTable 1: Lsu-lsi-lsi-mrarpid-plugin Malicious VIB contents\r\nThe second malicious VIB named ata-pata-pdc20211 referenced the payload payload1.v00 (MD5:\r\n9ea86dccd5bbde47f8641b62a1eeff07) which contained the following two (2) files for which details can be found in\r\nTable 2:\r\n/etc/rc.local.d/vmware_rhttpio.sh (MD5: 9d5cc1ee99ccb1ec4d20be1cee10173e)\r\n/usr/lib/vmware/weasel/consoleui/rhttpproxy-io (MD5: 2c28ec2d541f555b2838099ca849f965)\r\nFile Name Description\r\nvmware_rhttpio.sh\r\nA bash installation script to be placed into /etc/rc.local.d/ to ensure its actions will\r\nbe executed upon each bootup of ESXi. This script executes the ELF backdoor\r\nrhttpproxy-io\r\nAn ELF backdoor (VIRTUALPITA) that creates a listener on the hard coded VMCI\r\nsocket port 18098. Capable of arbitrary command execution, file transfer capabilities and\r\nthe ability to start/stop vmsyslogd. The following sample generates an additional log not\r\nseen in other samples which fetches the systems context ID (CID).\r\nThe generated log /var/log/sysclog records in the following format\r\n[\u003cdate/timestamp\u003e]\\n\\r[!]\u003c\u003cPID\u003e\u003e:\u003cCID\u003e:\u003cport\u003e\\n\\n\r\nTable 2: Lsu-lsi-lsi-mrarpid-plugin Malicious VIB contents\r\nVIRTUALPITA (LINUX)\r\nMandiant discovered two (2) additional VIRTUALPITA samples listening on TCP port 7475 that were persistent as\r\nan init.d startup service on Linux vCenter systems. To disguise themselves, the binaries shared the name of the\r\nlegitimate binary ksmd . KSMD (Kernel Same-Page Merging Daemon) is normally in charge of memory-saving\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 5 of 14\n\nde-duplication on Linux and would not be listening on this port. The samples were found under the following\r\ndirectories:\r\n/usr/libexec/setconf/ksmd (MD5: 744e2a4c1da48869776827d461c2b2ec)\r\n/usr/bin/ksmd (MD5: 93d50025b81d3dbcb2e25d15cae03428)\r\nThese backdoors were capable of arbitrary command execution, file transfer capabilities and the ability to start/stop\r\nvmsyslogd.\r\nVIRTUALGATE (Windows)\r\nThe Windows guest virtual machines which were hosted by the infected hypervisors also contained a unique\r\nmalware sample located at C:\\Windows\\Temp\\avp.exe . This malware, which we refer to as VIRTUALGATE, is a\r\nutility program written in C that is comprised of two (2) parts, a dropper, and the payload. The memory only\r\ndropper deobfuscates a second stage DLL payload that uses VMware's virtual machine communication interface\r\n(VMCI) sockets to run commands on a guest virtual machine from a hypervisor host, or between guest virtual\r\nmachines on the same host.\r\nCommand Execution through vmtoolsd.exe\r\nReviewing the ESXi hypervisors during an active attacker event, Mandiant identified an attacker executed\r\ncommands to the guest machines through the process /bin/rdt (VIRTUALPITA). The parent process /bin/rdt\r\nspawned a bash shell which called on a python script specifying the target guest machine and commands to run as\r\nseen in Figure 4.\r\n-\u003e /bin/rdt -i\r\n....-\u003e sh -c /bin/sh\r\n........-\u003e /bin/sh\r\n...........-\u003e python e.py 127.0.0.1 vpxuser \u003cpassword\u003e \u003ctarget guest machine\u003e C:\\Windows\\system32\\cmd.exe /c dir\r\nFigure 4: Commands executed by attacker on ESXi Hypervisor\r\nCommands passed as arguments into e.py were also seen being executed by the targeted Windows guest machine,\r\nrunning as a child process under vmtoolsd.exe . This execution chain can be seen in Figure 5. The parent binary\r\n/bin/rdt was not present on disk but was able to be recovered by dumping the processes memory of the ESXi\r\nhypervisor. The python script that sent out commands to the guest machines, e.py , was unable to be recovered.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 6 of 14\n\nFigure 5: vmtoolsd.exe executing commands passed by ESXi\r\nThe commands the attacker ran through vmtoolsd.exe on the guest virtual machines were primarily focused on\r\nthe enumeration and compression of files across both the system and connected file shares utilizing the native tools\r\n“dir” and “makecab”. Samples of these redacted commands can be seen in Figure 6.\r\nC:\\Windows\\system32\\cmd.exe\" /c dir /od /s /a s:\\ \u003e C:\\Windows\\Temp\\ts_\u003cREDACTED\u003e.tmp 2\u003enull\r\nC:\\Windows\\System32\\cmd.exe makecab /F C:\\Windows\\Temp\\TS_\u003cREDACTED\u003e.txt /D compressiontype=lzx /D compressionm\r\nFigure 6: File enumeration and compression commands utilized by attacker on Guest Virtual Machines\r\nMandiant also identified the attacker targeting a virtualized system for credential harvesting. The attacker used\r\nMiniDump to dump process memory and search for cleartext credentials. Figure 7 shows an excerpt of these\r\ncommands.\r\n-- “ C:\\Program Files\\VMware\\Vmware Tools\\vmtoolsd.exe”\r\n---- “C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe”\r\n------ rundll32.exe C:\\windows\\System32\\comsvcs.dll MiniDump \u003cProcess ID\u003e C:\\Windows\\Temp\\TS_\u003cREDACTED\u003e.tmp full\r\nFigure 7: Credential Dumping on Guest Machine\r\nOnce the process memory was dumped, a powershell script was used to parse the resultant file for any cleartext\r\ncredentials. Figure 8 shows the contents of script used for credential harvesting. The attacker also targeted KeyPass\r\npassword database files.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 7 of 14\n\n$b = New-Object System.IO.streamReader(\"C:\\windows\\Temp\\\u003cREDACTED\u003e.tmp\",[Text.Encoding]::UTF8)\r\n$n = 0\r\nwhile (($b1 =$b.ReadLine()) -ne $null)\r\n{\r\n if($b1 -like '*\u0026password=*'){\r\n $n++\r\n Write-Host \"YES $n\"\r\n Write-Host $b1\r\n }\r\n \r\n}\r\nif($n -eq 0){Write-Host \"NO!\"}\r\n$b.Dispose()\r\nFigure 8: PowerShell Password Search Script\r\nThe attacker cleared the C:\\Windows\\Temp directory following most activity, but small errors were made which left\r\nbehind trace artifacts. As shown in Figure 9, the attacker sent the output of a dir listing to a .tmp file. Since the\r\nattacker used the Linux syntax (2\u003enull) to suppress errors instead of the Windows syntax (2\u003enul), all errors were\r\nforwarded to the file null in the working directory C:\\Windows\\System32\\null . This file was only created if a file\r\nenumerated with the dir command had a directory path too long to be displayed.\r\nC:\\Windows\\system32\\cmd.exe\" /c dir /od /s /a s:\\ \u003e C:\\Windows\\Temp\\TS_\u003cREDACTED\u003e.tmp 2\u003enull\r\nFigure 9: Failed writing Error to Null in Windows Command\r\nAttribution\r\nMandiant has begun tracking this activity as UNC3886. Given the highly targeted and evasive nature of this\r\nintrusion, we suspect UNC3886 motivation to be cyber espionage related. Additionally, we assess with low\r\nconfidence that UNC3886 has a China-nexus. Each investigation conducted by Mandiant includes analysts from our\r\nAdvanced Practices team who work to correlate activity observed in the thousands of investigations to which\r\nMandiant responds. At times, we do not have the data available to directly attribute intrusion activity to a previously\r\nknown group. In these cases, we create a new UNC group to track the activity that we observed. An UNC group is a\r\ncluster of related cyber intrusion activity, which includes observable artifacts such as adversary infrastructure, tools,\r\nand tradecraft, that we are not yet ready to give a classification such as APT or FIN. For more details on how\r\nMandiant uses UNC groups, see our blog post: DebUNCing Attribution: How Mandiant Tracks Uncategorized\r\nThreat Actors.\r\nConclusion\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 8 of 14\n\nWhile we noted the technique used by UNC3886 requires a deeper level of understanding of the ESXi operating\r\nsystem and VMWare’s virtualization platform, we anticipate a variety of other threat actors will use the information\r\noutlined in this research to begin building out similar capabilities. Mandiant recommends organizations using ESXi\r\nand the VMware infrastructure suite follow the hardening steps outlined in this blog post to minimize the attack\r\nsurface of ESXi hosts.\r\nMITRE ATT\u0026CK Techniques\r\nCollection\r\nT1560: Archive Collected Data \r\nT1560.001:  Archive via Utility   \r\nExecution\r\nT1059: Command and Scripting Interpreter \r\nT1059.001: PowerShell \r\nT1059.003: Windows Command Shell \r\nT1059.004: Unix Shell \r\nT1059.006: Python \r\nT1129: Shared Modules \r\nCommand and Control\r\nT1105: Ingress Tool Transfer \r\nT1573.001: Symmetric Cryptography   \r\nDefense Evasion\r\nT1027: Obfuscated Files or Information \r\nT1070: Indicator Removal on Host \r\nT1070.003: Clear Command History \r\nT1070.004: File Deletion \r\nT1140: Deobfuscate/Decode Files or Information \r\nT1202: Indirect Command Execution \r\nT1218.011: Rundll32 \r\nT1497: Virtualization/Sandbox Evasion \r\nT1497.001: System Checks \r\nT1620: Reflective Code Loading \r\nDiscovery\r\nT1016: System Network Configuration Discovery \r\nT1083: File and Directory Discovery \r\nLateral Movement\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 9 of 14\n\nT1021: Remote Services  \r\nT1021.004: SSH \r\nCredential Access\r\nT1003: OS Credential Dumping \r\nT1003.001: LSASS Memory \r\nPersistence\r\nT1547: Boot or Logon Autostart Execution\r\nIndicators of Compromise\r\nType Value Description\r\nMD5\r\nSHA1\r\nSHA256\r\n2716c60c28cf7f7568f55ac33313468b\r\n5ffa6d539a4d7bf5aacc4d32e198cc1607d4a522 \r\n2be5f4520846bf493b4694789841907d058fe08d59fff6bad7abe1db8ed96e7d \r\nMalicious VIB\r\n.vgz Payload\r\nMD5\r\nSHA1\r\nSHA256\r\nbd6e38b6ff85ab02c1a4325e8af29ce4\r\n17fb90d01403cb3d1566c91560f8f4b7dd139aa8 \r\ne68872c49aaedeb3bde3ff5fd2ad6f70658687dc02d04f12ebc7cb28e821cc88 \r\nMalicious VIB\r\nDeployment\r\nScript\r\nMD5\r\nSHA1\r\nSHA256\r\n8e80b40b1298f022c7f3a96599806c43\r\ne9cbac1f64587ce1dc5b92cde9637affb3b58577\r\nc2ef08af063f6d416233a4b2b2e991c177fc72d70a76c24bca9080521d41040f \r\nVIRTUALPITA\r\nMD5\r\nSHA1\r\nSHA256\r\n61ab3f6401d60ec36cd3ac980a8deb75\r\n93d5c4ebec2aa45dcbd6ddbaad5d80614af82f84 \r\n4cf3e0b60e880e6a6ba9f45187ac5454813ae8c2031966d8b264ae0d1e15e70d \r\nVIRTUALPIE\r\nMD5\r\nSHA1\r\n9ea86dccd5bbde47f8641b62a1eeff07\r\nb90b19781fde2c35963eb3eac4ce2acc6f5019fb \r\nMalicious VIB\r\nPayload\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 10 of 14\n\nSHA256 23eb8d056f18e7c69ec3568f2833c9d09e91df98d11b11de235331ef42756fe5 \r\nMD5\r\nSHA1\r\nSHA256\r\n9d5cc1ee99ccb1ec4d20be1cee10173e\r\n9d191849d6c57bc8a052ec3dac2aa9f57c3fe0cd \r\n4d995eb87b0685124b7f1640d1ab431f5a1ab991ade02750b876ed5c523234bb \r\nMalicious VIB\r\nDeployment\r\nScript\r\nMD5\r\nSHA1\r\nSHA256\r\n2c28ec2d541f555b2838099ca849f965\r\ne35733db8061b57b8fcdb83ab51a90d0a8ba618c \r\n505eb3b90cd107cf7e2c20189889afdff813b2fbb98bbdeab65cde520893b168 \r\nVIRTUALPITA\r\nMD5\r\nSHA1\r\nSHA256\r\n744e2a4c1da48869776827d461c2b2ec\r\na3cc666e0764e856e65275bd4f32a56d76e51420 \r\n4a6f559426493abc0d056665f23457e2779abd3482434623e1f61f4cd5b41843 \r\nVIRTUALPITA\r\nMD5\r\nSHA1\r\nSHA256\r\n93d50025b81d3dbcb2e25d15cae03428\r\nabff003edf67e77667f56bbcfc391e2175cb0f8a \r\n13f11c81331bdce711139f985e6c525915a72dc5443fbbfe99c8ec1dd7ad2209 \r\nVIRTUALPITA\r\nMD5\r\nSHA1\r\nSHA256\r\nfe34b7c071d96dac498b72a4a07cb246\r\n0962e10dc34256c6b31509a5ced498f8f6a3d6b6 \r\n5731d988781c9a1d2941f7333615f6292fb359f6d48498f32c29878b5bedf00f \r\nVIRTUALPITA\r\nDescriptor\r\nXML\r\nName\r\nlsu-lsi-lsi-mrarpid-plugin VIB Name\r\nFilename lsu_lsi_.v05\r\nVIB .vgz\r\npayload\r\nFullpath /etc/rc.local.d/vmware_local.sh\r\nVIB\r\nDeployment\r\nScript\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 11 of 14\n\nFullpath /bin/rdt VIRTUALPITA\r\nFullpath /bin/vmsyslog.py  \r\nDescriptor\r\nXML\r\nName\r\nata-pata-pdc20211 VIB Name\r\nFilename payload1.v00\r\nVIB .vgz\r\npayload\r\nFullpath /etc/rc.local.d/vmware_rhttpio.sh\r\nVIB\r\nDeployment\r\nScript\r\nFullpath /usr/lib/vmware/weasel/consoleui/rhttpproxy-io VIRTUALPITA\r\nFullpath /usr/libexec/setconf/ksmd\r\nVIRTUALPITA\r\n(Linux)\r\nFullpath /usr/bin/ksmd\r\nVIRTUALPITA\r\n(Linux)\r\nFullpath C:\\Windows\\Temp\\avp.exe VIRTUALGATE\r\nFullpath\r\nand Hash\r\n(MD5)\r\nC:\\Windows\\Temp\\Silverlight\\wmpd.exe 76df41ee75d5077f2c5bec70747b3c99 \r\nDeleted File\r\ncreated by\r\nvmtoolsd.exe\r\nand executed by\r\nvmtoolsd.exe\r\nchild process\r\nYara Detections\r\nrule M_APT_VIRTUALPITA_1\r\n{\r\n meta:\r\n author = \"Mandiant\"\r\n md5 = \"fe34b7c071d96dac498b72a4a07cb246\"\r\n description = \"Finds opcodes to set a port to bind on 2233, encompassing the setsockopt(), htons(),\r\n strings:\r\n $x = {8b ?? ?? 4? b8 04 00 00 00 [0 - 4] ba 02 00 00 00 be 01 00 00 00 [0 - 2] e8 ?? ?? ?? ?? 89 4? ?\r\n condition:\r\n uint32(0) == 0x464c457f and all of them\r\n}\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 12 of 14\n\nrule M_APT_VIRTUALPITA_2\r\n{\r\n meta:\r\n author = \"Mandiant\"\r\n md5 = \"fe34b7c071d96dac498b72a4a07cb246\"\r\n description = \"Finds opcodes to decode and parse the recieved data in the socket buffer in fe34b7c07\r\n strings:\r\n $x = {85 c0 74 ?? c7 05 ?? ?? ?? ?? fb ff ff ff c7 8? ?? ?? ?? ?? 00 00 00 00 e9 ?? ?? ?? ?? 4? 8b 05\r\n condition:\r\n uint32(0) == 0x464c457f and all of them\r\n}\r\nrule M_APT_VIRTUALPITA_3\r\n{\r\n meta:\r\n author = \"Mandiant\"\r\n md5 = \"fe34b7c071d96dac498b72a4a07cb246\"\r\n description = \"Finds opcodes from 409dd8 to 409e46 in fe34b7c071d96dac498b72a4a07cb246 to set the HI\r\n strings:\r\n $x = {4? 8b 4? ?? c6 00 48 4? 8b 4? ?? 4? 83 c0 05 c6 00 49 4? 8b 4? ?? 4? 83 c0 01 c6 00 49 4? 8b 4?\r\n condition:\r\n uint32(0) == 0x464c457f and all of them\r\n}\r\nrule M_APT_VIRTUALPITA_4\r\n{\r\n meta:\r\n author = \"Mandiant\"\r\n md5 = \"fe34b7c071d96dac498b72a4a07cb246\"\r\n description = \"Finds opcodes from 401f1c to 401f4f in fe34b7c071d96dac498b72a4a07cb246 to decode tex\r\n strings:\r\n $x = {4? 8b 4? ?? 4? 83 c1 30 4? 8b 4? ?? 4? 8b 10 8b 4? ?? 4? 98 4? 8b 04 ?? ?? ?? ?? ?? 4? 31 c2 4?\r\n condition:\r\n uint32(0) == 0x464c457f and all of them\r\n}\r\nrule M_Hunting_Script_LaunchAndDelete_1\r\n{\r\n meta:\r\n author = \"Mandiant\"\r\n md5 = \"bd6e38b6ff85ab02c1a4325e8af29ce4\"\r\n description = \"Finds scripts that launch and then delete files, indicative of cleaning up tracks and\r\n strings:\r\n $ss = /setsid[^\\n\\r]{,250}-i[\\r\\n]{,5}rm/\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 13 of 14\n\ncondition:\r\n all of them\r\n}\r\nrule M_Hunting_Python_Backdoor_CommandParser_1\r\n{\r\n meta:\r\nauthor = \"Mandiant\"\r\n md5 = \"61ab3f6401d60ec36cd3ac980a8deb75\"\r\n description = \"Finds strings indicative of the vmsyslog.py python backdoor.\"\r\n strings:\r\n $key1 = \"readInt8()\" ascii wide\r\n $key2 = \"upload\" ascii wide\r\n $key3 = \"download\" ascii wide\r\n $key4 = \"shell\" ascii wide\r\n $key5 = \"execute\" ascii wide\r\n $re1 = /def\\srun.{,20}command\\s?=\\s?self\\.conn\\.readInt8\\(\\).{,75}upload.{,75}download.{,75}shell.{,7\r\n condition:\r\n filesize \u003c 200KB and all of them\r\n}\r\nAcknowledgements\r\nSpecial thanks to Brad Slaybaugh, Joshua Kim, Zachary Smith, Kirstie Failey, Nick Simonian, and Charles\r\nCarmakal for their assistance with the investigation, technical review, and creating detections for the malware\r\nfamilies discussed in this blog post. In addition, we would also like to thank VMware for their collaboration on this\r\nresearch.\r\nPosted in\r\nThreat Intelligence\r\nSource: https://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"ETDA"
	],
	"references": [
		"https://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-malware-persistence"
	],
	"report_names": [
		"esxi-hypervisors-malware-persistence"
	],
	"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": 1775434916,
	"ts_updated_at": 1775791794,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/daee4474bc83516f30465f644b30487d68022109.pdf",
		"text": "https://archive.orkl.eu/daee4474bc83516f30465f644b30487d68022109.txt",
		"img": "https://archive.orkl.eu/daee4474bc83516f30465f644b30487d68022109.jpg"
	}
}