{
	"id": "5b84b8ea-50a0-4c6e-b0ff-00ef981094ea",
	"created_at": "2026-04-06T00:16:27.666878Z",
	"updated_at": "2026-04-10T03:21:23.046869Z",
	"deleted_at": null,
	"sha1_hash": "664613a2a8de77e956599ce6663814bff0461a0e",
	"title": "Some Notes on VIRTUALGATE – One Night in Norfolk",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 568612,
	"plain_text": "Some Notes on VIRTUALGATE – One Night in Norfolk\r\nPublished: 2022-10-03 · Archived: 2026-04-05 23:48:17 UTC\r\nLate last week, Mandiant researchers published findings from an incident response engagement detailing an\r\nattacker workflow that took place in a VMWare ESXI environment. In this workflow, the attackers placed\r\nmalware or persistence mechanisms on each layer of this environment:\r\n1. vSphere layer, which can manage multiple ESXI environments\r\n2. ESXI hypervisor layer, which can manage virtualized “guest” machines\r\n3. Virtualized guest machines\r\nA key function of several of the attacker tools placed at the ESXI and guest levels in this environment was\r\nreportedly the ability to exchange attacker commands and data between the two layers.\r\nThis blog post examines a likely sample of VIRTUALGATE, a reported malware family that sits at the guest\r\nmachine layer of this workflow. The post will provide additional technical details regarding its underlying\r\nmechanisms and provides context for how an attacker might operate in this environment.\r\nvSphere, ESXI, and Attacker Malware\r\nMandiant’s blog post detailed several layers of activity for the attackers. At the top level, the attackers gained\r\naccess to – and likely created persistence mechanisms within – the organization’s vSphere infrastructure. This in\r\nturn gave the attackers access to Virtual Machine hypervisors, which manage virtualized guest machines for the\r\nenvironment.\r\nAlthough Mandiant provided hashes for some of these files, the files were not publicly available at the time of this\r\nwriting; however, Mandiant does provide a file name (avp.exe) and a description for one of these files, which the\r\nauthors named VIRTUALGATE, a malware family designed to run on Windows operating systems:\r\nThe memory only dropper... uses VMware's virtual machine communication interface (VMCI) sockets to run commands\r\nThese two datapoints are sufficient to find a possible candidate on VirusTotal:\r\nhttps://norfolkinfosec.com/some-notes-on-virtualgate/\r\nPage 1 of 7\n\nAs the remainder of this post will show, this file’s functions align well with Mandiant’s description. This post\r\nfocuses more on how this file works rather than on further attribution efforts (although the technical relationships\r\nare implied), as the internal mechanisms would likely apply to other malware families that use the same\r\ncommunication techniques.\r\nTechnical Information\r\nMain Workflow\r\nFilename: avp.exe\r\nMD5: 3c7316012cba3bbfa8a95d7277cda873\r\nSHA1: d6a57b9aaa20fe4f3330f5979979081af09a4232\r\nSHA256: 1893523f2a4d4e7905f1b688c5a81b069f06b3c3d8c0ff9d16620468d117edbb\r\nAs Mandiant noted, the file consists of a loader and DLL. Once loaded in memory, the payload uses three main\r\ncomponents:\r\n– A function containing API calls typically seen in files that use Sockets (Winsock)\r\n– A function referencing cmd.exe\r\n– A reference to a log file, with format strings suggesting timestamped entries\r\nThe socket workflow is responsible for launching the other two components.\r\nSocket API calls\r\nhttps://norfolkinfosec.com/some-notes-on-virtualgate/\r\nPage 2 of 7\n\nImmediately following the “recv” API call, there is a series of function calls that eventually leads to the execution\r\nof cmd.exe with the “/c” option:\r\nRecv followed by branch leading to cmd.exe\r\nRunning the malware dynamically also creates a log entry in the user’s AppData\\Temp folder, the contents of\r\nwhich conform to the format string mentioned above:\r\nLog file generated during the malware’s execution\r\nNotably, this log entry closely resembles the format of the logs produced by another file described in the Mandiant\r\nreport, lending additional weight to the likelihood that this file is part of the same attacker toolset. The log entry\r\nimplies that the malware is configured to interact using port 25736.\r\nA reasonable hypothesis would be that the malware opens a listener (likely on port 25736) and executes data that\r\nit receives through this listener via cmd.exe, given the order of these observed functions as well as the contents of\r\nthe log file and the description of VIRTUALGATE in the Mandiant report.\r\nA Detour to VMCI Sockets\r\nAt this stage, we would want to test this hypothesis by sending data over this port.\r\nTypically, during dynamic analysis, researchers can use tools such as Process Hacker to help identify network\r\nconnections and processes that are listening on unusual ports. Unfortunately, the port does not appear in Process\r\nHacker’s capture:\r\nhttps://norfolkinfosec.com/some-notes-on-virtualgate/\r\nPage 3 of 7\n\nCommands such as “netstat” also yield no results. Revisiting Mandiant’s description offers a hint as to why this\r\nmight be through its reference to VMCI sockets:\r\nThe memory only dropper... uses VMware's virtual machine communication interface (VMCI) sockets to run commands\r\nThe following additional branch off of the “socket function” above also offers some clues:\r\nhttps://norfolkinfosec.com/some-notes-on-virtualgate/\r\nPage 4 of 7\n\nThese API calls and Mandiant’s description lead to two useful resources:\r\n– VMWare’s documentation regarding “VMCI sockets”\r\n– A snippet on Github that can help an analyst understand how these work at a programming-level\r\n– A second page that includes a CreateFile call for “vmci” which provides another code example\r\nhttps://norfolkinfosec.com/some-notes-on-virtualgate/\r\nPage 5 of 7\n\nLooking first at VMWare’s documentation, we learn that:\r\nVMCI sockets are similar to other socket types... VMCI sockets work on an individual physical machine, and like\r\nThis documentation also provides an overview of the functions involved, including:\r\n– Bind() – “Associates the stream socket with the network settings in the sockaddr_vm structure\r\n– Listen () – “Prepares to accept incoming client connections”\r\n– Accept() – “Waits indefinitely for an incoming connection to arrive”\r\n– Recv() – “Reads data from the client application”\r\n– Send() – “Writes data to the client application”\r\nThis helps explain why the we saw familiar function names, but did not observe the behavior we expected. At this\r\npoint, we have enough information to conclude that we are likely dealing with a VMCI socket, and not a “normal”\r\nsocket.\r\nTesting VMCI Connections\r\nThe final piece to this puzzle is finding a way to view a VMCI connection (also referred to as vsockets).\r\nFortunately, there is outstanding research publicly available from Pedro Mendes da Silva. This whitepaper\r\nexplains why the virtual sockets may not be visible using traditional tools:\r\n“vsockets” can be used much the same way as TCP/IP sockets but using a different address family. “vsockets” can\r\nFortunately, the author provides a set of tools available here to help work with these vsockets. Using one of these\r\ntools, we can:\r\n– Test a connection over port 25736 to see if it is open\r\n– Test sending a cmd.exe command (e.g. “notepad.exe”) over this port to validate the execution workflow\r\n– Repeat the test over a port expected to be closed, to validate that this only works for this port\r\nThis test is relatively straightforward:\r\navp.exe spawning cmd.exe and notepad.exe following the vsocket connection\r\nThe success of the test is evident both in the creation of notepad.exe and the process tree evidence showing\r\navp.exe spawning the command shell. At this stage, the malware’s functionality is validated.\r\nhttps://norfolkinfosec.com/some-notes-on-virtualgate/\r\nPage 6 of 7\n\nConcluding Thoughts\r\nThe novelty and complexity of the malware examined in this post does not reside in its functionality; at face\r\nvalue, the malware receives data over a socket and executes a command. Instead, the complexity lies in the\r\n(somewhat) esoteric nature of the ecosystem it is installed in. As Mandiant notes in its blog post, ESXI\r\nenvironments are less likely to have EDR products present to detect the steps leading to the installation of this\r\nmalware in the first place.\r\nSource: https://norfolkinfosec.com/some-notes-on-virtualgate/\r\nhttps://norfolkinfosec.com/some-notes-on-virtualgate/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://norfolkinfosec.com/some-notes-on-virtualgate/"
	],
	"report_names": [
		"some-notes-on-virtualgate"
	],
	"threat_actors": [],
	"ts_created_at": 1775434587,
	"ts_updated_at": 1775791283,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/664613a2a8de77e956599ce6663814bff0461a0e.pdf",
		"text": "https://archive.orkl.eu/664613a2a8de77e956599ce6663814bff0461a0e.txt",
		"img": "https://archive.orkl.eu/664613a2a8de77e956599ce6663814bff0461a0e.jpg"
	}
}