They dumped the domain controller without entering Windows

On 19 October 2026, Unit 42 updated its report on the exploitation of CVE-2026-0257 with a paragraph that went largely unnoticed under the "ransomware comes in through the VPN" headlines. It says that, in one of the cases, the attackers pivoted from the compromised gateway to vCenter, disabled a protection on the ESXi hosts and used a custom tool to dump credentials against the domain controller's virtual disk. The agent watching that machine had nothing to report: nothing had to happen inside it.

We run other people's infrastructure for a living, so we read these reports hunting for the part that changes what we do on Monday. Here the part that changes isn't the firewall vulnerability — that gets patched — but the second half of the chain, where the attack leaves the operating system and moves into a layer where, quite simply, no agent is installed. And one uncomfortable thing is worth saying up front: what they disabled, they didn't break. They switched it off with a command the vendor documents on its own website.

The chain, in order

The front door is CVE-2026-0257, which the official advisory describes in the plural — "authentication bypass vulnerabilities in the GlobalProtect portal and gateway" of PAN-OS — and which lets the attacker "bypass security restrictions and establish an unauthorized VPN connection". Base score 7.8 on CVSS 4.0, high severity, suggested urgency the highest tier. The advisory was published on 13 May 2026 and last updated on 3 June. It doesn't affect every deployment: you need the authentication override cookies feature active with a specific certificate configuration, which is why the vendor's published workarounds are to use a dedicated certificate for those cookies or to turn the option off.

The calendar that follows is worth reading in one go, because it's the real headline. CISA added it to its Known Exploited Vulnerabilities catalogue on 29 May with a remediation deadline of 1 June: three days. Unit 42 observed active exploitation attempts from 5 June. Arctic Wolf investigated several distinct intrusions during June, all of which ended in Qilin ransomware. And the report we're discussing here is from October. Five months with a patch available, and the hole was still paying.

What they did inside in June, per Arctic Wolf, is textbook and it is loud: VPN sessions opened from machines self-identifying with the hostname kali, LSASS dumping via rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump, ntds.dit extraction with ntdsutil.exe using the IFM method, lateral movement with PsExec over administrative shares, exfiltration with Rclone to MEGA and the win.exe payload staged in C:\PerfLogs\. Every one of those lines is something an EDR agent can see and a log keeps. It's the script we already wrote up when DeadLock turns off the antivirus before encrypting: you have to fight whatever lives inside the machine.

The October case doesn't fight any of that. It walks around it. And one point of honesty is worth flagging: Arctic Wolf's July report does not mention the hypervisor pivot. That shows up in Unit 42's update, attributed to one case. It isn't an established pattern yet; it's a technique that already worked once against somebody real.

"They disabled the protection" is generous

The protection in question is called execInstalledOnly, and it does one thing: it makes the VMkernel execute only binaries packaged and signed as part of a valid VIB. It is, literally, the hypervisor's anti-ransomware checkbox. And the page explaining how to remove it is the vendor's own, titled "Deactivate the execInstalledOnly Internal Runtime Option", and it fits on one line:

The same page warns of both consequences: "When you deactivate the execInstalledOnly internal runtime option, vCenter Server warnings appear for the host" and "Deactivating the execInstalledOnly internal runtime option leaves you more vulnerable to attacks". Nobody broke any cryptography here. Somebody who already owned the host used the switch that ships with it. What failed was one layer earlier: that they got to own the host at all.

There are two execInstalledOnly options, and yours is the weak one

This is the part we haven't seen covered anywhere, and it's the one that decides whether the command above would have worked on your estate. There isn't one execInstalledOnly: there are two, same name, opposite properties. The vSphere 8.0 documentation separates them like this:

The vendor's exact sentence is this: "The execInstalledOnly boot option continues to be deactivated by default, except a previously enabled execInstalledOnly boot option overwrites the internal runtime option if you set both". And enabling the boot option carries a toll almost nobody has paid: "the secure boot enforcement must be activated before you can enforce the execInstalledOnly boot option in the sealing policy". Translated into consequences: if your host is a clean ESXi 8.x install, you have the first column. And the first column is worth exactly what that host's root password is worth, because it goes off hot and without rebooting anything.

Two commands to find out which column you're in. Neither changes anything:

And switched on, it still won't stop a script

There's a support article from the vendor itself, titled "execInstalledOnly Not Preventing Script Execution on ESXi", that puts it in writing: the feature "is designed to prevent the execution of unsigned binaries, but it does not prevent the execution of scripts run through interpreters like Python". And it finishes: "there is no built-in method in ESXi 7.0 to prevent the execution of unsigned scripts run through interpreters", a limitation the article extends up to and including the 8.x versions.

This doesn't make the control useless and we won't pretend it does: it raises the cost of the operation, forces the attacker to bring an interpreter or make do with what's there, and it leaves traces. But it sets the expectation correctly. It blocks the binary, not the tooling. An attacker holding the host with an interpreter available doesn't need to touch that switch at all — and if they did touch it, it was probably for convenience.

The warning you were already getting

So: the signal existed. It was written down, in plain English, and it names ransomware. The problem is what comes next, and it's in that same support article, which lists why a host can show up like this: because somebody disabled it by hand, because a firmware update utility disabled it, or because it was left off during the first initialisation after an upgrade to 8.x.

There's the knot. A host you upgraded in March and a host that was taken over an hour ago produce exactly the same line. An ambiguous signal nobody triages isn't a signal: it's noise formatted as an alert. And resolving that ambiguity isn't a product's job — there's nothing you can install that knows who switched off what; it's the job of somebody on shift who can answer two questions: when it went off, and who was connected at the time. That's a rota, not a licence.

The coverage map, layer by layer

This table is our reading of the chain, not a quotation. One column is what usually watches each layer; the other is what this attack left there:

The first row is what sells the rest of this article. A properly deployed EDR on the domain controller is a serious piece of kit and we're not saying it's surplus: it covers what happens inside that machine, which is nearly everything. What it doesn't cover — because it can't — is its disk being read from a layer below the operating system the agent lives in. It's the same reasoning we laid out with the encryptor that only touches 10 % of each VMDK: from the hypervisor, your virtual machines are files.

And no, this isn't a VMware problem. We say so because the commercial temptation would be exactly that, and it would be a lie: on Proxmox, a node's root reads that same domain controller's disk just as easily, whether it's a qcow2 or an RBD volume. The exposed surface isn't the product, it's the management plane. Change the badge and the argument doesn't move.

Six questions for this afternoon

All of them are answered with a yes, a no or a number. None of them needs you to buy anything:

Question 4 is the one we've most often seen left unanswered, and it's the only one an afternoon's work doesn't fix. The other five, it does.

At everyWAN we run managed EDR and MDR, and that's exactly why we say what they don't do: at the hypervisor layer there is no agent to install, so what covers it there is the rota, events shipped outside the cluster, and somebody who takes an ambiguous out-of-hours warning seriously. The other thing that genuinely helps is treating the management plane with Zero Trust criteria: its own network, accounts that don't depend on what they're protecting, and a root password rotated on a date.

Sources (verified on 2026-11-07): description, CVSS 7.8 (CVSS 4.0), affected versions, publication date (2026-05-13) and last update (2026-06-03), the authentication override cookies precondition and the workarounds — Palo Alto Networks advisory for CVE-2026-0257; the pivot from VPN gateway to vCenter, the execInstalledOnly deactivation and the offline credential dumping against the domain controller's VMDK, plus the exploitation timeline and the groups involved — Unit 42, "Active Exploitation of May 2026 PAN-OS CVE-2026-0257" (section "Update: Oct. 19, 2026"; the report’s last update, 2026-10-26); the June intrusions, the kali hostname, LSASS MiniDump, ntdsutil, PsExec, Rclone and win.exe in PerfLogs — Arctic Wolf Labs, "Cookie Crumbles"; KEV listing on 2026-05-29 with a 2026-06-01 due date — CISA Known Exploited Vulnerabilities Catalog; the deactivation command, the default state of both options and the vCenter warnings — Broadcom TechDocs, "Deactivate the execInstalledOnly Internal Runtime Option"; the secure-boot dependency for the kernel option — Broadcom TechDocs, "Securing the ESXi Configuration"; the interpreter limitation — KB 373898, "execInstalledOnly Not Preventing Script Execution on ESXi"; the exact warning text and its three causes — KB 401376; risks of integrating vSphere with Active Directory — Google Cloud Threat Intelligence (Mandiant). The two-options table, the coverage map and the six questions are our own work. Photograph: HP EVA4400 storage array, CC BY-SA 3.0 via Wikimedia Commons, cropped by us.