{ "id": "6b406585-f038-4232-a6ca-3cf8c02d7c77", "created_at": "2026-04-06T00:21:37.53781Z", "updated_at": "2026-04-10T13:12:09.427053Z", "deleted_at": null, "sha1_hash": "67713300cf50f900d59bed7c5bcfd6adad53e900", "title": "Infiltrating Defenses: Abusing VMware in MITRE’s Cyber Intrusion", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1107690, "plain_text": "Infiltrating Defenses: Abusing VMware in MITRE’s Cyber\r\nIntrusion\r\nBy Lex Crumpton\r\nPublished: 2025-04-03 · Archived: 2026-04-05 14:48:41 UTC\r\nWritten by\r\nand Charles Clancy.\r\n⚠️ This post has moved to our new blog and is kept here for archival purposes.\r\nhttps://ctid.mitre.org/blog/2024/05/22/infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion/\r\nPress enter or click to view image in full size\r\nhttps://medium.com/mitre-engenuity/infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion-4ea647b83f5b\r\nPage 1 of 7\n\nImage Credit: GPT-4o / DALL-E 3\r\nThis is the third and final blog post in a series detailing MITRE’s encounter with a state-sponsored cyber threat\r\nactor in our research and experimentation network, NERVE. It builds upon the insights shared in our April 19,\r\n2024 post, “Advanced Cyber Threats Impact Even the Most Prepared” and May 3, 2024 post “Technical Deep\r\nDive: Understanding the Anatomy of a Cyber Intrusion”. We continue to work across MITRE, including our\r\nInformation Security Team, to help all security teams understand and defend against this threat.\r\nIn this post of our series, we provide technical details of new behavior employed by the adversary, who aligns\r\nwith Google Mandiant’s UNC5221, and how the BRICKSTORM backdoor and BEEFLUSH web shell abused\r\nVMs in VMware through a privileged user account, VPXUSER, to establish persistence within the impacted\r\nenvironment. We will also provide detection scripts, from MITRE and CrowdStrike, to find this activity in other\r\nenvironments and go over how Secure Boot serves as a barrier against the adversary technique.\r\nRecap from Parts One \u0026 Two\r\nIn our first blog post, we shared the experience of facing a cyber intrusion that targeted MITRE’s Networked\r\nExperimentation, Research, and Virtualization Environment (NERVE) through two Ivanti Connect Secure zero-https://medium.com/mitre-engenuity/infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion-4ea647b83f5b\r\nPage 2 of 7\n\nday vulnerabilities that bypassed our multi-factor authentication. The adversary maneuvered within the research\r\nnetwork via VMware infrastructure using a compromised administrator account, then employed a combination of\r\nbackdoors and web shells to maintain persistence and harvest credentials.\r\nIn our second blog post, we took a deep dive into the technical details of the intrusion, including a timeline of\r\nevents, indicators of compromise, and malware analysis. Additionally, we disclosed novel aspects not previously\r\nreported by Mandiant or other threat intelligence sources, including:\r\nDetails on the BEEFLUSH web shell; and\r\nUnique components of the BUSHWALK web shell seen in our incident.\r\nTable 1. Notable MITRE ATT\u0026CK® techniques shared in our initial blog\r\nBefore delving into the techniques employed by the adversary to abuse VMware infrastructure, it is essential to\r\nunderstand the overarching context: the adversary had already gained administrative access to NERVE ESXi\r\ninfrastructure.\r\nCreated Rogue VMs\r\nRogue VMs are created and managed through service accounts directly on the hypervisor, rather than through the\r\nvCenter administrative console. As a result, these VMs do not appear in the inventory.\r\nAs we said in the second post, “On January 5, 2024, the adversary escalated their attack with manipulated VMs\r\nand compromised administrative credentials to establish control over the infrastructure. Specifically, their actions\r\nincluded attempted enablement of SSH, destruction of one of their own VMs, and file downloads.”\r\nThe adversary created their own rogue VMs within the VMware environment, leveraging compromised vCenter\r\nServer access. They wrote and deployed a JSP web shell (BEEFLUSH) under the vCenter Server’s Tomcat server\r\nto execute a Python-based tunneling tool, facilitating SSH connections between adversary-created VMs and the\r\nESXi hypervisor infrastructure.\r\nBy deploying rogue VMs, adversaries can evade detection by hiding their activities from centralized\r\nmanagement interfaces like vCenter. This allows them to maintain control over compromised systems\r\nwhile minimizing the risk of discovery.\r\nDetecting Adversary Activity in VMware Ecosystem\r\nIn VMware’s environment, spotting adversary activity demands meticulous scrutiny. For instance, adversaries\r\nmight enable SSH on hypervisors and log in by routing traffic through the vCenter Server. This technique\r\nunderscores the importance of monitoring SSH activity for signs of unauthorized access.\r\nWhat to Look for:\r\n1. Anomalous SSH Enablement: Keep a close watch for unexpected occurrences of “SSH login enabled”\r\nmessages. Any activation of SSH outside the normal administrative cycle could indicate malicious activity.\r\nhttps://medium.com/mitre-engenuity/infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion-4ea647b83f5b\r\nPage 3 of 7\n\n2. Unusual SSH Sessions: Monitor for deviations from the expected pattern of SSH sessions being opened.\r\nLook out for instances where “SSH session was opened for” messages occur unexpectedly or at unusual\r\ntimes.\r\nTable 2. Notable ATT\u0026CK techniques\r\nDeploying Rogue VMs\r\nAs we said in the second post, “Moving forward to January 7, 2024, the adversary accessed VMs and deployed\r\nmalicious payloads, the BRICKSTORM backdoor and the BEEFLUSH web shell. The adversary also used a\r\ndefault VMware account, VPXUSER, to make seven API calls that enumerated a list of mounted and unmounted\r\ndrives.”\r\nThe adversary bypassed detection mechanisms by deploying rogue VMs, as VPXUSER, directly onto hypervisors\r\nusing SFTP to write files then executed them with /bin/vmx . By doing this, these rogue VMs were not\r\ndiscoverable via vCenter, the ESXi web interface, and even some on-hypervisor command-line utilities that query\r\nthe API.\r\nGet Lex Crumpton’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nThese rogue VMs contained the BRICKSTORM backdoor and persistence mechanisms, see blog post 2, that\r\nwere configured with dual network interfaces for communication with both the Internet/C2 and core\r\nadministrative subnets within the prototyping network.\r\nAdversaries often can leverage the vpxuser account to perform various administrative tasks, such as\r\nenumerating VMs, accessing configuration settings, and interacting with the underlying hypervisor\r\ninfrastructure. Additionally, adversaries may deploy rogue VMs directly onto hypervisors to evade\r\ndetection mechanisms and maintain persistence within the environment. Rogue VMs, which are created\r\nand operated without proper authorization and management by the hypervisor, provide adversaries with\r\na stealthy foothold for conducting malicious activities. These VMs can bypass visibility controls within\r\nVMware management interfaces, making them difficult to detect and mitigate.\r\nDetecting Rogue VMs\r\nSafeguarding against rogue VMs and any ensuing persistence demands a vigilant approach. Simply using the\r\nhypervisor management interface to manage VMs is often insufficient and can be pointless when it comes to\r\ndealing with rogue VMs. This is because rogue VMs operate outside the standard management processes and do\r\nnot adhere to established security policies, making them difficult to detect and manage through the GUI alone.\r\nInstead, one needs special tools or techniques to identify and mitigate the risks associated with rogue VMs\r\neffectively.\r\nhttps://medium.com/mitre-engenuity/infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion-4ea647b83f5b\r\nPage 4 of 7\n\nWhat to Look For:\r\nCommand-Line Usage: Utilize the following commands on an ESXi hypervisor to identify unregistered VMs:\r\n1. vim-cmd vmsvc/getallvms\r\n2. esxcli vm process list | grep Display\r\nComparison of VM Lists: Compare the output of vim-cmd (API-based VM check) with the list of running VMs\r\nobtained from esxcli .\r\n1. Differences in the list of VMs between the output of a vim-cmd (that will check for VMs via the API) and\r\nthe list of running VMs that esxcli sees (which directly queries the host hypervisor) indicate a potential\r\nproblem. A VM running on a hypervisor that is not seen via the registered VM data via API warrants\r\nfurther investigation as a possible unregistered/rogue VM.\r\nDetecting VMware Persistence\r\nTo address the persistence of these rogue VMs, it is crucial to scrutinize the hypervisor’s startup scripts.\r\nWhat to Look For\r\nPersistence Mechanism: Monitor for modification of the legitimate /etc/rc.local.d/local.sh file to include\r\nthe following line:\r\n/bin/vmx -x /vmfs/volumes/\u003cREDACTED_VOLUME\u003e/\u003cREDACTED_VM_NAME\u003e/\u003cREDACTED_VM_NAME\u003e.vmx 2\u003e/dev/null 0\u003e/\r\nPersistence Identification: Search for invocations of the /bin/vmx binary within /etc/rc.local.d/ or more\r\nspecifically by manually reviewing the local.sh startup script with the following commands:\r\n1. grep -r \\/bin\\/vmx /etc/rc.local.d/\r\n2. cat /etc/rc.local.d/local.sh\r\nTable 3. Notable ATT\u0026CK techniques\r\nSuspicious VMware Detection Scripts\r\nMITRE is sharing two scripts designed to identify and mitigate potential threats within the VMware environment.\r\nThe first script, developed by MITRE, Invoke-HiddenVMQuery is written in PowerShell and serves to detect\r\nmalicious activities. It scans for anomalous invocations of the /bin/vmx binary within rc.local.d scripts.\r\nFurthermore, it checks for the presence of rogue VMs by cross-referencing data obtained from two sources: the\r\nvim-cmd utility, which queries VMs via the API, and the list of running VMs retrieved by esxcli , a command-line interface directly querying the host hypervisor. Any VM detected running on a hypervisor but not listed via\r\nthe registered VM data via API warrants immediate investigation as a potential threat.\r\nhttps://medium.com/mitre-engenuity/infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion-4ea647b83f5b\r\nPage 5 of 7\n\nWe are also sharing a PowerShell script, VirtualGHOST, that CrowdStrike prepared to help detect evidence of\r\nunregistered VMs using PowerCLI and help scale hunting exercises by executing the scripts remotely. Thanks to\r\nCrowdStrike for their collaboration in identifying these adversary tactics, techniques, and procedures (TTPs).\r\nBy leveraging these scripts, organizations can identify and respond to suspicious activities, bolstering their\r\ncybersecurity defenses against evolving threats.\r\nRecommended Mitigation Strategy\r\nBased on consultation with the VMware PSIRT team, the most effective countermeasure to thwart the persistence\r\nmechanism is to enable secure boot. Secure boot is a security feature designed to verify the integrity of a host’s\r\nboot process, mitigating the risk of unauthorized modifications.\r\nEnabling secure boot serves as one defense against adversaries seeking to establish persistent access within the\r\nVMware environment. By verifying the integrity of the boot process, secure boot prevents malicious actors from\r\ninjecting unauthorized code.\r\nThis countermeasure aligns with the MITRE ATT\u0026CK Mitigation: Boot Integrity (M1046).\r\nBy fortifying the boot process with secure boot, organizations can thwart adversaries’ efforts to evade detection\r\nand maintain unauthorized access to critical systems.\r\nFor detailed information on this feature and its implementation, please refer to the following resource: VMware\r\nSecure Boot Documentation.\r\nConclusion\r\nAs adversaries continue to evolve their tactics and techniques, it is imperative for organizations to remain vigilant\r\nand adaptive in defending against cyber threats. By understanding and countering their new adversary behaviors,\r\nwe can bolster our defenses and safeguard critical assets against future intrusions.\r\nFor additional IOCs and context, including for more detail on the exploits, backdoors, and C2 involved, please see\r\nour prior post.\r\nAbout the Center for Threat-Informed Defense\r\nThe Center for Threat-Informed Defense is a non-profit, privately funded research and development organization\r\noperated by MITRE Engenuity. The Center’s mission is to advance the state of the art and the state of the practice\r\nin threat-informed defense globally. Comprised of participant organizations from around the globe with highly\r\nsophisticated security teams, the Center builds on MITRE ATT\u0026CK, an important foundation for threat-informed\r\ndefense used by security teams and vendors in their enterprise security operations. Because the Center operates\r\nfor the public good, outputs of its research and development are available publicly and for the benefit of all.\r\n© 2024 MITRE Engenuity, LLC. Approved for Public Release. Document number CT0117.\r\nhttps://medium.com/mitre-engenuity/infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion-4ea647b83f5b\r\nPage 6 of 7\n\nSource: https://medium.com/mitre-engenuity/infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion-4ea647b83f5b\r\nhttps://medium.com/mitre-engenuity/infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion-4ea647b83f5b\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://medium.com/mitre-engenuity/infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion-4ea647b83f5b" ], "report_names": [ "infiltrating-defenses-abusing-vmware-in-mitres-cyber-intrusion-4ea647b83f5b" ], "threat_actors": [ { "id": "b2e48aa5-0dea-4145-a7e5-9a0f39d786d8", "created_at": "2024-01-18T02:02:34.643994Z", "updated_at": "2026-04-10T02:00:04.959645Z", "deleted_at": null, "main_name": "UNC5221", "aliases": [ "UNC5221", "UTA0178" ], "source_name": "ETDA:UNC5221", "tools": [ "BRICKSTORM", "GIFTEDVISITOR", "GLASSTOKEN", "LIGHTWIRE", "PySoxy", "THINSPOOL", "WARPWIRE", "WIREFIRE", "ZIPLINE" ], "source_id": "ETDA", "reports": null }, { "id": "6ce34ba9-7321-4caa-87be-36fa99dfe9c9", "created_at": "2024-01-12T02:00:04.33082Z", "updated_at": "2026-04-10T02:00:03.517264Z", "deleted_at": null, "main_name": "UTA0178", "aliases": [ "UNC5221", "Red Dev 61" ], "source_name": "MISPGALAXY:UTA0178", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434897, "ts_updated_at": 1775826729, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/67713300cf50f900d59bed7c5bcfd6adad53e900.pdf", "text": "https://archive.orkl.eu/67713300cf50f900d59bed7c5bcfd6adad53e900.txt", "img": "https://archive.orkl.eu/67713300cf50f900d59bed7c5bcfd6adad53e900.jpg" } }