{
	"id": "c2a8cc2b-860e-4056-96f6-2f0056f6d84e",
	"created_at": "2026-04-06T00:11:57.340854Z",
	"updated_at": "2026-04-10T13:12:30.520202Z",
	"deleted_at": null,
	"sha1_hash": "c50a8b1c033c616fd204c6885a4272797d45202e",
	"title": "Detection, Containment, and Hardening Opportunities for Privileged Guest Operations, Anomalous Behavior, and VMCI Backdoors on Compromised VMware Hosts",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1265244,
	"plain_text": "Detection, Containment, and Hardening Opportunities for Privileged\r\nGuest Operations, Anomalous Behavior, and VMCI Backdoors on\r\nCompromised VMware Hosts\r\nBy Mandiant\r\nPublished: 2023-06-28 · Archived: 2026-04-05 23:37:53 UTC\r\nWritten by: Alex Marvi, Greg Blaum, Ron Craft\r\nIn Mandiant’s initial publication of this vulnerability, we covered the attackers’ exploitation of CVE-2023-20867, the\r\nharvesting of ESXi service account credentials on vCenter machines, and the implications of backdoor communications\r\nover VMCI socket. In this blog post, we will focus on the artifacts, logging options, and hardening steps to detect and\r\nprevent the following tactics and techniques seen being used by UNC3886:\r\nBoth ESXi host and guest machine level logging options for Guest Operations\r\nvpxuser behavior indicative of anomalous usage\r\nIdentifying open VMCI ports on ESXi hosts\r\nMultiple vCenter and ESXi containment and hardening recommendations to help deter future activity\r\nFor additional details, VMware has also released their guidance on the most recent CVE utilized by UNC3886.\r\nSince the majority of threat actor operations cross the virtualization barrier between ESXi host and connected guest VMs,\r\nboth successful and failed actions will have some sort of remnants available across both layers. The first section of this\r\nblog post will describe log options and configurations available on both ESXi hosts and guest VMs to identify when a\r\nthreat actor performs successful guest operations.\r\nESXi Host and Guest Logging Options\r\nThe inherent behavior of Guest Operations can be partially tracked across Windows and Linux guest machines with\r\nproper EDR detections, but fall short in a few key situations. While EDR solutions can generally track file write\r\ninteractions and new processes spawned from vmtoolsd.exe on Windows and from the vmtools daemon on Linux, they do\r\nnot generally track file read operations. This particular interaction originally impacted Mandiant’s ability to track\r\nUNC3886 transferring files from the guest VMs to the ESXi host. For this reason, Mandiant has identified and outlined\r\nadditional logging sources and configurations that can be used to track when anomalous guest operations are occurring on\r\nboth the ESXi host and guest machine level, regardless of the operation.\r\nESXi Host Logging\r\nWhen Guest Operations are successfully performed on guest VMs from the ESXi Host, the ESXi host logs the operation\r\naction by default at the following path /vmfs/volumes/…//vmware.log . Due to the location of this log, once a virtual\r\nmachine is deleted from the ESXi host, the logs will be deleted alongside the .vmdk and .vmx files. This means by\r\ndefault only virtual machines currently present on the ESXi hosts can be reviewed for historical Guest Operations. Some\r\nexamples of Guest Operations entries can be seen in Figure 1.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 1 of 17\n\nFigure 1: ESXi Host logging for Guest Operations\r\nTo focus on interactions between the ESXi Host and its guest machines in the vmware.log, filter for lines containing\r\n“GuestOps” (Here is a full list of Guest Operations). By default, these logs store up to six (6) separate log files, which\r\nrotate to a new file with every power on/off operation. The oldest log is removed in place of a new log once the max\r\nnumber of logs are reached. The following section further describes which configuration options can be used to customize\r\nthe logs to the settings that best fit the environment.\r\nAdditional Host Level Logging Configurations\r\nThe following options can be used to configure ESXi host logging for Guest Operations to support additional retention,\r\nalternative rotation options, and location of the vmware.log output:\r\nlogging – Set to either True or False, this value enables or disables Guest Operation logging for the virtual\r\nmachine on the ESXi host\r\nlog.rotateSize – By default, logs rotate to a new file when a power on or off operation occurs. This option changes\r\nthe logs to only rotate to a new file once a specific size in bytes are met (Only available on ESXi 6.x+).\r\nlog.keepOld – This value is set to six (6) by default and specifies the number of log rotations retained. Mandiant\r\nsuggests increasing this value based on available storage and number of VMs on the ESXi host.\r\nlog.fileName – Sets the filename used to save the Guest Operation logs. If a full path is provided, Guest\r\nOperations will be written to that directory.\r\nvmx.log.destination – When this value is set to syslog-and-disk, logs will be forwarded to both the ESXi local\r\ndatastore and the syslog server defined in the Host syslog settings . The vmx.log.syslogID value must be set\r\ncorrectly to be able to identify the virtual machines associated with these logs.\r\nvmx.log.syslogID – A unique identifier to associate the logs forwarded to the syslog server with a guest machine.\r\nThis is most commonly set to the name of the Virtual Name if a unique guest machine naming schema is being\r\nenforced.\r\nAdditional information surrounding these logging configurations can be found within the following VMware article.\r\nIn addition to ESXi host logging, Mandiant has identified optional logging on guest VMs with VMware Tools (vmtools)\r\ninstalled, which enable high-level, or detailed logging options, on Guest Operations being performed from the ESXi host.\r\nGuest Machine Logging (vmsvc.log)\r\nBy default, the vmsvc.log is not enabled by vmtools on guest machines, but this log provides a few different levels of\r\nvisibility into any Guest Operations being executed on the host when enabled. This visibility ranges from seeing the\r\nnames of the operations being performed when message level logging is enabled, to full visibility into files being\r\ntransferred and command line arguments being executed if debugging is enabled.\r\nMessage Level Logging (vmsvc.log)\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 2 of 17\n\nHaving the vmsvc.log enabled at the message level enables partial visibility into the types of actions being taken against\r\nthe guest machines by the ESXi host due to VixTools operation codes being logged. The VIXTools API (Vix) is a library\r\ndesigned for writing scripts and programs to manipulate virtual machines and is the backend that drives Guest Operations.\r\nSince Guest Operations are directly related to the VixTools API, it is possible to translate Vix operational codes to the\r\nGuest Operations used to invoke them. Figure 2 shows an example line in the vmsvc.log which contains these Vix codes\r\n(denominated as X) and can be translated into an equivalent Guest Operation:\r\n[message] [vix] VixTools_ProcessVixCommand: command X\r\nFigure 2: Example VixTools Events in message level logging (vmsvc.log)\r\nTo translate these Vix codes, the following source code contains a list of all possible Vix operational codes. Some of the\r\nkey Vix codes which are related to Guest Operations seen being used by the attacker can be seen in Table 1:\r\nVixCommand\r\nOpCode\r\nVix Command Name Guest Operation Equivalent\r\n177 VIX_COMMAND_LIST_FILES ListFilesInGuest\r\n185 VIX_COMMAND_START_PROGRAM StartProgramInGuest\r\n186 VIX_COMMAND_LIST_PROCESSES_EX ListProcessesInGuest\r\n188 VIX_COMMAND_INITIATE_FILE_TRANSFER_FROM_GUEST InitiateFileTransferFromGuest\r\n189 VIX_COMMAND_INITIATE_FILE_TRANSFER_TO_GUEST InitiateFileTransferToGuest\r\n84 VMXI_HGFS_SEND_PACKET_COMMAND\r\nAccompanies 188 and 189 to\r\nsend and receive files\r\nTable 1: Vix Operational Codes to Guest Operations\r\nMessage level logging in the vmsvc.log can be a consistent tool to alert on anomalous Guest Operations occurring on\r\nguest machines to prompt further investigation. This level of logging still falls short in the same manner as many EDR\r\nsolutions if files are being copied from the guest machine to the ESXi host as the specific files cannot be identified. This\r\nis where debugging level logging is useful.\r\nDebug Level Logging (vmsvc.log)\r\nFor full visibility into the Guest Operations within the vmsvc.log , debugging level logging can be enabled. This allows\r\nvisibility into:\r\nEvents showing that impersonation of the root user is occurring\r\nThe commands and arguments being passed on to the guest machine from the ESXi host\r\nThe number of bytes sent to and from the ESXi host and guest machine during guest operations\r\nThe source path, destination path, file names, and size of file being sent during file transfer operations\r\nAn example of debugging level logging for the “StartPrograminGuest” Guest Operation can be found in Figure 3 for\r\nLinux guest VMs and Figure 4 for Windows guest VMs.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 3 of 17\n\nLinux Guest Machine:\r\n[debug] [vmsvc] RpcIn: received 198 bytes, content:\"Vix_1_Relayed_Command \"588cea63b2ecd6cd\"\\00\\01\\00\\0d\\d0\\05\\00\\9d\\0\r\n[message] [vix] VixTools_ProcessVixCommand: command 185\r\n[debug] [vix] VixToolsImpersonateUser: successfully impersonated user _ROOT_\r\n[debug] [vix] VixTools_StartProgram: User: _ROOT_ args: progamPath: '/bin/ls', arguments: '\"-R\" \"/var/log\"', workingDir\r\n[debug] [vmsvc] Executing async command: '\"/bin/ls\" \"-R\" \"/var/log\"' in working dir '/root'\r\n[debug] [vix] VixToolsStartProgramImpl: started '\"/bin/ls\" \"-R\" \"/var/log\"', pid 8817\r\n[debug] [vix] VixTools_StartProgram: returning '8817'\r\n[message] [vix] VixTools_StartProgram: opcode 185 returning 0\r\n[debug] [vix] ToolsDaemonTcloReceiveVixCommand: command 185, additionalError = 0\r\n[debug] [vmsvc] RpcIn: sending 1242 bytes\r\nFigure 3: Linux guest VM Debug Level Logging (vmsvc.log)\r\nWindows Guest Machine:\r\n[ debug] [vmsvc] [3116] RpcIn: received 253 bytes, content:\"Vix_1_Relayed_Command \"25642877bd645a32\"\\00\\01\\00\\0dÐ\\05\r\n[ message] [vix] [3116] VixTools_ProcessVixCommand: command 185\r\n[ debug] [vmsvc] [3116] VMTools_ConfigGetBoolean: Returning default value for '[guestoperations] disabled'=FALSE (Not\r\n[ debug] [vmsvc] [3116] VMTools_ConfigGetBoolean: Returning default value for '[guestoperations] StartProgramInGuest.\r\n[ debug] [vix] [3116] VixToolsImpersonateUser: successfully impersonated user _ROOT_\r\n[ debug] [vix] [3116] VixTools_StartProgram: User: _ROOT_ args: progamPath: 'c:\\windows\\system32\\cmd.exe', arguments:\r\n[ debug] [vmsvc] [3116] ProcMgr_ExecAsync: Executing async command: \"c:\\windows\\system32\\cmd.exe\" \"/c dir /od /s /a c\r\n[ debug] [vmsvc] [3116] Spawned sub-process 888\r\n[ debug] [vix] [3116] VixToolsStartProgramImpl: started '\"c:\\windows\\system32\\cmd.exe\" \"/c dir /od /s /a c:\\\\ \u003e C:\\\\T\r\n[ debug] [vix] [3116] VixToolsUnimpersonateUser: Faking unimpersonate\r\n[ debug] [vix] [3116] VixTools_StartProgram: returning '4812'\r\n[ message] [vix] [3116] VixTools_StartProgram: opcode 185 returning 0\r\n[ debug] [vix] [3116] ToolsDaemonTcloReceiveVixCommand: command 185, additionalError = 0\r\n[ debug] [vmsvc] [3116] RpcIn: sending 12 bytes\r\nFigure 4: Windows guest VM Debug Level Logging (vmsvc.log)\r\nBoth configurations can be set to message or debug , depending on the visibility and storage capabilities of the\r\nenvironment it’s being enabled on.\r\nMandiant advises that a test environment is staged with vmsvc logging enabled at both levels to better identify the\r\nperformance impact this may have on each individual environment, prior to additional logging levels being enabled in\r\nproduction.\r\nConfiguring Extended Logging on Windows and Linux Machines\r\nTo enable the vmsvc.log on guest VMs with vmtools installed, locate the tools.conf file which can be found at one of\r\nthe locations specified in Figure 5.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 4 of 17\n\nFigure 5: Location of vmsvc.log configuration file per operating system\r\nWithin tools.conf , insert the appropriate configuration based on the relevant operating system seen in both Figure 6\r\nand Figure 7. The VMware Tools service will need to be restarted for the new logging level to take effect.\r\n[logging]\r\nlog = true\r\nvmsvc.level = debug\r\nvmsvc.handler = file\r\nvmsvc.data = c:/Windows/Temp/vmsvc.log\r\nFigure 6: Windows tools.conf configurations (Use forward slashes)\r\n[logging]\r\nlog = true\r\nvmsvc.level = debug\r\nvmsvc.handler = file\r\nvmsvc.data = /tmp/vmsvc.log\r\nFigure 7: Linux tools.conf configurations\r\nFor further instructions on how to apply these configurations within Windows and Linux guest machines, please follow\r\nVMware’s guide.\r\nTo enable log forwarding to syslog or other sources such as the ESXi Host, please reference the “syslog” section of the\r\ndefault tools.conf configuration file.\r\nThe aforementioned logging options across ESXi host and guest VMs provide visibility into Guest Operations occurring\r\nbetween host and guest VM. However, they do not log the presence of VMCI backdoors being deployed or the\r\ncommunication that occurs when a threat actor is connecting to a VMCI backdoor. To account for this, the following\r\nsection details how to identify if a binary has an open VMCI port on an ESXi host.\r\nDetecting Open VMCI Sockets on ESXi Hosts\r\nWhile VMCI provides threat actors with a flat network to listen on and connect over for extended persistence in\r\nvirtualized environments, this same concept enables defenders to perform checks for VMCI backdoors with similar\r\nflexibility. Since VMCI sockets on ESXi hosts are open to all guest machines running underneath the ESXi host, any\r\nguest machine running underneath the host can sniff VMCI port traffic to identify anomalies.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 5 of 17\n\nWhile scanning for open VMCI ports sounded like a viable approach at first, it becomes unrealistic when attempting to\r\naccount for the entire port range. As of this blog post, Mandiant has not observed threat actors utilizing port numbers\r\noutside of the traditional 65,535 range (the range for TCP/UDP ports). However, the port can range from 0-2,147,483,647\r\nas the port number field for VMCI socket address is 32-bits. This makes scanning a time-consuming process that is not\r\nrealistic in a production environment.\r\nAt the time of writing, the most consistent way Mandiant has identified VMCI ports open on ESXi hosts is through the\r\nusage of the lsof -A command. This command displays file information and metadata about files opened by processes,\r\nand in effect on ESXi hosts, it also lists processes that actively have open VMCI ports. As seen in Figure 8, when a\r\nprocess is listening on a VMCI port, lsof will show the process as containing a type SOCKET_VMCI and a description\r\nfield with the value {no file name} . Mandiant has guidance on how to dump ESXi host process memory in the\r\nfollowing blog post to further inspect the offending binary so the exact port number can be identified.\r\nFigure 8: lsof -A showing process listening on a VMCI port\r\nWhile VMCI communication is normally invisible to common network sniffing tools without modification, public\r\nresearch exists which documents how to sniff this traffic. Andra Paraschiv and Stefano Garzarella covered this and much\r\nmore in their talk “Leveraging virtio-vsock in the cloud and containers” in FOSDEM 2021 (recording | slide deck, slide\r\n23).\r\nIn addition to active VMCI backdoors, other historical artifacts can be found on ESXi hosts and guest machines that can\r\nbe indicative of past threat actor activity. The following section describes some of the artifacts that arise from both\r\nsuccessful compromise of an ESXi host using the vpxuser, and failed attempts to use Guest Operations on guest VMs\r\nwithout the exploit.\r\nAdditional Artifacts\r\nExpected vpxuser Behavior on ESXi Hosts\r\nSince the credentials for the vpxuser can be harvested on one (1) vCenter and result in the compromise of multiple\r\nconnected ESXi hosts, it is important to understand the expected behavior of this user so any anomalous activity can be\r\nalerted on and investigated further.\r\nSince the vpxuser account is a service account designed to administer ESXi hosts from vCenter servers, vCenter servers\r\nare the only place that this account should be expected to login from. Additionally, due to being a service account with\r\nautomatic password rotation and with no expected user interaction, failed logons from the vpxuser should be considered\r\nabnormal and investigated further. An exception to this could potentially occur when an authentication check fails as the\r\npassword is being rotated, however this should not occur often enough to cause a large amount of false positive alerts.\r\nIn addition to expected logon locations, there is only one user agent that the vpxuser should have when it logs onto an\r\nESXi host as seen in the hostd.log examples in Figure 9. Normally, the expected user agent would be VMware-https://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 6 of 17\n\nclient/X.X.X . While investigating UNC3886 activity, Mandiant identified the threat actor connecting to ESXi hosts\r\nutilizing the following user agents:\r\npyvmomi Python/3.5.5 (Linux; 4.4.157-1.ph1; x86_64)\r\nPowerCLI/12.5.0.19195797\r\nVMware confirmed that the aforementioned user agents are not expected from the vpxuser when authenticating to an\r\nESXi host and would be considered anomalous, warranting further investigation.\r\ninfo hostd[B981B70] [Originator@6876 sub=Vimsvc.ha-eventmgr opID=2dee888f] Event 488 : User vpxuser@\u003cvCenter IP\u003e logge\r\ninfo hostd[C481B70] [Originator@6876 sub=Vimsvc.ha-eventmgr opID=2dee88ad user=vpxuser] Event 491 : User vpxuser@\u003cvCent\r\ninfo hostd[11EC2B70] [Originator@6876 sub=Vimsvc.ha-eventmgr opID=bb47b2c8] Event 1461 : User vpxuser@\u003cvCenter IP\u003e logg\r\ninfo hostd[11E81B70] [Originator@6876 sub=Vimsvc.ha-eventmgr opID=bb47b37b user=vpxuser] Event 1462 : User vpxuser@\u003cvCe\r\nFigure 9: hostd.log entries showing abnormal vpxuser User Agents\r\nIn the situation where a .vib file is recovered, it is important to understand that .vib files are actually AR archives to\r\nbe able to properly inspect them. To extract the contents of the VIB properly, the command ar -xv \u003c.vib File\u003e can be\r\nused.\r\nIn addition to abnormal vpxuser interactions, abnormal remote VIB installations can also shed light on past attacker\r\nactivity, even if the VIBs have since been cleaned from the systems. The following section details additional log entries\r\nfound in the esxupdate.log which can show where VIBs were remotely installed from.\r\nInstallation of VIBs Logs with download from vCenter\r\nWithin the esxupdate.log , a specific log entry will log the installation of a new VIB along with the viburl if it is\r\ninstalled remotely. Per Figure 10, the log entry provides the URL the VIB was downloaded from, the options used to\r\ninstall the VIB, and the destination that the VIB was downloaded to on the ESXi host.\r\nesxupdate: 376185: root: INFO: Options = {'nomaintmode': False, 'oktoremove': False, 'force': False, 'nosigcheck': Tru\r\nesxupdate: 376185: downloader: DEBUG: Downloading http://\u003cvCenter IP\u003e:8080/ata-pata-pdc20279.vib to /tmp/vibdownload/VM\r\nFigure 10: VIBURL esxupdate.log entry\r\nLooking for abnormal installation options such as force/nosigcheck , anomalous sources and VIB names, and\r\nsuspicious ports used for installs can act as additional detection mechanisms.\r\nThus far, the blog post has covered logging for successful Guest Operations and abnormal vpxuser activity on ESXi hosts.\r\nThe following section details how failed Guest Operations are logged on both ESXi hosts and guest VMs if the exploit is\r\nnot properly executed and authentication challenges are made.\r\nFailed Guest Operation events on ESXi Host\r\nWhen Guest Operations fail, they are logged on guest machines in a consistent manner on the operating system, but failed\r\nGuest Operations can result in multiple types of error messages on the ESXi host that should be searched for within the\r\nhostd.log .\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 7 of 17\n\nIf the exploit is executed successfully, but the guest machine does not have vmtools installed, the hostd.log will log the\r\nerror “vim.fault.GuestOperationsUnavailable” per Figure 11.\r\n/var/log/hostd.log-2023-03-20T18:19:46.994Z info hostd[265567] [Originator@6876\r\nsub=AdapterServer opID=216dd829 user=root] AdapterServer caught exception;\r\n\u003c\u003c520eeb98-8189-0488-f079-b1b09e197338, \u003cTCP '127.0.0.1 : 8307'\u003e, \u003cTCP '127.0.0.1 : 48405'\u003e\u003e,\r\nha-guest-operations-process-manager, vim.vm.guest.ProcessManager.startProgram\u003e,\r\nN3Vim5Fault26GuestOperationsUnavailable9ExceptionE(Fault cause:\r\nvim.fault.GuestOperationsUnavailable\r\n/var/log/hostd.log---\u003e )\r\n/var/log/hostd.log---\u003e [context]zKq7AVICAgAAAKEvNgEPaG9zdGQAACJDF2xpYnZtYWNvcmUuc28AATp37WxpYnZpbS10eXBlcy5zbwCBF8EHA\r\nYGBYQgBgRYdBAECyO/HaG9zdGQAAkuvcAJmsHCBcAAVAQKKklIArMctADQDLgDiED8DO30AbGlicHRocmVhZC5zby4wA\r\nARt0Q5saWJjLnNvLjYA[/context]\r\n/var/log/hostd.log-2023-03-20T18:19:46.999Z info hostd[265567] [Originator@6876 sub=Solo.Vmomi opID=216dd829 user=root]\r\n/var/log/hostd.log-2023-03-20T18:19:46.999Z verbose hostd[265567] [Originator@6876 sub=Solo.Vmomi opID=216dd829 user=ro\r\n/var/log/hostd.log---\u003e 'vim.VirtualMachine:3'\r\n/var/log/hostd.log-2023-03-20T18:19:46.999Z verbose hostd[265567] [Originator@6876 sub=Solo.Vmomi opID=216dd829 user=ro\r\n/var/log/hostd.log---\u003e (vim.vm.guest.NamePasswordAuthentication) {\r\n/var/log/hostd.log---\u003e interactiveSession = false,\r\n/var/log/hostd.log:--\u003e username = \"vinny\",\r\n/var/log/hostd.log---\u003e password = (not shown)\r\n/var/log/hostd.log---\u003e }\r\n/var/log/hostd.log-2023-03-20T18:19:46.999Z verbose hostd[265567] [Originator@6876 sub=Solo.Vmomi opID=216dd829 user=ro\r\n/var/log/hostd.log---\u003e (vim.vm.guest.ProcessManager.ProgramSpec) {\r\n/var/log/hostd.log---\u003e programPath = \"C:\\Windows\\system32\\cmd.exe\",\r\n/var/log/hostd.log---\u003e arguments = \"/c dir /od /s /a c:\\ \u003e C:\\Windows\\Temp\\hi.txt\",\r\n/var/log/hostd.log---\u003e }\r\n/var/log/hostd.log-2023-03-20T18:19:46.999Z info hostd[265567] [Originator@6876 sub=Solo.Vmomi opID=216dd829 user=root]\r\n/var/log/hostd.log-2023-03-20T18:19:46.999Z info hostd[265567] [Originator@6876 sub=Solo.Vmomi opID=216dd829 user=root]\r\nInstall vmtoolsd.exe on Windows Guest Machine\r\nFigure 11: ESXi hostd.log vim.fault.GuestOperationsUnavailable\r\nIf vmtools are installed on the target guest machine but the exploit was not executed successfully, the host will validate\r\nwhether the passed credentials are valid. When invalid credentials are used to attempt a Guest Operation, the error\r\n“vim.fault.InvalidGuestLogin” will be written to the hostd.log as seen in Figure 12.\r\n/var/log/hostd.log-2023-03-20T18:57:17.574Z info hostd[265189] [Originator@6876 sub=Default opID=71a2fa8c] Accepted pa\r\n/var/log/hostd.log-2023-03-20T18:57:17.574Z warning hostd[265189] [Originator@6876 sub=Vimsvc opID=71a2fa8c] Refresh fu\r\n/var/log/hostd.log-2023-03-20T18:57:17.574Z info hostd[265189] [Originator@6876 sub=Vimsvc.ha-eventmgr opID=71a2fa8c] E\r\n/var/log/hostd.log-2023-03-20T18:57:17.630Z info hostd[265191] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/63e135fc-5c8\r\n/var/log/hostd.log-2023-03-20T18:57:17.678Z verbose hostd[265191] [Originator@6876 sub=Vigor.Vmsvc.vm:/vmfs/volumes/63e\r\n/var/log/hostd.log-2023-03-20T18:57:17.678Z verbose hostd[265191] [Originator@6876 sub=Vigor.Vmsvc.vm:/vmfs/volumes/63e\r\n/var/log/hostd.log-2023-03-20T18:57:17.679Z info hostd[264228] [Originator@6876 sub=Vimsvc.ha-eventmgr opID=esxui-e1ff-\r\n/var/log/hostd.log-2023-03-20T18:57:17.681Z info hostd[264228] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/63e135fc-5c8\r\n/var/log/hostd.log-2023-03-20T18:57:17.685Z info hostd[264228] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/63e135fc-5c8\r\n/var/log/hostd.log-2023-03-20T18:57:17.685Z info hostd[264228] [Originator@6876 sub=Solo.Vmomi opID=esxui-e1ff-fa23] Ac\r\n/var/log/hostd.log-2023-03-20T18:57:17.685Z verbose hostd[264228] [Originator@6876 sub=Solo.Vmomi opID=esxui-e1ff-fa23]\r\n/var/log/hostd.log---\u003e 'vim.VirtualMachine:3'\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 8 of 17\n\n/var/log/hostd.log-2023-03-20T18:57:17.685Z verbose hostd[264228] [Originator@6876 sub=Solo.Vmomi opID=esxui-e1ff-fa23]\r\n/var/log/hostd.log---\u003e (vim.vm.guest.NamePasswordAuthentication) {\r\n/var/log/hostd.log---\u003e interactiveSession = false,\r\n/var/log/hostd.log:--\u003e username = \"vinny\",\r\n/var/log/hostd.log---\u003e password = (not shown)\r\n/var/log/hostd.log---\u003e }\r\n/var/log/hostd.log-2023-03-20T18:57:17.685Z verbose hostd[264228] [Originator@6876 sub=Solo.Vmomi opID=esxui-e1ff-fa23]\r\n/var/log/hostd.log---\u003e (vim.vm.guest.ProcessManager.ProgramSpec) {\r\n/var/log/hostd.log---\u003e programPath = \"C:\\Windows\\system32\\cmd.exe\",\r\n/var/log/hostd.log---\u003e arguments = \"/c dir /od /s /a c:\\ \u003e C:\\Windows\\Temp\\hi.txt\",\r\n/var/log/hostd.log---\u003e }\r\n/var/log/hostd.log-2023-03-20T18:57:17.685Z info hostd[264228] [Originator@6876 sub=Solo.Vmomi opID=esxui-e1ff-fa23] Th\r\n/var/log/hostd.log-2023-03-20T18:57:17.685Z info hostd[264228] [Originator@6876 sub=Solo.Vmomi opID=esxui-e1ff-fa23] Re\r\n/var/log/hostd.log---\u003e (vim.fault.InvalidGuestLogin) {\r\n/var/log/hostd.log---\u003e msg = \"\",\r\n/var/log/hostd.log---\u003e }\r\nFigure 12: ESXi hostd.log vim.fault.InvalidGuestLogin\r\nWhen Guest Operations fail with vmtools installed on the target guest machine and due to invalid credentials, the guest\r\nmachines will also log the failed checks. The following sections describe how both Windows and Linux machines log\r\nthese failed validation attempts.\r\nFailed Guest Operations on Linux Guests\r\nIf vmtoolsd is enabled on a Linux guest but the exploit was not executed correctly, an authentication check is made\r\nagainst a Linux guest machine. If this check fails,  /var/log/secure  will generate the event “Failed\r\npam_unix(vmtoolsd:auth)” as seen in Figure 13 with the name of the user which was used to authenticate.\r\nFigure 13: Linux vmtoolsd failed authentication\r\nIf the debugging logging level for vmsvc logging is enabled on the Linux machine, the failed impersonation can be\r\nobserved along with the guest operation type that failed to run as seen in Figure 14.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 9 of 17\n\nFigure 14: Linux failed authentication vmsvc.log\r\nFailed Guest Operations on Windows Guests\r\nSimilar to Linux guest machines, when vmtoolsd is enabled but the exploit is not executed, an authentication check is\r\nmade against a Windows guest machine resulting in three 4625 events in the Windows Security Event Logs. These three\r\nevents occur in quick succession with one Type 2, one Type 4, and one Type 5 logon attempt (Windows Logon Types).\r\nAdditionally, the following attributes are consistent amongst the 4625 events:\r\nThe account name is the username passed from the host that failed the check\r\nThe Caller Process Name is  C:\\Program Files\\VMware\\VMware Tools\\vmtoolsd.exe\r\nThe  Network Information: Workstation Name  will be the Windows Guest Hostname.\r\nAlerting and detections are useful when reacting to a threat actor already in the environment, but to be proactive in\r\nprotecting against potential incidents before they occur, proper hardening and configuration of virtualization technologies\r\nis required. The rest of this blog post will describe the many layers of protections that can be put in place at the vCenter,\r\nESXi host, and guest machine level to help protect against unauthorized access to these technologies.\r\nContainment and Hardening Recommendations\r\nNetwork Segmentation of Administrative Interfaces for ESXi Hosts and vCenter Servers\r\nTo gain access to ESXi hosts and vCenter Servers, attackers need to be able to reach the administrative interfaces of these\r\nsystems. Network segmentation provides a significant opportunity for reducing the overall attack surface and presents an\r\nattacker with roadblocks throughout each step of the attack lifecycle. Isolating the administrative interface to a separate\r\nnetwork segment from the main production network has the added benefit of helping to contain compromises of other\r\nsystems and infrastructure from spreading to the VMware hypervisor infrastructure.Ensure that any VMKernel interfaces\r\nthat are configured for ESXi Management, vMotion, and vSAN are deployed only in a restricted network segment, and\r\nthat any supporting systems that are needed for those functions are also deployed in the restricted network segment. In\r\naddition to isolating the ESXi and vCenter Server administrative interfaces to a separate VLAN, restrict access to only\r\nspecifically allowed, privileged management workstations. Ensure that these management workstations are implementing\r\nbest practices, such as multi-factor authentication, Windows Defender Credential Guard, Remote Credential Guard, and\r\nApplication Control.\r\nFirewall Restrictions for Administrative Access\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 10 of 17\n\nConfigure the ESXi hosts and vCenter Servers to only allow connections on their administrative interfaces from the IP\r\naddresses of the privileged management workstations mentioned in the previous section. Ensure that these firewall\r\nconfigurations apply to each service utilized by the server, such as SSH, vSphere Web Access, etc. Alternatively, utilize a\r\nnetwork firewall appliance in front of the ESXi and vCenter Server administrative interfaces and implement the IP\r\naddress restrictions there.\r\nFigure 15 shows the PowerCLI command that can be used to list all services on ESXi host(s).\r\nPS C:\\\u003e Get-VMHostService -VMHost 192.168.1.10\r\n \r\nKey Label Policy Running Required\r\n--- ----- ------ ------- --------\r\nDCUI Direct Console UI on True False\r\nTSM ESXi Shell on True False\r\nTSM-SSH SSH on True False\r\nattestd attestd off False False\r\ndpd dpd off False False\r\nkmxd kmxd off False False\r\nlbtd Load-Based Teaming Daemon on True False\r\nlwsmd Active Directory Service off False False\r\nntpd NTP Daemon on True False\r\npcscd PC/SC Smart Card Daemon off False False\r\nptpd PTP Daemon off False False\r\nsfcbd-watchdog CIM Server on False False\r\nslpd slpd off False False\r\nsnmpd SNMP Server on False False\r\nvltd vltd off False False\r\nvmsyslogd Syslog Server on True True\r\nvpxa Vmware vCenter Agent on False False\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 11 of 17\n\nxorg X.Org Server on False False\r\nFigure 15: PowerCLI command to list all services\r\nThe firewall on ESXi hosts is enabled by default and can be managed from the vSphere client web UI, the ESXCLI\r\ncommand shell, and PowerCLI. By default, the firewall is configured to block both incoming and outgoing network\r\ntraffic. Services that are enabled in the host’s security profile are allowed through the host firewall and are configured to\r\nallow access for all IP addresses. To further harden access to services, configure the ESXi firewall to allow access only\r\nfrom the IP addresses of privileged management workstations.\r\nFigure 16 shows the PowerCLI command that retrieves and lists the ESXi host firewall exceptions.\r\nPS C:\\\u003e Get-VMHostFirewallException -VMHost 192.168.1.10\r\n \r\nName Enabled IncomingPorts OutgoingPorts Protocols ServiceRunning\r\n---- ------- ------------- ------------- --------- --------------\r\nCIM Server True 5988 TCP False\r\nCIM Secure Server True 5989 TCP False\r\nCIM SLP True 427 427 UDP, TCP False\r\nDHCPv6 True 546 547 TCP, UDP\r\nDVFilter False 2222 TCP\r\nDVSSync True 8301, 8302 8302, 8301 UDP\r\nHBR True 31031, 44046 TCP\r\nNFC True 902 902 TCP\r\nWOL True 9 UDP\r\nActive Directory All False 2020 88, 123, 13... UDP, TCP\r\nvSAN Clustering S... False 12345, 2345... 12345, 2345... UDP\r\nDHCP Client True 68 68 UDP\r\nDNS Client True 53 UDP, TCP\r\nesxio-orchestrator False 8084 TCP\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 12 of 17\n\nesxupdate False 443 TCP\r\netcdClientComm False 2379 2379 TCP\r\netcdPeerComm False 2380 2380 TCP\r\nFault Tolerance True 8300 80, 8300 TCP\r\nFTP Client False 20 21 TCP\r\ngdbserver False 1000-9999, ... TCP\r\ngstored False 443 TCP\r\nhttpClient False 80, 443 TCP\r\nSoftware iSCSI Cl... False 3260 TCP\r\niofiltervp True 9080 TCP\r\nNSX Distributed L... False 6999 6999 UDP\r\niwarp-pm False 3935 3935 UDP\r\nnfs41Client False 0-65535 TCP\r\nNFS Client False 0-65535 TCP\r\nNTP Client True 123 UDP True\r\nnvmetcp False 8009, 4420 TCP\r\nPTP Client False 319-320 319-320 UDP False\r\npvrdma False 28250-28761 28250-28761 TCP\r\nvSAN Transport False 2233, 12443 2233, 12443 TCP\r\nVM serial port co... False 23, 1024-65535 0-65535 TCP\r\nsettingsd False 8083 8083 TCP\r\nSNMP Server True 161 UDP False\r\nSSH Client False 22 TCP\r\nSSH Server True 22 TCP\r\nsyslog False 514, 1514 UDP, TCP\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 13 of 17\n\ntrusted-infrastru... True 0-65535 TCP\r\ntrusted-infrastru... False 0-65535 TCP\r\nvCenter Update Ma... True 80, 9000-9100 TCP\r\nvMotion True 8000 8000 TCP\r\nVM serial port co... False 0-65535 TCP\r\nvSphereCCP False 81, 444, 20... 81, 444, 20... TCP\r\nvSphere Web Client True 902, 443 TCP\r\nvdfs False 1564 1564 TCP\r\nvic-engine False 2377 TCP\r\nvit False 3260 TCP\r\nvltd False 1492 TCP False\r\nVMware vCenter Agent True 902 UDP False\r\nvsanEncryption False 0-65535 TCP\r\nvsanhealth-unicas... False 5201 5201 UDP, TCP\r\nvvold False 0-65535 TCP\r\nvSphere Web Access True 80 TCP\r\nFigure 16: PowerCLI command to list all firewall exceptions\r\nFor additional information on ESXi Firewall Configuration, reference VMware’s ESXi page.\r\nSign On Identity Sources\r\nAt the time of this blog post, it is unknown how the attackers initially gained privileged access to the vCenter Server.\r\nMandiant recommends reviewing current identity source configurations to enforce the mindset of least privilege for\r\naccess to ESXi hosts and vCenter Servers.\r\nIdentity sources on vCenter Servers dictate which external services (if any) vCenter will utilize to authorize\r\nadministrative users to the vCenter Server. Possible identity sources include native Microsoft Active Directory Domains\r\nand OpenLDAP directory services. Microsoft Active Directory can be configured to utilize Integrated Windows\r\nAuthentication or LDAP.\r\nMandiant has observed threat actors discovering the presence of ESXi hosts and vCenter Servers that are integrated with\r\nMicrosoft Active Directory and actively targeting the administrative accounts to infiltrate the VMware hypervisor\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 14 of 17\n\ninfrastructure. Consider decoupling ESXi and vCenter Servers from Active Directory and use vCenter Single Sign-On.\r\nRemoving ESXi and vCenter from Active Directory will prevent any compromised Active Directory accounts from being\r\nable to be used to authenticate directly to the virtualization infrastructure.\r\nIf Active Directory is utilized as an identity source, Mandiant recommends actively monitoring the groups and/or users\r\nthat are allowed to perform ESXi and vCenter administrative capabilities for changes/modifications/additions.\r\nFor additional information on configuring vSphere authentication please see VMware’s documentation regarding vCenter\r\nsingle sign-on.\r\nMulti-Factor Authentication (MFA) for Admins\r\nAttackers will commonly target the vCenter Server Appliance and leverage single-factor authentication for accessing\r\napplications with legitimate or stolen credentials. Using MFA reduces the risk of an attacker gaining access to highly\r\nprivileged systems and applications.\r\nMandiant recommends enforcing MFA to access all vCenter Server instances. Some supported methods of utilizing\r\nmultifactor authentication with vCenter Server include smart card authentication, RSA SecureID Authentication, and Duo\r\nSecurity. For additional information related to MFA integration, please reference this VMware article.\r\nDisable Remote SSH\r\nAttackers have often targeted and utilized SSH access on ESXi and vCenter hosts to gain access and propagate malware\r\nthroughout the environment. Eliminating the exposure of open ports reduces the ability for an attacker to leverage this\r\nmethod of access. Some management solutions require the use of SSH to accomplish their automated tasks. If one of\r\nthese solutions is being utilized, SSH access can be secured by using an allow list to limit appropriate source IP addresses\r\nthat are used by the management solution.\r\nFigure 17 shows the PowerCLI command that can be used to list the status of SSH on ESXi host(s).\r\nPS C:\\\u003e Get-VMHostService -VMHost 192.168.1.10 | Where-Object {$_.Key -match “SSH”}\r\nKey Label Policy Running Required\r\n--- ----- ------ ------- --------\r\nTSM-SSH SSH on True False\r\nFigure 17: PowerCLI command to list status of SSH service\r\nEnable Lockdown Mode\r\nRequiring all access to occur through the vCenter Server can reduce the risk of an attacker bypassing access controls and\r\naccessing the ESXi host directly, then leveraging that access to elevate privileges or perform other malicious activity.\r\nEnabling Lockdown Mode disables direct access to an ESXi host and requires that the host be managed remotely using\r\nvCenter. This is done to ensure the roles and access controls implemented in vCenter are always enforced and users\r\ncannot bypass them by logging into a host directly. By forcing all interaction to occur through vCenter, the risk of\r\nsomeone inadvertently attaining elevated privileges or performing tasks that are not properly audited is greatly reduced.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 15 of 17\n\nTo reduce the risk and exposure of credentials correlating to accounts with access to vCenter, it is recommended that\r\nunique and dedicated accounts be used for this access. If vCenter must be joined to an on-premises Active Directory (AD)\r\ndomain and Integrated Windows Authentication is configured, the scope of accounts provided access to vCenter should be\r\nrestricted to a small subset, where the account(s) are not co-utilized for performing interactive or remote logons for\r\nendpoints.\r\nFigure 18 shows the PowerCLI command that can be used to determine the Lockdown status of an ESXi host.\r\nPS C:\\\u003e (Get-VMHost 192.168.1.10).ExtensionData.Config.LockdownMode\r\nlockdownDisabled\r\nFigure 18: PowerCLI command to show LockdownMode status\r\nEnforcing VIB Acceptance Levels \u0026 Conducting VIB Verification\r\nConfiguring a more secure acceptance level will restrict the installation of unsigned VIBs to protect the security and\r\nintegrity of an ESXi host. Determine the appropriate risk acceptance level for vSphere Installable Bundles (VIBs) and\r\nenforce acceptance levels in the Security Profiles for ESXi hosts. This protects the integrity of the hosts and ensures\r\nunsigned VIBs cannot be installed.\r\nVMware and Mandiant recommend not allowing users to install unsigned (community-supported) VIBs. Concurrently\r\nwith Mandiant’s disclosure of threat actors utilizing unsigned VIBs to install backdoors on compromised ESXi hosts via\r\nthe Bad VIB(E) Part One and Part Two blog posts in September 2022, VMware published the Mitigation and Threat\r\nHunting Guidance for Unsigned vSphere Installation Bundles (VIBs) in ESXi article. This VMware article includes a\r\nPowerCLI script that can be utilized to audit ESXi hosts for unsigned VIBs.\r\nFinding unsigned VIBs on ESXi hosts is not definitive proof of a compromise. Mandiant and VMware recommend\r\norganizations investigate the origin of any installed unsigned VIBs and if a compromise is suspected, follow their\r\nestablished incident response procedures.\r\nPrevent Execution of Unsigned Binaries and Enable Secure Boot\r\nEnabling the  execInstalledOnly  feature in ESXi will restrict unsigned binaries from being executed in the ESXi host\r\nand can ensure that only signed binaries are allowed. This can significantly reduce the risk of unknown executable files\r\nbeing executed on ESXi hosts. This article by VMware provides additional information to enable\r\nthe  execInstalledOnly  feature.\r\nMandiant recommends enabling  execInstalledOnly  enforcement using ESXCLI to change the Trusted Platform\r\nModule (TPM) configuration settings in ESXi hosts. This will enforce integrity checks of vSphere Installable Bundles\r\n(VIBs), governed by the configured acceptance level. Instructing ESXi to only execute binaries that originated from a\r\nvalid VIB installed on the host makes it harder for threat actors to use prebuilt binaries during a compromise. UEFI secure\r\nboot needs to be enabled before enforcing  execInstalledOnly  settings. For additional information for enabling UEFI\r\nSecure boot, please reference the following VMware article.\r\nCentralize VMware Logging to SIEM Solution\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 16 of 17\n\nInsufficient logging can hinder a successful response to an incident, as there may be limited evidence as to actions taken\r\nthat led to a compromise. Without a unified approach to centralized logging, organizations will encounter difficulties\r\ndetecting and responding to threats within the environment.\r\nESXi and vCenter Server record host activity in log files using a syslog facility and can be configured to store log files on\r\nan in-memory file system (which means logs will not persist reboots) or to a permanent datastore. Mandiant recommends\r\nthat all ESXi and vCenter Server host logging should always be configured to a persistent datastore. The following\r\nVMware articles cover the locations of log locations on both vCenter and ESXi.\r\nRemote logging to a central log collector or SIEM provides a secure, centralized store for vSphere logs. Having a\r\ncentralized location for logs enables detection and threat hunting at scale. Mandiant recommends that all logs for critical\r\nassets be sent to a centralized system, and that high-fidelity alerts and alert logic be configured to alert on anomalous\r\nactivity. Logging to a secure, centralized logging system also helps prevent log tampering and is also a long-term audit\r\nrecord. For information on Configuring Syslog on ESXi Hosts and ESXi Syslog Options, please reference the linked\r\nVMware articles.\r\nUtilize VMware’s vSphere Security Configuration Guide\r\nVMware has created Security Configuration Guides for specific versions of VMware products, including vSphere. These\r\nguides provide VMware’s recommended security baselines in an easy-to-read spreadsheet format with example\r\nPowerCLI commands to configure security features. VMware’s Security Configuration and Hardening Guides are\r\navailable now.\r\nConclusion\r\nAs attackers continue to find new techniques to evade detection and technologies to persist on, defenders must continue to\r\nevolve as well. To be able to identify when advanced threat actors are present in the environment, defenders need to not\r\nonly focus on building out a workflow that alerts on known indicators, but also has a strong baseline understanding of\r\nexpected activity to notify when abnormalities occur. This process is not an easy or quick one to implement, but the\r\nbenefits achieved in establishing this system are twofold. In addition to greater visibility, knowing and documenting your\r\nown environment to this degree enables streamlined communication and quicker response times when attackers do make\r\ntheir way through whatever preventative measures are in place.\r\nAcknowledgements\r\nSpecial thanks to Brad Slaybaugh, Jeremy Koppen, DJ Palombo, Joshua Kim, Matthew Maczko, Maegan Palombo, Rufus\r\nBrown, and Charles Carmakal for their assistance with the investigation and technical review of this blog post. In\r\naddition, we would also like to thank VMware for their collaboration and assistance with this research.\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://cloud.google.com/blog/topics/threat-intelligence/vmware-detection-containment-hardening"
	],
	"report_names": [
		"vmware-detection-containment-hardening"
	],
	"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
		},
		{
			"id": "f9806b99-e392-46f1-9c13-885e376b239f",
			"created_at": "2023-01-06T13:46:39.431871Z",
			"updated_at": "2026-04-10T02:00:03.325163Z",
			"deleted_at": null,
			"main_name": "Watchdog",
			"aliases": [
				"Thief Libra"
			],
			"source_name": "MISPGALAXY:Watchdog",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "47a8f6c7-5b29-4892-8f47-1d46be71714f",
			"created_at": "2025-08-07T02:03:24.599925Z",
			"updated_at": "2026-04-10T02:00:03.720795Z",
			"deleted_at": null,
			"main_name": "BRONZE FLEETWOOD",
			"aliases": [
				"APT5 ",
				"DPD ",
				"Keyhole Panda ",
				"Mulberry Typhoon ",
				"Poisoned Flight ",
				"TG-2754 "
			],
			"source_name": "Secureworks:BRONZE FLEETWOOD",
			"tools": [
				"Binanen",
				"Comfoo",
				"Gh0st RAT",
				"Isastart",
				"Leouncia",
				"Marade",
				"OrcaRAT",
				"PCShare",
				"Protux",
				"Skeleton Key",
				"SlyPidgin",
				"VinSelf"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434317,
	"ts_updated_at": 1775826750,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c50a8b1c033c616fd204c6885a4272797d45202e.pdf",
		"text": "https://archive.orkl.eu/c50a8b1c033c616fd204c6885a4272797d45202e.txt",
		"img": "https://archive.orkl.eu/c50a8b1c033c616fd204c6885a4272797d45202e.jpg"
	}
}