The ESXi implant ships with a control panel; your hypervisor ships with no agent

On 10 November, Recorded Future's Insikt Group published its analysis of GhostFrame, a post-exploitation framework purpose-built for VMware ESXi hypervisors. The striking part is not that someone is attacking ESXi —that has been going on for years— but the shape of it: GhostFrame ships with a web operator panel with two sections, Sessions and Builder. The Builder generates the implant. The panel lists the guest virtual machines, changes their power state, manages their snapshots, and can switch on VNC to watch the guest desktop. It is, feature for feature, your virtualization console. The difference is that nobody asks theirs for a second factor.

Worth saying up front what GhostFrame is not: it is not a way in. It gets deployed once the attacker already has root on the host; the panel comes afterwards, with the instructions. And that is the heart of it: there is no agent to install on the layer where this runs. Your fleet's EDR lives inside the guest Windows and Linux machines. GhostFrame does not live there. It lives one floor down, where your machines are not machines: they are files.

What GhostFrame is and where it comes from

Insikt found it while tracking a group it calls TAG-218, whose activity overlaps with the Settra ransomware. The observed window runs from late August to October 2026, and four of the targeted organisations later appeared on Settra's extortion portal. The researchers add a caveat worth respecting: "available evidence does not establish that the framework is exclusive to Settra or identify its distribution model". Operational overlap, not exclusive ownership. Translated: it is not "ransomware crew X now has its own tool", it is that the tool circulates among people who share operations.

What is new, and what to hold on to, is the packaging: a framework nobody had documented —Insikt calls it "previously undocumented"— that puts the whole workflow into a single panel built for ESXi: persistence, credential theft and machine control.

The panel: what the person on the other side sees

The implant the Builder generates is called vmhostd-core and copies itself to /opt/vmhostd-core. At runtime it masks itself by changing its process name and command line to look like vmhostd. The name tells you who it is designed against: on ESXi the management daemon is called hostd. vmhostd does not exist. It is a name built to survive a quick glance at a process list at three in the morning, not a search.

If someone switches on the guest's graphical console from the hypervisor, inside that Windows there is no session to start: no remote desktop process, and watching generates no logon event at all. Only whatever someone then types into that console would. The framebuffer is served from outside the operating system: the guest takes no part in being watched and therefore never finds out.

Seventeen thousand times a day

To persist, the implant modifies /etc/rc.local.d/local.sh, the host's startup script. Once running, as the report describes, it executes a loop that roughly every five seconds disables the ESXi firewall and sets execInstalledOnly to zero. The arithmetic is ours, not the report's, which is why it is rounded: at five seconds that is on the order of 17,000 passes a day.

The report already explains what the loop is for: to switch the controls back off if an administrator tries to restore them. Put another way, the attacker does not trust their change to stick and has written the implant against an attentive administrator. And it wins, because it corrects every five seconds and you look once a quarter.

What the report does not say, and this is where we are going, is that the same loop is the loudest signal in the whole set and almost nobody collects it. Hypervisor configuration gets audited like a photograph. You look at it on audit day, it comes back "compliant", it gets signed and the report gets filed. A host that rewrites its own configuration seventeen thousand times a day is not an audit finding: it is a time series. And almost nobody is graphing it. Your host firewall's state should be a metric with an alert on it, not a screenshot in a PDF.

When your configuration backup saves the attacker's

There is a detail in the report the coverage mentions in passing and nobody follows to the end: so that its weakening survives a reboot, the implant executes /sbin/auto-backup.sh. That script is not theirs. It is the legitimate mechanism ESXi uses to persist the configuration changes it holds in memory.

The credentials do not come from the guest, they come from the disk

The framework integrates VMkatz, an open-source tool that extracts credentials from memory snapshots, from virtual disk images and from combining both, scanning datastores recursively. The haul the report describes: NTLM hashes, WDigest credentials, Kerberos tickets, SAM and LSA secrets, and NTDS.dit, the Active Directory database.

None of that happens inside the guest. There is no process reading lsass, no dump an agent can block, no suspicious-memory-access alert. There is a file, and someone with read permission on the store that holds it. We wrote about this a week ago in another case: when a domain controller's disk is read from outside, Windows logs absolutely nothing, because Windows never booted.

And there is one more piece, sdkmon, which alters service configurations to intercept usernames and passwords from future logins to ESXi itself. That has a very concrete operational consequence for the day after: rotating what you suspect was taken is not enough. You have to rotate everything used to log into the host during the incident window, because it was being recorded as it was typed.

The switch the loop turns off, and why turning it off is free

The control the loop switches off is the one Broadcom defines plainly: with execInstalledOnly enabled, it guarantees "that the VMkernel executes only those binaries that have been packaged and signed as part of a VIB". That is, the control that would have cost vmhostd-core one extra step.

We took the two execInstalledOnly options apart last week: there is an internal runtime option, added in ESXi 8.0 and enabled by default, switched off hot with esxcli system settings advanced set -o /User/execInstalledOnly -i 0; and a VMkernel boot option, still disabled by default. What matters today is which of the two the loop attacks. It attacks the weak one: the runtime option, the one almost everybody has, the one a single line removes without rebooting anything.

Since vSphere 7.0 Update 2 the boot option can be enforced on every boot using the TPM, and on ESXi 8.0 with UEFI Secure Boot and TPM 2.0 the host checks at boot that execInstalledOnly is still enabled and, if it is not, purple-screens on purpose. You turn it on with esxcli system settings encryption set --require-exec-installed-only=T, and the order matters: the documentation itself warns that "the execInstalledOnly enforcement is built on top of the UEFI secure boot enforcement", so secure boot comes first.

And it is not what you expect from a security control: this does not prevent the attack. It changes the ending. You go from a silent compromise that can last months to a loud crash at the next reboot. That is a trade, and it should be decided with open eyes, because a purple screen is an outage with a name on it and someone will ask why the host went down.

We often say it in other words: failure is inevitable, an outage is a design decision. This control is one of the few cases where you also get to choose which failure you would rather have.

And the honest counterweight, from the person who documented this control when there was barely any documentation. Anders Olsson wrote in 2022, explaining it in detail, that "if the attacker has root access to your ESXi hosts, there is not much we can do to stop them. All the protections that we put in place using root privileges can in some way be removed by anyone with root privileges". He added a detail that still holds: the Python interpreter VMware packages inside ESXi did arrive in a VIB, so an attacker with root can stay within what is allowed and keep operating. execInstalledOnly is not a barrier. It is a toll: it makes the attack more expensive and noisier. Which is a lot, but it is not the same thing.

This starts before the hypervisor

Between August and October 2026, TAG-218 came in through perimeter VPN appliances —the report names SonicWall, Fortinet and Palo Alto Networks— and among the routes is CVE-2026-0257, an authentication bypass in PAN-OS's GlobalProtect portal and gateway published by the vendor on 13 May 2026, which lets an unauthenticated attacker establish a VPN session by forging an authentication override cookie —exploitable when that feature is in use and the certificate signing those cookies is reused or exposed—. It is in CISA's KEV catalogue. Only then, with root already in hand, does the hypervisor appear.

And this often gets told badly: a VPN session established without authenticating does not "bypass MFA". It never reaches it. The second factor sits downstream of the point where the chain broke, which is why it never comes into play. Then comes the usual: dual-use remote management tooling —Insikt places a MeshCentral server in the chain, used for persistence—, lateral movement over RDP and SMB and staged credential harvesting before encryption, which is how Unit 42 describes it. It is the same shape we wrote about in late October: in through a portal login, out with the hypervisor. And just yesterday, on the three FortiOS criticals: what gets in, gets in where the appliance already trusted.

Six things you can actually watch on a host with no agent

There is no agent, but there is state and there is traffic. This is what we would put under continuous monitoring across an ESXi estate, in this order:

The report publishes concrete indicators for anyone who wants to look backwards: 193.5.65.114 as the MeshCentral command server and 45.158.196.81 and 45.158.196.141 for GhostFrame, plus the implant's SHA-256 digest. If you keep egress logs, that search costs an afternoon.

When not to, and what changing hypervisor does not fix

If your hosts have no TPM 2.0 and no secure boot, the whole TPM paragraph is not your move this quarter. Your move is to close off who reaches the management interface and put those four settings under continuous monitoring. That costs no money and is most of the benefit. And if your management interface only answers on a management network that a user VPN session cannot reach, a good part of this chain has nobody to talk to. Saying so takes work away from us, but it is the truth.

And what nobody who makes a living from this will probably tell you: migrating from VMware to Proxmox does not fix this problem. We are saying it, and we have migrated companies from VMware to Proxmox and have also recommended staying put when that made sense. A Proxmox node is a Debian box with root. The equivalent of everything above gets written in a systemd unit instead of in /etc/rc.local.d/local.sh, and reading a guest's disk needs no special tool: the system's own are enough. The real advantage of Proxmox here is that it is an ordinary Linux and does accept auditing, log shipping and the tools your team already knows. But that is work you have to do, not a gift that comes in the box with the hypervisor swap.

What has actually changed

Reading a guest machine's disk from the hypervisor is not a new technique, and anyone who has been around knows it. What is new is the packaging. When an entire attack chain fits in a panel with tabs, you no longer need the specialist who knew how to chain it by hand. That does not raise the ceiling of what can be done to your infrastructure: it raises the floor of who can do it. And the floor is exactly what ends up reaching you.

The virtualization layer has sat for years in an odd gap: too critical not to watch and too closed to install an agent on. In our managed EDR and MDR service that layer is in scope like any other, with the difference that what gets watched there is not processes: it is configuration state, changes to startup scripts and what the host is trying to talk to outside. And the perimeter where all of this started —the VPN appliances— is the same old cybersecurity job: knowing what version each one runs and when it was last patched.

Sources (verified): GhostFrame analysis, operator panel, vmhostd-core, gfsox, sdkmon, VMkatz, persistence, six-port pattern and indicators — Insikt Group, Recorded Future, 10 Nov 2026, recordedfuture.com; VNC, snapshot and process-masking details — securityonline.info; execInstalledOnly behaviour and commands, dependency on UEFI secure boot — vSphere 8.0 documentation, techdocs.broadcom.com; the runtime-versus-boot distinction, TPM-backed check and deliberate purple screen, and the quote on the control's limits — Anders Olsson, Truesec, 16 Dec 2022, truesec.com; CVE-2026-0257 (GlobalProtect authentication bypass, published 13 May 2026, the override-cookie precondition, in CISA\x27s KEV) and the subsequent post-exploitation chain (dual-use remote management tooling, RDP/SMB and credential harvesting before encryption) — Unit 42. The seventeen-thousand figure is our own arithmetic, deliberately rounded, on the approximate five-second interval the report describes; the consequence for the host configuration backup is flagged in the text as a deduction, not as a claim from the source.