Recorded Future’s Insikt Group published research on November 10, 2026 describing GhostFrame, a previously undocumented post-exploitation framework built specifically for VMware ESXi hypervisors. The report, written by Lawrence Stowe and Jerrilee Plude, ties the framework to a threat activity cluster the company tracks as TAG-218, whose operations overlap with Settra ransomware intrusions. GhostFrame contains no exploit and breaks into nothing on its own. It assumes the attacker already holds root on the ESXi host, and its entire design covers what happens next: turning one compromised hypervisor into a control plane for every virtual machine running on top of it.
A single production ESXi host routinely runs domain controllers, file servers, databases, and backup infrastructure side by side. An operator with root on that host can read the memory and disks of all of them, watch their consoles, and route traffic through the host into the network segments the guests occupy, all without dropping malware inside a single guest. Unit 42, documenting the same broader trend from the incident response side, describes this class of technique as a way to bypass in-guest endpoint detection and response (EDR) entirely. GhostFrame is the first publicly documented framework that packages the whole workflow, from persistence to credential theft, into one operator panel purpose-built for ESXi.
What is GhostFrame? An ESXi post-exploitation framework
Insikt Group’s analysis of recovered frontend files shows a web-based operator panel with two sections, “Sessions” and “Builder.” The builder generates an ESXi implant named vmhostd-core, an ELF binary, and walks the operator through deployment: compiling the binary, manually disabling the ESXi firewall, and executing the implant from a datastore. The sessions view lists connected hypervisors and exposes the framework’s post-exploitation tooling against each one.
Existing root-level access is the prerequisite throughout. GhostFrame is what an attacker installs after the perimeter has already failed, which fits how TAG-218 operates. Its initial access activity, observed between late August and October 2026, concentrated on VPN appliances and went after hypervisors only later.
Why attackers target ESXi hypervisors
ESXi runs VMware’s proprietary VMkernel with a minimal Unix-like userland. Organizations cannot install standard endpoint agents on it the way they would on a general-purpose operating system. The EDR products protecting a Windows guest see processes, registry writes, and network connections inside that guest, and they have no view of what the layer beneath does with the guest’s .vmdk files or RAM.
Attackers have known this for years. Mandiant documented ESXi backdoors installed as vSphere Installation Bundles in September 2022, and the ESXiArgs campaign of February 2023 encrypted virtual disk files at scale by exploiting the OpenSLP heap overflow CVE-2021-21974 on unpatched hosts. GhostFrame adds a builder, a session manager, and integrated tooling that treats the hypervisor as the operating environment for the whole intrusion.
How GhostFrame persists on ESXi hosts
The recovered ELF sample establishes persistence in a way that only makes sense on ESXi. The implant copies itself to /opt/vmhostd-core and modifies /etc/rc.local.d/local.sh, the boot-time script ESXi executes for administrator customizations. The modified script launches the implant and then disables two security controls, the ESXi firewall and the execInstalledOnly setting, on a loop that repeats roughly every five seconds. It also invokes /sbin/auto-backup.sh so the changes survive a reboot.
Each piece of that chain relies on documented ESXi behavior. Much of the ESXi root filesystem lives in memory, so configuration changes vanish at reboot unless they are written to the boot bank. The auto-backup.sh script performs that save by packaging the host configuration into state.tgz, and ESXi normally runs it on an hourly cron schedule. By calling it directly after editing local.sh, the implant commits its boot script to persistent storage immediately, with no risk of a reboot landing before the next scheduled backup.
The five-second loop is the more aggressive touch. An administrator who notices the firewall is off and re-enables it will watch the setting revert within seconds. Insikt Group’s mitigation guidance states the operational consequence plainly: re-enabling the controls without removing the persistence mechanism achieves nothing.
Why execInstalledOnly matters
When the execInstalledOnly VMkernel boot option is set to TRUE, ESXi executes only binaries that have been packaged and signed as part of a VIB, and an attacker-dropped ELF binary falls outside that category. Enforcement is layered. It builds on UEFI Secure Boot, and on hosts with a TPM 2.0 the setting can be sealed so it is enforced at every boot. Where that hardware-backed enforcement is absent, root access is enough to flip the option with esxcli. Disabling it in a loop keeps the implant runnable even after an administrator restores the restriction.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
For cover, the implant rewrites its process name and command-line representation to appear as vmhostd, a near match for VMware’s legitimate vmware-hostd management daemon. A casual glance at a process list shows something that looks like it belongs.
GhostFrame C2 traffic: the six-port connection race
GhostFrame’s command-and-control (C2) logic is unusual enough to work as a detection opportunity. The analyzed sample opens simultaneous TCP connection attempts to the same server across six ports: 53, 2222, 3389, 4444, 8443, and 9443. Whichever connection completes first becomes the C2 channel, and the rest are closed. If nothing connects within thirty seconds, the implant waits a randomized five to twelve seconds and tries the full set again.
The ports look like a survey of what might plausibly leave a network: TCP 53 (DNS), 2222 (a common alternate SSH port), 3389 (RDP), 8443 and 9443 (alternate HTTPS), and 4444, long associated with default listener configurations in offensive tooling. Racing all six raises the odds that one matches a permissive egress rule, and the jittered retry avoids a fixed beaconing cadence. The cost to the operator is a distinctive pattern on the wire: six near-simultaneous TCP SYN packets from an ESXi host to a single external IP, repeated on failure. Legitimate hypervisor management traffic does not behave this way. Insikt Group flags the burst as a behavioral detection that survives C2 address rotation, and I would build a rule on it. A hypervisor management interface that fans out connections to one internet destination across six ports is anomalous whatever malware family produced it.
In-memory shellcode loader and fallback shell
Once the channel is up, the implant works mainly as an in-memory shellcode loader. It receives machine code from the C2 server, allocates executable memory, and runs the payload without writing it to disk. If the executable allocation fails, it falls back to a conventional /bin/sh reverse shell so the operator keeps interactive access either way. For forensic teams, the interesting material therefore sits in process memory and network telemetry, and the datastore holds little of it. The on-disk footprint is the implant binary and its boot script edits, which is where host-side hunting should concentrate.
Controlling guest VMs from the hypervisor
The session interface turns routine hypervisor administration into offensive capability. GhostFrame enumerates registered VMs with their names and power states, changes those power states, and creates or deletes snapshots. It can enable VNC access to individual VMs and relay the graphical session through the C2 infrastructure back to the operator panel. It can also expose the ESXi HTML Host Client, the host’s built-in browser management interface, through an operator-controlled tunnel.
The VNC feature leans on a legitimate ESXi capability. The hypervisor includes a per-VM VNC server, enabled through advanced configuration options such as RemoteDisplay.vnc.enabled with a port assignment, and historically used for console access without vCenter. Because the hypervisor serves the VNC endpoint, the operator sees the guest’s screen, including a logged-in administrator desktop or a pre-boot state, with no guest credentials and no network path into the guest OS. Relaying the session through the C2 channel means the console traffic never has to be exposed on a reachable port.
Snapshots matter for a separate reason. A snapshot of a running VM captures its memory state to files on the datastore, which is the raw material for the credential tooling described below. For lateral movement beyond the host, GhostFrame ships gfsox, a SOCKS5 proxy component that routes operator traffic through the compromised hypervisor into internal networks and services that are unreachable from the internet. A hypervisor has legs into management and storage networks by design, which makes it a natural pivot.
How GhostFrame steals credentials without touching the guests
The framework integrates two credential access mechanisms that operate at different layers.
The first, sdkmon, is described in the recovered frontend as a credential interceptor. It modifies the ESXi service configuration and intercepts authentication traffic, capturing usernames and passwords from subsequent logins to the ESXi host itself. Insikt Group attributes this description to its frontend analysis. Every future login by an administrator of the virtualization estate feeds the attacker fresh, valid credentials for the management plane.
The second mechanism reaches into the guests without entering them. GhostFrame integrates VMkatz, an open-source, Rust-based tool that extracts Windows credentials directly from VM memory snapshots and virtual disks. The operator panel offers memory snapshot analysis, disk image analysis, combined memory and disk processing, and recursive scanning of every VM on a datastore.
What VMkatz can recover
From memory snapshots, the public tool recovers material across all nine security support providers that mimikatz implements. That includes NT and LM hashes, WDigest plaintext where present, Kerberos keys and tickets exportable as .kirbi, TsPkg, DPAPI master keys, and Credential Manager entries. From offline disks it parses SAM hashes, LSA secrets such as service account passwords, cached domain logon hashes (DCC2), and the Active Directory database NTDS.dit through a native ESE parser.
It reads VMware .vmsn and .vmem snapshots and both sparse and flat VMDKs, and it can parse VMFS-5 and VMFS-6 raw devices directly on ESXi, which bypasses the file locks that protect running VMs’ disks. It also extracts BitLocker full-volume encryption keys from memory images and uses them to decrypt disks transparently, so guest-level disk encryption does not necessarily protect a running or snapshotted VM.
An operator can snapshot a running domain controller, parse the memory and disk files from the datastore, and leave with domain credential material while the EDR agent inside that domain controller sees nothing malicious, because nothing malicious ran inside it. Insikt Group assesses that GhostFrame’s integration lets an operator obtain credentials from hosted Windows systems without first deploying conventional credential-stealing malware in each VM.
Unit 42’s October update on CVE-2026-0257 exploitation describes an investigated case with the same shape. Attackers moved from a compromised VPN gateway to the vCenter appliance, disabled execInstalledOnly on ESXi hosts, and used a custom tool to dump credentials offline directly from a domain controller’s VMDK. GhostFrame packages that same workflow.
TAG-218 and Settra ransomware: from VPN appliance to hypervisor
Insikt Group found GhostFrame by watching TAG-218’s operator infrastructure. Using Recorded Future Network Intelligence, the team observed a cluster of victim-facing servers targeting VPN appliances across the US and Europe between late August and October 2026, predominantly SonicWall, Palo Alto Networks, and Fortinet devices. Four of the targeted organizations later appeared on the Settra ransomware leak site.
Those servers connect to TAG-218’s backend tooling: two GhostFrame C2 servers and a MeshCentral remote monitoring and management server that Huntress had previously attributed to Settra intrusions. On October 12, 2026, a victim Fortinet VPN appliance was observed beaconing to both GhostFrame and MeshCentral infrastructure in the same period. That places GhostFrame inside the TAG-218 intrusion chain and not merely next to it.
What Huntress found in Settra incidents
Huntress anchors the infrastructure overlap in incident data. Settra first surfaced in June 2026, and Huntress investigated two incidents, one in July at a consumer services and retail organization and one in September at a manufacturer. Both featured MeshAgent, the MeshCentral agent, installed for persistence. Both also had ransomware executables named after the victim’s domain with a _win64.exe suffix, RESTORE_FILES.txt ransom notes, and encrypted files carrying .locked or .locked_wip extensions.
The MeshAgent C2 in the September incident was 193.5.65[.]114, the same address Insikt Group lists as TAG-218’s MeshCentral server. Huntress also linked that IP to a recurring attacker workstation name, WIN-LIVFRVQFMKO, seen in incidents going back to December 2024 and associated with the address since November 2025. That suggests the operators’ infrastructure predates Settra’s public debut.
The Windows-side behavior shows a crew comfortable with hands-on-keyboard tradecraft and destructive cleanup. Huntress documented BYOVD activity using gdrv.sys in the September case, clearing of Windows event logs (a misspelled Defender log name left that one intact), reagentc /disable to kill the recovery environment, diskpart scripts assessed to remove recovery partitions, and cipher /w to overwrite free space and frustrate file recovery. GhostFrame extends that pattern downward. The crew stops fighting EDR inside each Windows guest and takes the layer underneath, where the guests’ defenses do not reach.
CVE-2026-0257: the GlobalProtect connection
Insikt Group places the campaign alongside reporting on CVE-2026-0257, an authentication bypass in the GlobalProtect portal and gateway of Palo Alto Networks PAN-OS that lets an attacker establish a VPN session without valid credentials or MFA. Palo Alto disclosed the flaw on May 13, 2026 with a CVSS 4.0 score of 7.8 and rated it highest urgency. It is classified as CWE-565, reliance on cookies without validation and integrity checking. Exploitation requires GlobalProtect authentication override cookies to be enabled together with a specific certificate configuration. The fix regenerates those cookies using a more secure method, with strict HMAC validation enforced after upgrade. Recommended mitigations are to use a dedicated certificate exclusively for authentication override cookies or to disable the override feature outright.
Unit 42 observed active exploitation from early June, noted the CVE’s addition to CISA’s Known Exploited Vulnerabilities catalog on May 13, and tracked a public proof-of-concept release at the end of May.
Unit 42’s October 19 threat brief update is where the two research threads meet. It names ransomware operators exploiting the flaw, including Spikey Scorpius (Qilin) and Tarnished Scorpius (Inc), and notes public reporting that attributes exploitation to actors deploying Settra. It describes the post-exploitation progression as RMM-based reconnaissance, lateral movement over RDP and SMB, and staged credential harvesting ahead of encryption. The biggest tactical shift it flags is a direct pivot to the virtualization layer, in some cases chained with exploitation of Veeam backup infrastructure via CVE-2023-27532.
Insikt Group is careful about the linkage. Palo Alto’s description of attackers disabling ESXi security controls and harvesting credentials with a custom tool is consistent with GhostFrame’s capabilities, but the reporting does not establish that the two tools are the same code. The pattern itself is documented across multiple ransomware operations: perimeter VPN compromise, identity bypass, a jump to vCenter or ESXi, and offline theft from virtual disks.
How to detect GhostFrame on ESXi hosts
On the host, hunt for the persistence artifacts and the defense impairment together. Insikt Group’s indicators are modifications to /etc/rc.local.d/local.sh, the presence of /opt/vmhostd-core or a vmhostd process impersonating vmware-hostd, and attempts to disable the firewall or set execInstalledOnly to 0. The repeated five-second reversion is a tripwire in its own right. If a setting an administrator restored keeps flipping back, treat it as an active compromise and not a configuration bug.
Forward host logs to a remote syslog collector so shell activity, configuration changes, and authentication events survive even if the host is later wiped. Baseline the boot script and the installed VIB inventory so deviations stand out.
On the network, alert on near-simultaneous TCP SYNs from a hypervisor to one external address across ports 53, 2222, 3389, 4444, 8443, and 9443. That pattern stays useful even as C2 IPs rotate.
ESXi hardening and incident response
GhostFrame needs root before it can do anything, so the management plane comes first. Insikt Group recommends restricting administrative access to trusted systems and investigating unexpected privileged access or configuration changes. In practice that means management interfaces reachable only from dedicated administrative networks or jump hosts, SSH and the ESXi shell disabled when not in active use, and the hypervisor and vCenter held to the same tier-zero standard as domain controllers.
Hardware-backed controls raise the cost of the exact technique GhostFrame relies on. With UEFI Secure Boot and TPM 2.0 enforcing execInstalledOnly, the setting resists the runtime toggling the implant performs, because enforcement is re-applied at boot and no longer rests on a software flag. Egress filtering deserves equal weight, since a hypervisor has little legitimate reason to initiate arbitrary outbound connections.
Plan the response around exposed credentials. If a host running GhostFrame is confirmed, treat the guests on it as credential compromised even with clean EDR verdicts, because VMkatz-style extraction leaves no in-guest execution to detect. If a domain controller’s memory or NTDS.dit was reachable, that means domain-wide credential rotation.
Cleanup order matters. Remove the boot script persistence and the implant binary before restoring the firewall and execInstalledOnly, or the loop undoes the repair. Where integrity is in doubt, I would rebuild the host from trusted media and restore configuration deliberately instead of trusting a system whose trust anchor was owned.
GhostFrame indicators of compromise (IOCs)
Recorded Future published four indicators with the research.
Indicator Type Context 193[.]5[.]65[.]114 IP address TAG-218 MeshCentral C2, previously observed by Huntress in a Settra incident 45[.]158[.]196[.]81 IP address GhostFrame C2 server 45[.]158[.]196[.]141 IP address GhostFrame C2 server a05eae6d07b82e2e5451a72266f21fbaf76486ef4920a820988de93e15353a10 SHA-256 Recovered GhostFrame ELF sample
The framework uses a builder and the operators have a history of infrastructure reuse, so weight the behavioral detections above these specific addresses and hashes.
What GhostFrame means for ESXi security
Insikt Group assesses it as highly likely that additional financially motivated actors will adopt GhostFrame or comparable ESXi-focused tooling. Current evidence neither establishes the framework as exclusive to Settra nor identifies its distribution model. Any ransomware affiliate or initial access broker who can obtain a framework that converts one rooted hypervisor into credentials, consoles, and network reach across a virtual estate has a reason to want it.
Consolidation moved the most valuable systems onto a layer that most security programs monitor far less than the Windows servers above it, and GhostFrame shows attackers now build dedicated, maintained tooling for that gap. Treat the hypervisor as a tier-zero asset.
