Threat Hunt Plan: VMware vCenter and ESX — Management Plane Reconnaissance, Authentication Bypass and Guest-to-Host Escape

Date: 2026-08-11 | Revision 1.1

Hunt Objective and Scope

This hunt seeks evidence that an external or internal actor has fingerprinted, accessed, or exploited VMware vCenter Server and VMware ESX hosts using the vulnerabilities disclosed in Broadcom advisory VMSA-2026-0006 on 29 July 2026. The three vulnerabilities in scope are CVE-2026-59309 (CVSS v3.1 9.8, authentication bypass in the VMware Directory Service), CVE-2026-59310 (CVSS v3.1 9.8, directory traversal to arbitrary code execution in the vCenter Syslog server), and CVE-2026-47876 (CVSS v3.1 9.3, out-of-bounds write in the VMXNET3 virtual network adapter permitting guest-to-host code execution).

The hunt is motivated by confirmed pre-exploitation reconnaissance. Within days of disclosure, internet-facing honeypot infrastructure recorded a rise in unauthenticated requests to the vCenter web services endpoint at /sdk/ invoking the RetrieveServiceContent method, together with probing of the /websso single sign-on paths tied to the VMware Directory Service component named in CVE-2026-59309. No public proof-of-concept code and no confirmed in-the-wild exploitation had been reported at the time of writing, so the primary objective is to determine whether the estate has been enumerated and whether any deployment was compromised in the interval before patching.

Environment in scope: all vCenter Server appliances (8.0 prior to U3k, 9.0.x prior to 9.0.2.0100, 9.1.x prior to 9.1.0.0300), all ESX hosts (8.0, 9.0.x, 9.1.x), VMware Cloud Foundation 5.x/9.0.x/9.1.x, VMware vSphere Foundation 9.0.x/9.1.x, VMware Telco Cloud Infrastructure 3.0 and Telco Cloud Platform 3.0/4.x/5.0.x/5.1.x. Also in scope: the Windows and Linux administrative workstations and jump hosts that manage those platforms, the network segments carrying vCenter management traffic (TCP 443, 902, 5480, 9443), and any virtualized OT workload — human-machine interfaces, historians, engineering workstations, SCADA clients and jump hosts — resident on the affected clusters.

The organization's external attack surface is explicitly in scope for this run. Because the actor's reconnaissance is being conducted from the internet against internet-reachable instances, the hunt includes a passive external attack-surface hypothesis (Hypothesis 5) that determines what the internet can see of the estate's vCenter and ESX footprint. That hypothesis is executed first, because its output defines the target population that Hypothesis 1 then hunts internally.

Time window: 15 July 2026 through the present. The window opens two weeks before the 29 July disclosure so that pre-disclosure reconnaissance and any baseline of legitimate management traffic are both captured. For process-attribution queries that depend on ProcessRollup2 records from long-running daemons, extend the window to 90 days or one year, because a service started months ago may have no ProcessRollup2 event inside a short window.

Out of scope: exploitation of guest operating systems by means unrelated to the hypervisor, and vulnerability remediation itself. Remediation tracking is handled by the patch program; this hunt establishes whether compromise preceded it.

Hypotheses and Hunt Procedures

Hypothesis 1: An external or internal actor has performed unauthenticated fingerprinting of internet-reachable or internally reachable vCenter instances, observable as anomalous requests to the /sdk/ and /websso/ URL paths and as connections to vCenter management ports from sources outside the approved administrative range, in reverse-proxy logs, vCenter appliance logs, network flow records and endpoint network telemetry.

MITRE ATT&CK: Reconnaissance | T1595.002 — Active Scanning: Vulnerability Scanning | An actor enumerates vCenter build numbers via unauthenticated RetrieveServiceContent calls to identify unpatched instances before exploit code is available.

MITRE ATT&CK: Reconnaissance | T1592.002 — Gather Victim Host Information: Software | The RetrieveServiceContent response returns product line, version and build, giving an exact patch-level determination without any intrusive action.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — enumerate every process on every managed endpoint that opened a connection to a vCenter management port, joined in the reverse direction so the ProcessRollup2 side streams and the connection side stays well under the 100k subquery row cap. Substitute the 10.20.30.0/24 example subnet with your own vCenter management CIDR before running.

CrowdStrike Falcon LogScale (CQL) — surface command-line tooling used to probe vCenter web paths directly from a managed endpoint.

CrowdStrike Falcon LogScale (CQL) — if vCenter and reverse-proxy syslog is onboarded to NG-SIEM through a data connector, hunt the URL paths directly. Data-connector events use ECS-normalised field names, and the #type literal is parser-specific: confirm both with a fieldset() probe or a head(1) sample before relying on a zero result.

BPF packet capture — rolling capture of all traffic to the vCenter management interfaces, sized so a full hunt window survives on disk. The -G value requires a strftime format in the -w filename or each rotation overwrites the previous file.

Datadog Log Search — reverse-proxy and load-balancer logs fronting vCenter, matching the two reconnaissance URL paths.

Datadog Log Search — Windows endpoint fallback where the reverse proxy is not forwarding, matching administrative tooling invocations against vCenter.

Datadog Log Search — cloud API events where vCenter or its management network sits behind a cloud load balancer.

Datadog Live Process Monitoring — Infrastructure > Processes, not a log search source; requires the Agent with process_config.process_collection.enabled set to true.

Data source gaps to declare explicitly: where VPC flow logs are not forwarded to Datadog, the external-source determination above cannot be made from cloud telemetry and must come from the reverse-proxy log search or the perimeter firewall export; where Live Process Monitoring is not enabled, use the source:windows and source:kubernetes log searches as the fallback; where vCenter appliance syslog is not forwarded at all, the /sdk and /websso evidence exists only in the appliance-local /var/log/vmware/rhttpproxy/rhttpproxy.log and must be collected by hand before log rotation destroys it.

Windows Event IDs to collect on administrative workstations and jump hosts:

• 4624 — successful logon; identify interactive and remote sessions on hosts that manage vCenter
• 4625 — failed logon; brute-force or credential-stuffing precursors
• 4648 — logon using explicit credentials; frequently the artifact of a tool authenticating to vCenter with a stored credential
• 4688 — process creation with command line; captures PowerCLI, curl, govc and python invocations
• 5156 — Windows Filtering Platform permitted connection; source of outbound connections to vCenter ports where EDR is absent
• 4104 — PowerShell script block logging; captures the body of VMware module scripts even when obfuscated

OT Data Collection: Claroty xDome — in Devices > All Devices > Advanced Filters set Manufacturer = "VMware, Inc." to enumerate every hypervisor and virtualized asset the sensors observe, then export the table. In Network > Communication > Communication Analysis, leave Side A empty, set the Communication bucket to Port IN (443, 902, 5480, 9443), set Side B to Manufacturer = "VMware, Inc.", and set Time Frame to Past Month; this returns every observed flow into the management plane regardless of source. Export is capped at 100,000 rows, so batch by site if the estate is large.

OT Data Collection: Claroty CTD — CTD is a different platform from xDome with continuous full-PCAP retention rather than event-slice capture. Where CTD is the deployment, pull the same flow set from the on-prem console and retrieve packet data for any flagged conversation through the CTD-only per-event PCAP surface; this makes retrospective payload inspection of the reconnaissance window possible in a way xDome cannot support.

OT Data Collection: Dragos Platform — in Assets, scope to server-class and virtualization assets to define the hunt population. In the Communications Hub, filter source-zone = Level 4 or Level 3.5 and destination-zone = Level 3 or Level 2 with protocol filters for HTTPS and the vCenter management ports over the past 30 days, then pivot each session to its asset record and its event-based PCAP. Export a time-bounded PCAP window at the Sensor for the reconnaissance interval and pull it from SiteStore for offline analysis.

OT Data Collection: Nozomi Guardian and Vantage — N2QL queries against the links table, joined back to nodes so the output carries labels rather than bare IP addresses.

OT Data Collection: Armis Centrix — ASQ against the device inventory and the connection surface. Set the time window in the UI time-picker rather than in the query body, and add your tenant's boundary literal to the endpoint predicates when scoping to a specific zone.

OT Data Collection: Tenable One OT Exposure — the GraphQL endpoint at /graphql is the only programmatic interface; there are no REST /api/v1/ query paths for OT Exposure. Scope by the AssetType enum values VirtualServer, VirtualWorkstation, Server and OtServer to enumerate virtualized OT assets, and work the CVE matches for the three advisory CVEs in Risks > Findings, filtering by Plugin Name and affected asset. Use pyTenable for repeatable sweeps. Note that origins is deprecated in favour of networkAreas in v4.7.44.

OT Data Collection: Forescout eyeInspect — use the Command Center Asset Inventory view filtered by vendor and Purdue level to enumerate virtualization assets, and the Alerts view filtered by MITRE ATT&CK for ICS technique and time window. eyeInspect exposes no analyst query language, so forward asset and alert data over syslog/CEF or the REST API into the SIEM and hunt there; the Forescout OT Network Security Monitoring App for Splunk maps the data to CIM automatically.

SNMP polling of the switch ports facing the vCenter and ESX management interfaces, to detect traffic spikes and error bursts coincident with scanning:

Repeat the ifInOctets and ifOutOctets polls at 60-second intervals through the hunt window and diff successive values; the 32-bit counters wrap on high-speed links, so use the 64-bit ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6) and ifHCOutOctets (.10) for volumetric baselining. Treat any v1 or v2c community-string access to OT assets as a finding in its own right, since those transit essentially in cleartext. Collect trap-receiver logs for the window and flag coldStart (1.3.6.1.6.3.1.1.5.1), warmStart (1.3.6.1.6.3.1.1.5.2), linkDown/linkUp (1.3.6.1.6.3.1.1.5.3 and .4) and authenticationFailure (1.3.6.1.6.3.1.1.5.5) traps from the management segment.

YARA file-system scan for reconnaissance and exploitation tooling staged on administrative hosts:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — rarity analysis over sources reaching the management plane; sorting ascending surfaces the one-off connections that a busy management workstation buries.

CrowdStrike Falcon LogScale (CQL) — DNS resolution of vCenter and ESX names, a lightweight discovery signal that precedes direct connection.

Wireshark display filters — isolate the reconnaissance request shapes in the captured traffic.

Datadog Log Analytics — rank reconnaissance sources and detect the burst shape that distinguishes scanning from administration.

Datadog Audit Trail — confirm that no Datadog-side access-management change masked the collection during the window.

Datadog Monitor definition:

Windows Event Log PowerShell analysis:

OT network and protocol analysis: correlate the SNMP interface-counter diffs against the Communication Analysis and Communications Hub flow exports on a common timeline. A traffic spike on the vCenter-facing switch port that has no matching flow record in the OT monitoring platform indicates a SPAN or sensor coverage gap rather than an absence of activity, and that gap must be recorded as a limitation rather than reported as a clean negative.

YARA memory scan for scanning tooling resident in memory on administrative hosts. Classic YARA 4.5 takes the PID as a positional argument; there is no -p flag for process scanning, and YARA-X yr scan cannot scan process memory at all.

CrowdStrike Custom IOAs can express the process-and-command-line half of this hypothesis as standing detection content, and Falcon Real Time Response can execute the YARA scans above on remote hosts through put and run, avoiding a per-host analyst visit.

Hypothesis 2: An actor has exploited CVE-2026-59309 to bypass authentication in the VMware Directory Service and obtain unauthorized access to vCenter, observable as vCenter sessions and administrative actions with no corresponding authentication record, as unexpected principals or privilege grants in the Single Sign-On identity store, and as downstream credential and inventory access from the management plane.

MITRE ATT&CK: Initial Access | T1190 — Exploit Public-Facing Application | The authentication bypass is reachable by an unauthenticated actor with network access to vCenter, with low attack complexity and no user interaction.

MITRE ATT&CK: Defense Evasion, Persistence, Privilege Escalation | T1078.004 — Valid Accounts: Cloud Accounts | Post-bypass, the actor operates as a legitimate vCenter principal and may create or elevate SSO accounts to hold access across the patch.

MITRE ATT&CK: Credential Access | T1003 — OS Credential Dumping | Administrative control of vCenter and its managed guests enables credential extraction from guest memory and from the identity store itself.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — administrative tooling against vCenter from managed endpoints, which establishes the sanctioned-activity baseline that unmatched vCenter-side sessions are judged against.

CrowdStrike Falcon LogScale (CQL) — remote interactive logons to management hosts from public source addresses. A zero result here is a meaningful negative, not a query defect.

vCenter appliance log collection — these paths hold the authoritative record and rotate, so collect them before they age out. Retrieve over SSH or through a support bundle.

BPF packet capture — capture the full session content of management-plane traffic for the window so an unmatched session can be reconstructed.

Datadog Log Search — vCenter appliance syslog forwarded to Datadog, matching session establishment and directory service activity.

Datadog Log Search — Kubernetes-hosted workloads that authenticate to vCenter, where the estate runs a container platform on the same clusters.

Datadog Live Process Monitoring:

Data source gaps to declare explicitly: vCenter appliance syslog is frequently not forwarded, in which case the vmdird and websso logs exist only on the appliance and the source:vmware search above returns nothing for reasons of collection rather than of absence; where DNS query logging is unavailable, the resolution-precedes-connection signal cannot be recovered and the network leg must carry the hypothesis alone.

Windows Event IDs to collect:

• 4624 and 4625 — logon success and failure on hosts holding vCenter administrative credentials
• 4648 — explicit-credential logon, the artifact of a stored vCenter credential being used
• 4672 — special privileges assigned, indicating elevated session establishment
• 4720, 4728, 4732 — account created and added to privileged groups, where SSO is federated to Active Directory
• 4104 — PowerShell script block logging, capturing VMware module use

OT Data Collection: Claroty xDome — in Alerts & Threats > Alerts > All Alerts, filter the Alert Category chips to Threat Alert and Segmentation Alert and review any alert whose affected devices include a hypervisor or a virtualized OT asset. In Communication Analysis, set Side A to Purdue Level = 4 and Side B to Manufacturer = "VMware, Inc." with Time Frame Past Month to surface cross-level access into the management plane.

OT Data Collection: Claroty CTD — for any unmatched vCenter session identified in the appliance logs, pull the retained full PCAP for that exact five-tuple and window from the on-prem console and reconstruct the session offline; this is the capability that distinguishes CTD from xDome for retrospective work.

OT Data Collection: Dragos Platform — triage Notifications filtered to ATT&CK for ICS Initial Access (T0866, T0822) and Lateral Movement (T0859, T0867) across the Level 3 and Level 3.5 boundary and escalate any carrying an Activity Group tag. Query the Server Stats QFD for peers whose producer-consumer ratio trends toward −0.99, the signature of a server acting as an exfiltration source. Open a Case on any confirmed finding and attach the event PCAP and the SSH-sessions QFD.

OT Data Collection: Nozomi Guardian and Vantage — bound every exploratory query, because head without an argument silently returns ten rows and that is a presentation default, not a result set.

OT Data Collection: Armis Centrix — the failed-then-successful authentication shape has no native window-correlation operator in ASQ, so surface the alert and correlate against a parallel connection export in Excel by source-IP and affected-device tuple.

OT Data Collection: Tenable One OT Exposure — pull PLC mode changes, project uploads and code revisions for the window through the GraphQL API and cross-reference each against the change-management ticket queue; any engineering activity on a virtualized-EWS-driven controller without a ticket is a hunt finding regardless of whether the vCenter leg is confirmed.

OT Data Collection: Forescout eyeInspect — review the Alerts view for cross-zone and external-communication alerts involving virtualization assets, and forward the same data via CEF into the SIEM for correlation against the vCenter appliance logs, which eyeInspect itself cannot join.

YARA file-system scan for credential-access and post-exploitation tooling on management hosts and guests:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — data-staging and export behaviour issued through the vSphere API, the practical shape of inventory theft from a compromised management plane.

Wireshark display filters — isolate LDAP and SSO traffic to the directory service for session reconstruction.

Datadog Log Analytics — establish whether any vCenter session in the window lacks a preceding authentication record, which is the defining artifact of an authentication bypass.

Datadog Audit Trail — account and access changes across the observability estate during the same window, which frequently mirror identity changes made on the compromised platform.

Datadog CloudTrail — cloud-side credential use that follows a management-plane compromise.

Datadog Monitor definition:

Windows Event Log PowerShell analysis:

OT network and protocol analysis: for any virtualized HMI, historian or engineering workstation on an affected cluster, baseline its peer set and protocol mix over the 30 days preceding 15 July and compare against the hunt window. A virtualized OT asset that acquires a new peer or a new protocol during the window — RDP appearing inside a segment that previously carried only Modbus or DNP3, for example — should be treated as a lateral-movement candidate and correlated against the vCenter session timeline, because the hypervisor compromise path reaches the guest without traversing any guest-visible network boundary.

YARA memory scan targeting credential-dumping tooling on management hosts and on guests that hold vCenter credentials:

Hypothesis 3: An actor has exploited CVE-2026-59310, the directory traversal in the vCenter Syslog server, to write outside the intended log directory and achieve arbitrary code execution on the vCenter appliance, observable as unexpected file writes under the appliance web roots and service directories, as child processes spawned by syslog and proxy service parents, and as outbound connections originating from the appliance itself.

MITRE ATT&CK: Initial Access | T1190 — Exploit Public-Facing Application | The syslog collector accepts data from managed hosts and network devices by design, so the traversal is reachable wherever vCenter performs log aggregation.

MITRE ATT&CK: Persistence | T1505.003 — Server Software Component: Web Shell | A traversal write into a vCenter web root yields a persistent, authentication-free re-entry path that survives the session that created it.

MITRE ATT&CK: Command and Control | T1071.001 — Application Layer Protocol: Web Protocols | Post-exploitation callbacks from the appliance blend into the HTTPS traffic the management plane already generates.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — where a Falcon Linux sensor is deployed on the appliance or on adjacent Linux hosts, catch a service parent spawning an interpreter or network client, the canonical post-traversal execution shape.

Appliance-side file and process collection over SSH, to be run before any patch or reboot destroys the evidence:

BPF packet capture — capture syslog ingress to the appliance and any egress from it, since the traversal is delivered on the syslog channel and the payload calls back on another.

Datadog Log Search — syslog records containing traversal sequences, in encoded and unencoded form.

Datadog Log Search — Kubernetes and Windows fallback where the appliance forwards nothing and the only visibility is on the hosts sending it syslog.

Datadog Live Process Monitoring:

Data source gaps to declare explicitly: the vCenter appliance is a closed appliance and does not host a third-party EDR agent in most deployments, so the process-parentage query above will return nothing for the appliance itself even under successful exploitation; the appliance-side find, ps and ss collection is therefore the primary evidence for this hypothesis and cannot be substituted by endpoint telemetry. Where syslog to the appliance is UDP-only and no capture was running, there is no retrospective record of the delivery payload at all — state that limitation in the report rather than reporting a clean negative.

Windows Event IDs to collect on the hosts and network devices that forward syslog to vCenter:

• 4688 — process creation, identifying any host that generated crafted syslog traffic
• 5156 — Windows Filtering Platform permitted connection to the appliance syslog ports
• 7045 — new service installed, where the actor pivoted from the appliance back to a Windows host
• 4104 — PowerShell script block logging

OT Data Collection: Claroty xDome — in Communication Analysis, leave Side A empty, set the Communication bucket to Port IN (514, 1514, 6514) and Side B to Manufacturer = "VMware, Inc." over Past Month, to enumerate every device forwarding syslog into the appliance; any sender not on the sanctioned forwarder list is a delivery-vector candidate.

OT Data Collection: Claroty CTD — retrieve retained PCAP for the syslog conduit across the full window and search the payloads offline for traversal sequences; because CTD retains continuous capture rather than event slices, this is the one platform position from which the delivery payload can be recovered after the fact.

OT Data Collection: Dragos Platform — query the Industrial Protocols QFD and the DNS and file-transfer QFDs for anomalous activity sourced from the management segment, and export a time-bounded PCAP window at the Sensor covering the syslog conduit for offline analysis.

OT Data Collection: Nozomi Guardian and Vantage — remember that the right-hand side of a where clause is a string constant by default; a field-to-field comparison needs the dollar-sign prefix or the query silently matches nothing.

OT Data Collection: Armis Centrix — Armis forwards metadata only and has no packet capture of any kind, so payload inspection for traversal sequences must be sourced from a SPAN or TAP feed outside Armis or from a capture-capable platform such as Claroty CTD or Dragos.

OT Data Collection: Tenable One OT Exposure — enumerate every asset forwarding syslog through the GraphQL API, scoping on the AssetType values IndustrialGateway, IndustrialSwitch, Server and OtServer, and treat any forwarder absent from the sanctioned inventory as a delivery-vector candidate.

OT Data Collection: Forescout eyeInspect — use the Command Center structured filters to enumerate syslog flows toward the management segment and forward the result via CEF to the SIEM; eyeInspect's predefined active queries can confirm the identity of an unexpected forwarder without free-text hunting.

YARA file-system scan of the appliance web roots and service directories, run against a mounted copy of the appliance disk or over an RTR-style session:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — new script and executable writes on Linux hosts adjacent to the appliance, using the file-write family regex because there is no generic FileWritten event.

Wireshark display filters — recover traversal sequences and callback traffic from the captures.

Datadog Log Analytics — rank syslog senders and isolate the ones whose message content deviates from the RFC-shaped norm.

Datadog Audit Trail — integration and API-key changes that would accompany an actor establishing a persistent collection channel.

Datadog Monitor definition:

Windows Event Log PowerShell analysis:

OT network and protocol analysis: reconcile the list of devices observed forwarding syslog to the appliance against the sanctioned forwarder inventory held in the configuration management database. Any forwarder present on the wire but absent from the inventory is a finding regardless of payload content, because the traversal is delivered over exactly that channel and an unsanctioned forwarder is both the likeliest delivery point and an independent configuration failure.

YARA memory scan of the appliance service processes, where a live-response channel to the appliance exists:

Hypothesis 4: An actor with administrative privileges inside a guest virtual machine has exploited CVE-2026-47876 in the VMXNET3 virtual network adapter to execute code on the underlying ESX host, observable as guest-side driver and exploitation artifacts, as host-side shell and service activity outside change windows, and as hypervisor-level actions such as snapshotting, cloning or datastore manipulation with no corresponding change record.

MITRE ATT&CK: Privilege Escalation | T1611 — Escape to Host | The out-of-bounds write in the VMXNET3 adapter allows a guest administrator to execute code on the hypervisor, breaking the isolation boundary that segmentation designs depend on.

MITRE ATT&CK: Collection | T1005 — Data from Local System | Host-level access permits cloning or snapshotting guests to extract data without touching guest operating system logging.

MITRE ATT&CK: Impact | T1486 — Data Encrypted for Impact | Hypervisor-level encryption of datastores is a standard element of ransomware playbooks precisely because a single action at the ESX layer takes down every guest at once.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — rarity analysis over the VMXNET3 driver image across the guest fleet. Sorting ascending surfaces the host whose driver hash differs from every other guest, which is the tampering signal.

CrowdStrike Falcon LogScale (CQL) — VMware guest tooling spawned by an interpreter rather than by the service control manager, a masquerading and abuse pattern that precedes escape attempts. The regex event-name form catches SyntheticProcessRollup2 so processes already running at sensor start still resolve.

ESX host-side collection over SSH, where the ESXi shell is enabled for the investigation and then disabled again afterwards:

BPF packet capture — capture ESX management and vMotion traffic, since post-escape activity frequently appears as unexpected host-originated egress.

Datadog Log Search — ESX host syslog forwarded to Datadog, matching shell and privileged-session activity.

Datadog Log Search — Windows guest fallback for driver and crash artifacts where host syslog is unavailable.

Datadog Live Process Monitoring:

Data source gaps to declare explicitly: ESX hosts do not run a third-party EDR agent, so all host-side evidence for this hypothesis comes from host syslog and from live esxcli and vim-cmd collection; where ESX syslog is not forwarded to a central collector, host logs are held on local scratch storage that may not persist across a reboot, and a host that has been rebooted since the window opened may have no recoverable evidence at all. Where guest crash dumps are disabled, the out-of-bounds write may leave no guest-side artifact.

Windows Event IDs to collect inside guest virtual machines:

• 1001 — Windows Error Reporting bugcheck, the guest-side artifact of an out-of-bounds write that failed before achieving control
• 41 — Kernel-Power unexpected shutdown, correlating with exploitation attempts that crashed the guest
• 7045 — new service installed, indicating post-escape persistence pivoted back into a guest
• 4672 — special privileges assigned, establishing which accounts held the guest administrative rights the exploit requires
• 4688 — process creation with command line

OT Data Collection: Claroty xDome — enumerate every virtualized OT asset by setting Advanced Filters to Device Type IN ("Industrial Workstation", "SCADA Client", "SCADA Server", "OPC Server", "Server") and OS Category = "Windows", export the result, and reconcile it against the vCenter inventory to identify which OT workloads share a cluster with untrusted or externally reachable guests. That reconciliation defines the blast radius of a successful escape.

OT Data Collection: Claroty CTD — where a guest escape is suspected on a cluster hosting OT workloads, pull retained PCAP for the affected guests across the window and analyse for new peers and new protocols; continuous retention means the pre-escape baseline and the post-escape deviation are both recoverable from the same source.

OT Data Collection: Dragos Platform — in Assets, scope to virtualized OT assets and check the Now bucket of the vulnerability view, using the Dragos-corrected severity rather than the NVD score. Run a Sensor active query against any silent Level 2 asset suspected of hosting a covert channel before dispositioning it, and note that this requires customer coordination.

OT Data Collection: Nozomi Guardian and Vantage — Arc host telemetry is the relevant layer for guests that cannot run an IT EDR, and it captures process execution, USB events and local network connections on vendor-locked HMI and engineering-workstation images.

OT Data Collection: Armis Centrix — enumerate virtualized assets and their observed traffic; recall that ASQ has no window-correlation operator, so the temporal join between a guest crash and a subsequent host-level action is done by exporting both result sets and merging them in Excel on the device identifier with a delta-time column.

OT Data Collection: Tenable One OT Exposure — scope on the AssetType values VirtualWorkstation, VirtualServer, Hmi, Eng and OtWorkstation, which the platform models as distinct from the generic Workstation value; an engineering-workstation hunt scoped to Workstation misses exactly the hosts that matter. Exclude TenableIcp, TenableEm and TenableSensor before reporting any asset count.

OT Data Collection: Forescout eyeInspect — use the Asset Inventory view filtered by Purdue level and vendor to identify virtualized OT assets and their communication graphs, and pivot from any alert to the underlying flow or packet capture where sensor PCAP is enabled.

YARA file-system scan of guest and host file systems for escape tooling and staged payloads:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — guest crash and reboot clustering. Multiple guests on the same cluster crashing inside a narrow window is the signature of an exploit being iterated against an unreliable primitive.

Wireshark display filters — isolate host-originated egress and management-plane anomalies after a suspected escape.

Datadog Log Analytics — correlate guest crashes against host-side shell activity on the same cluster and in the same interval.

Datadog Audit Trail — monitor and alert modifications during the window, which an actor with platform access may make to blind the very detections built for this hunt.

Datadog CloudTrail — cloud-side snapshot and image operations, the cloud analogue of hypervisor-level data collection.

Datadog Monitor definition:

Windows Event Log PowerShell analysis:

OT network and protocol analysis: where virtualized OT workloads share a cluster with the guests implicated in a suspected escape, analyse their protocol traffic for the OT-specific abuse patterns that follow hypervisor-level access. Apply EtherNet/IP and CIP filters for write-class service codes, Modbus filters for function codes 16, 22 and 23 and for function code 8 sub-function 1, DNP3 filters for Select, Operate and cold or warm restart, S7 filters for download-block and stop-CPU PDUs, and IEC 61850 GOOSE filters for confRev changes and sequence-number jumps. Correlate every hit against the historian and SCADA alarm record for the same timestamp, and against the engineering change ticket queue; a controller write, mode change or setpoint deviation with no corresponding ticket is a finding that escalates immediately regardless of whether the hypervisor leg is confirmed.

YARA memory scan of guest processes holding the VMXNET3 device handle and of any suspicious host-side process:

Hypothesis 5: An external actor can reach an internet-facing instance of VMware vCenter or VMware ESX belonging to the organization, observable as an exposed service in passive internet-scan indices. Execute this hypothesis FIRST. The internal collection legs in Hypotheses 1 through 4 show what the defender's own sensors see; this hypothesis shows what the internet sees, which is frequently the actor's actual entry point, and its output defines the priority target population for the internal hunt. Because Broadcom has published no workaround for either vCenter vulnerability, an exposed unpatched instance has no compensating control other than removal from exposure.

MITRE ATT&CK: Reconnaissance | T1595 — Active Scanning | Defender-side passive discovery of exactly what an actor would enumerate; the honeypot-observed /sdk and /websso probing is the offensive form of this same enumeration.

MITRE ATT&CK: Initial Access | T1133 — External Remote Services | An internet-reachable vCenter management interface is an external remote service, and with CVE-2026-59309 requiring no authentication it is a direct entry point.

MITRE ATT&CK: ICS | T0883 — Internet Accessible Device | Where the exposed hypervisor hosts virtualized OT workloads, internet reachability of the management plane is internet reachability of the control environment.

Collection Queries — passive external indices. These are STRICTLY passive: they query third-party scan indices that already hold the data. Do NOT run an active scan or probe against any target infrastructure as part of this hunt. Reference API credentials by environment variable name only (SHODAN_API_KEY, CENSYS_API_ID, CENSYS_API_SECRET, NETLAS_API_KEY) and never inline a key into a query, a script or this document.

Shodan search filters — run each first unscoped to understand the global exposure shape, then scoped to your own estate with net:, org: and asn:.

Censys Search query language — the second engine, used both for its own coverage and to corroborate Shodan hits.

Netlas — the third engine, used only to break a tie when Shodan and Censys disagree on whether a host is exposed or on what version it runs.

Favicon-hash pivoting is a high-yield technique for finding instances whose banners are stripped or whose service is behind a non-standard port, but the hash is deployment-specific and must not be guessed. Derive it from one of your own known instances first (fetch /favicon.ico from an instance you own and compute the MurmurHash3 value the index expects), then pivot on it. Do not copy a favicon hash from a third-party blog post into a query without verifying it against your own instance, because a wrong hash silently returns an unrelated population and reads as a clean negative.

Cross-reference every exposed service and version against the CISA Known Exploited Vulnerabilities catalog and against the three CVEs in this advisory. A KEV match on an exposed instance is a presumptive ransomware and actor-associated initial-access risk and escalates immediately.

Analysis Queries:

Attribution — confirm every hit actually belongs to the organization before reporting it. Check the PTR record, the autonomous system, the TLS certificate common name and subject alternative names, and the WHOIS registrant for the address block. Shared hosting and cloud provider ranges will return hits that belong to other tenants, and a false attribution wastes remediation effort and can implicate an unrelated third party. Where the address is in a cloud provider range, confirm ownership through the organization's own cloud asset inventory rather than through the index alone.

Version triage — extract the vCenter or ESX build string from each confirmed-owned banner and compare it against the affected ranges: vCenter 8.0 prior to U3k, 9.0.x prior to 9.0.2.0100, 9.1.x prior to 9.1.0.0300, and ESX 8.0, 9.0.x and 9.1.x. Flag every in-range instance. Note that a banner reflects the state at the index's last scan, which may predate your patching; treat an in-range banner as a prompt to verify current state directly from your own inventory, not as proof the instance is unpatched today. Equally, treat a fixed-version banner as insufficient on its own if the index timestamp is older than your exposure window.

Corroboration — never report a single-engine hit. Confirm every exposure in at least two of Shodan, Censys and Netlas before escalation. The indices scan on different cadences and from different vantage points, and a host present in one and absent from another is usually a scan-timing artifact but is occasionally an index error. Record the index timestamp alongside each hit so the finding carries its own provenance.

Historical pivot — where the index supports it, review historical records for each confirmed-owned address to establish how long the instance has been exposed and whether the exposure predates 29 July 2026. An instance that was exposed and unpatched across the entire reconnaissance window should be treated as presumptively enumerated, and its internal hunt priority raised accordingly.

Pivot into the internal hypotheses — this is the point of the exercise. For every confirmed, owned, in-range exposed instance, feed its address and hostname into Hypotheses 1, 2 and 3 as a priority target: pull the full reverse-proxy and appliance log record for that instance across the window, run the /sdk and /websso queries against it specifically, enumerate its Single Sign-On account inventory, and examine its file system for traversal artifacts. An exposed unpatched instance is the likeliest initial-access vector in the estate, so the internal hunt for that instance is not a sampling exercise but an exhaustive one.

Blast-radius pivot — for every exposed instance confirmed to host virtualized OT workloads, escalate to the OT analysis in Hypothesis 4 immediately and document which HMIs, historians, engineering workstations and SCADA clients share its clusters. Internet reachability of a hypervisor hosting control-environment workloads is a finding in its own right under IEC 62443 zone and conduit modelling and under NERC CIP electronic security perimeter requirements, independent of whether exploitation is ever confirmed.

Because this advisory is generic and publishable, the queries above carry no organizational data: the reader substitutes their own domain, address ranges, ASN and organization name at run time, and every such value appears here as a placeholder.

Threat Actor Profile

Opportunistic mass-exploitation actors. Sophistication: low to moderate. Access path: internet-facing vCenter instances identified by unauthenticated fingerprinting, then exploited as soon as a working exploit circulates publicly or is purchased. TTPs: mass scanning of TCP 443 across hosting and enterprise address space, unauthenticated RetrieveServiceContent calls to determine build numbers, target-list construction ahead of exploit availability, then rapid opportunistic exploitation with minimal target discrimination. The observed reconnaissance against these CVEs matches this profile exactly, and the operational significance is that the target list is built now and used later. Detection leverage is highest at the fingerprinting stage, before an exploit exists, and exposure reduction (Hypothesis 5) removes the organization from the target list entirely rather than merely detecting its construction.

Ransomware operators. Sophistication: moderate to high, with well-developed hypervisor tradecraft. Access path: an internet-facing vCenter or a foothold on a management workstation, escalating to the management plane through CVE-2026-59309 or CVE-2026-59310. TTPs: hypervisor-level encryption has been a standard element of ransomware playbooks for several years precisely because a single action at the ESX layer takes down hundreds of guests at once and defeats guest-resident backup agents. Expect enumeration of datastores and guest inventory, deletion or encryption of snapshots and backups reachable with vCenter credentials, disabling of virtual security appliances, and encryption executed at the datastore layer rather than inside guests. For an OT asset owner the relevant consequence is that virtualized HMIs, historians and engineering workstations are taken down simultaneously regardless of the network zoning applied to the guests.

Nation-state and state-aligned intrusion sets. Sophistication: high. Access path: patient, credentialed access to management infrastructure, often via a compromised administrative workstation rather than direct exploitation of the appliance. TTPs: hypervisor-level persistence and collection, cloning or snapshotting guests to extract data without touching guest operating system logging, manipulation of virtual networking to defeat segmentation, and long dwell times. Groups with a documented history of targeting virtualization infrastructure treat vCenter as a collection platform rather than a disruption target. Because a snapshot-based collection leaves almost no guest-side artifact, this actor class is the strongest argument for treating the appliance-side logs as primary evidence and collecting them before patching destroys them.

Insider and third-party administrative misuse. Sophistication: variable, but with legitimate access that removes the need for exploitation. Access path: existing vCenter or ESX administrative credentials, or vendor and integrator remote access into the management network. TTPs: use of sanctioned tooling outside change windows, snapshot and clone operations for unauthorized data access, and configuration changes that weaken isolation. This actor class matters to the hunt because it produces much of the activity the queries above will surface, and distinguishing it from intrusion is what the change-record correlation in Section 7 is for.

Data Sources Required

Network: full packet capture or rolling PCAP at the management network boundary and at the vCenter and ESX management interfaces; NetFlow or IPFIX records covering the management segment; perimeter and internal firewall logs for TCP 443, 902, 5480, 9443, 514, 1514 and 6514; reverse proxy and load balancer access logs fronting vCenter, including full URL path and source address; DNS query and resolver logs.

External attack surface: passive internet-scan indices — Shodan, Censys and Netlas — queried read-only for the organization's own address ranges, ASN, organization name and certificate common names; the CISA Known Exploited Vulnerabilities catalog for cross-referencing exposed versions; the organization's authoritative public IP address inventory and cloud asset inventory, which are required to attribute index hits correctly and without which the exposure determination cannot be made. API credentials for these indices are referenced by environment variable name only.

Endpoint: CrowdStrike Falcon telemetry from Windows and Linux administrative workstations, jump hosts and guest virtual machines, specifically the ProcessRollup2, SyntheticProcessRollup2, NetworkConnectIP4, DnsRequest, DriverLoad, UserLogon, ServiceStarted, ScheduledTaskRegistered and file-write event families; Windows Security, System, PowerShell/Operational and TaskScheduler/Operational event logs; Sysmon where deployed, particularly event IDs 1, 3, 7, 11 and 22.

Virtualization platform: vCenter appliance logs at /var/log/vmware/vmdird/, /var/log/vmware/sso/, /var/log/vmware/vpxd/ and /var/log/vmware/rhttpproxy/; vCenter Single Sign-On account and group inventory via dir-cli; ESX host logs including hostd.log, shell.log, auth.log and vmkernel.log; ESX host configuration state via esxcli and vim-cmd; vCenter task and event history; snapshot, clone and datastore operation records.

OT and ICS: Claroty xDome or CTD device inventory, Communication Analysis flow exports and alerts; Dragos Platform assets, notifications, Communications Hub flows, Query Focused Datasets and event-based or window-exported PCAP; Nozomi Guardian and Vantage nodes, links, alerts and Arc host telemetry; Armis Centrix device inventory, ipConnections and alerts; Tenable One OT Exposure asset inventory, events and findings via the GraphQL API; Forescout eyeInspect asset inventory and alerts via CEF; process historian trends and SCADA alarm records for the hunt window; PLC and controller configuration-change and mode-change records.

Vendor and device: SNMP interface counters and trap-receiver logs from the switches carrying management traffic; syslog forwarder inventory from the configuration management database; change-management ticket records covering the hunt window, which are required to disposition almost every finding this plan produces.

Observability: Datadog log ingestion from nginx or the reverse proxy, source:vmware for appliance and host syslog, source:windows, source:kubernetes and source:cloudtrail; Datadog Audit Trail; Datadog Live Process Monitoring where the Agent is deployed with process collection enabled.

Detection Signatures

SIGMA rules

Snort and Suricata rules

YARA rules

The first rule targets the file-on-disk artifact expected from CVE-2026-59310 exploitation: a web shell or script dropped through the traversal into a vCenter appliance path. The condition requires both a vCenter-specific path or service string and at least one command-execution primitive, because either half alone matches ordinary appliance content — the appliance is full of legitimate Python and shell scripts, and the command primitives appear in vendor tooling. Requiring the intersection, and bounding the file size to 200 kilobytes, keeps the rule off the vendor's own large service binaries while still catching the small dropped payloads that traversal writes produce.

The second rule targets guest-to-host escape tooling for CVE-2026-47876 and is written for both disk and memory. It anchors on the VMXNET3 device path and driver name together with the ioctl and device-handle primitives an exploit needs to reach the adapter, and requires a spray or grooming indicator alongside them. The two-of-three structure exists because a legitimate VMware driver or diagnostic tool will match the device strings but not the exploitation primitives, while generic exploitation tooling will match the primitives but not the device strings — only something built for this adapter matches both.

The third rule is the standing credential-dumping rule required whenever a hunt involves credential access, which Hypothesis 2 does by way of the VMware Directory Service identity store. It covers mimikatz, Windows Credentials Editor, gsecdump and the comsvcs MiniDump technique, with a fifth catch-all branch matching any memory-read API paired with the LSASS process name and one tool indicator, so that renamed or lightly modified tooling still matches. Note that all of these techniques require SeDebugPrivilege, so a hit is meaningful only on a host where the executing account held it. This rule targets Windows LSASS tooling and will not match Linux credential dumping through the proc filesystem; on the vCenter and ESX appliances themselves, which are Linux-based, use the appliance-side file and process collection in Hypothesis 3 instead. CrowdStrike Real Time Response can execute this rule remotely without an analyst visiting each host.

Indicators of Compromise

Network indicators: unauthenticated HTTP POST requests to /sdk carrying RetrieveServiceContent in the body, from any source outside the sanctioned administrative range; requests to any /websso path from an external or non-administrative source; connections to TCP 443, 902, 5480 or 9443 on a vCenter or ESX management address from a host that is not on the administrative network; SYN bursts to the management ports with no completed session, the shape of a port sweep rather than an administrative connection; directory traversal sequences, raw or URL-encoded, inside syslog messages directed at the vCenter syslog server on UDP or TCP 514, 1514 or 6514; outbound connections originating from a vCenter appliance or ESX host to any public address, which is anomalous for both by design; DNS resolution of vCenter, vCSA or ESX hostnames from a host with no administrative role.

External exposure indicators: an organization-owned address appearing in Shodan, Censys or Netlas with a vCenter or ESX service banner on TCP 443, 902, 5480 or 9443; an exposed banner whose build string falls inside the affected ranges (vCenter 8.0 prior to U3k, 9.0.x prior to 9.0.2.0100, 9.1.x prior to 9.1.0.0300; ESX 8.0, 9.0.x, 9.1.x); an organization-owned TLS certificate common name presented by a host that does not appear in the authoritative public asset inventory, which indicates shadow infrastructure; an index record showing the instance was exposed continuously across the reconnaissance window that opened on 29 July 2026; a KEV catalog match against any exposed and confirmed-owned instance.

Host indicators: script or executable files with modification times inside the hunt window under /usr/lib/vmware-vsphere-ui/, /usr/lib/vmware/vsphere-ui/, /var/log/vmware/ or /etc/cron.d/ on the vCenter appliance; child processes of vmware-syslog, syslog-ng, rhttpproxy, vmdird, vmafdd or vmware-vpxd that are shells, interpreters or network clients; new or modified cron and systemd units on the appliance; unexpected principals, recently created service accounts, or unexplained privilege grants in the vCenter Single Sign-On and VMware Directory Service account inventory; changes to identity source configuration; vCenter sessions and administrative actions with no corresponding authentication record, which is the defining artifact of an authentication bypass rather than a credential compromise; a vmxnet3.sys driver hash present on one guest and no other; guest bugcheck or unexpected-shutdown events clustered within a narrow window across multiple guests on the same cluster; ESXi shell or SSH sessions on a production host outside a change window; snapshot, clone or datastore operations with no corresponding change ticket; PowerCLI, govc, esxcli or vim-cmd execution on a host outside the sanctioned administrative pool, and any of those spawned by a script interpreter or an Office process.

OT and operational indicators: a virtualized HMI, historian, engineering workstation or SCADA client acquiring a new peer or a new protocol during the hunt window; RDP, SSH or VNC appearing inside an OT segment that previously carried only industrial protocols; controller write-class service codes, Modbus function codes 16, 22 or 23, Modbus function code 8 sub-function 1, DNP3 Select, Operate or restart functions, S7 download-block or stop-CPU PDUs, or IEC 61850 GOOSE confRev changes and sequence-number jumps, sourced from a virtualized engineering workstation with no corresponding change ticket; PLC mode changes, project uploads or code revisions in the window that reconcile to no ticket; process-variable deviations at safety-critical points coincident with any of the above; SNMP coldStart or warmStart traps from management-segment devices outside a maintenance window; interface counter or error bursts on the vCenter-facing switch port with no matching flow record in the OT monitoring platform, which indicates a sensor coverage gap rather than an absence of activity.

False Positive Baseline

Third-party monitoring, backup and capacity-management platforms poll the vSphere API continuously and legitimately, and many of them do so through a NAT or proxy address that reads as external. These produce a high, steady volume of /sdk requests including RetrieveServiceContent. Enumerate every sanctioned vSphere API consumer with its source address and its polling interval before triaging any /sdk finding, and suppress on the source-address plus user-agent tuple rather than on the URL path, since suppressing the path blinds the detection entirely.

Virtualization administrators routinely run PowerCLI, govc and the vSphere client from workstations that are not formally on the administrative pool list, particularly in organizations where the pool list has drifted from practice. Reconcile the observed administrative source hosts against the current administrator roster and the privileged access management records before treating an unlisted host as a finding; the usual outcome is a documentation gap rather than an intrusion, but the reconciliation itself is a worthwhile control finding.

Vendor patch and update processes write shell scripts, temporary files and new cron entries into appliance service directories during maintenance windows, and vCenter support-bundle generation writes temporary scripts under /var/log/vmware/. Correlate every appliance file-write finding against the patch and maintenance calendar first. A file whose modification time falls inside a documented vendor update window, and whose ownership and permissions match the vendor's own files, is very likely legitimate; one written outside any window, or with anomalous ownership, is not.

Guest bugchecks and unexpected shutdowns have many mundane causes — memory pressure, storage latency, driver updates, and the guest operating system's own patch cycle. The signal in this hunt is not a crash but a cluster of crashes: multiple guests on the same cluster crashing inside a narrow window, particularly if they share a VMXNET3 adapter configuration. Isolated crashes on a single guest should be dispositioned against the guest's own event history and the storage performance record before being attributed to exploitation.

Vulnerability scanners operated by the organization or by an outsourced scanning provider generate exactly the reconnaissance pattern this hunt looks for, including /sdk enumeration, /websso probing and management-port sweeps. Obtain the scanning schedule and the scanner source addresses before the hunt begins and annotate the timeline with them. A scan that appears in the data but not in the schedule is a finding in its own right, whether or not it turns out to be authorized.

Passive-index hits attributed to the wrong owner are the dominant false positive in Hypothesis 5. Shared hosting, cloud provider address space, content delivery networks and reverse proxies all produce index records that carry an organization's certificate or hostname without the organization controlling the underlying host, and conversely a cloud-hosted instance may present a provider-owned PTR record that hides genuine ownership. Attribute every hit through at least two independent signals — PTR, ASN, certificate subject and subject alternative names, WHOIS registrant, and the organization's own cloud asset inventory — before reporting it. Equally, a banner reflects the state at the index's last scan and can be weeks stale, so an in-range version string is a prompt to verify current state directly, not proof of a live unpatched instance, and a patched-looking banner from a stale scan is not evidence of safety.

Engineering workstation reboots, scheduled maintenance and DHCP lease changes on Windows-based HMIs generate new-asset and state-change alerts across every OT monitoring platform in this plan, and vendor remote-support sessions appear as new flows that look like unauthorized remote access. Correlate OT-platform findings against the maintenance calendar and the vendor support ticket record before escalation, and note that on Nozomi deployments the first patch cycle after a baseline lock reliably floods with new-flow alerts.

Escalation Criteria

Escalate to incident response immediately when any of the following conditions is met.

1. Any YARA hit on VMware_vCenter_Traversal_Webshell_Artifacts against any file under /usr/lib/vmware-vsphere-ui/, /usr/lib/vmware/vsphere-ui/, /var/log/vmware/ or /etc/cron.d/ on a vCenter appliance, or against any file recovered from an appliance disk image.

2. Any YARA hit on VMware_VMXNET3_Guest_Escape_Tooling against any file or any process memory on a guest virtual machine or an ESX host.

3. Any YARA hit on Credential_Dump_Tool_Memory_Artifacts against the memory of lsass.exe, or against any process or file on a host that holds vCenter administrative credentials.

4. Any vCenter session or administrative action identified in the vpxd or vmdird logs for which no corresponding authentication record exists, which is the direct signature of CVE-2026-59309 exploitation rather than of credential theft.

5. Any principal, service account, group membership or identity source configuration change in the vCenter Single Sign-On or VMware Directory Service inventory that reconciles to no change ticket.

6. Any directory traversal sequence, raw or URL-encoded, confirmed inside a syslog message directed at the vCenter syslog server, whether or not a file write is also confirmed.

7. Any child process of vmware-syslog, syslog-ng, rhttpproxy, vmdird, vmafdd or vmware-vpxd that is a shell, an interpreter or a network client.

8. Any outbound connection from a vCenter appliance or an ESX host to a public address that does not reconcile to a documented vendor update or telemetry destination.

9. Any snapshot, clone, datastore, or virtual machine export operation recorded in the vCenter task history that reconciles to no change ticket, given that snapshot-based collection is the primary data-theft path from a compromised management plane.

10. Any ESXi shell or SSH session on a production host outside a documented change window.

11. Any cluster of guest bugcheck or unexpected-shutdown events across two or more guests on the same ESX host within a two-hour window where the guests share a VMXNET3 adapter configuration.

12. Any controller write, PLC mode change, project upload, code revision or process-variable deviation observed on a virtualized OT asset during the hunt window that reconciles to no engineering change ticket. This escalates on its own merits and does not wait for the hypervisor leg to be confirmed, and it requires immediate notification of plant operations as well as of incident response.

13. Any confirmation that an affected vCenter instance was reachable from the internet at any point during the hunt window, whether or not exploitation evidence is found, since exposure of an unpatched instance with no available workaround is itself an urgent risk finding.

14. Any organization-owned vCenter or ESX instance confirmed by at least two passive scan indices to be internet-exposed with a build string inside the affected version ranges. This escalates as an emergency exposure finding on discovery, before and independently of any internal evidence collection: with no vendor workaround available, the only immediate mitigations are removal from internet exposure and patching, and the internal hunt for that instance under Hypotheses 1 through 3 becomes exhaustive rather than sampled.

15. Any organization-owned exposed instance whose passive-index record shows continuous exposure spanning 29 July 2026, which should be treated as presumptively enumerated by the observed reconnaissance campaign.

16. Any exposed instance carrying an organization-owned certificate or hostname that does not appear in the authoritative public asset inventory, which is a shadow-infrastructure finding requiring ownership resolution regardless of its patch state.

17. Any exposed and confirmed-owned instance matching an entry in the CISA Known Exploited Vulnerabilities catalog, which constitutes presumptive ransomware and actor-associated initial-access risk.

Hunt Completion Criteria and Reporting

The hunt is complete when every hypothesis has been executed against every data source enumerated in Section 4 that is actually available in the environment, and when every data source that is not available has been explicitly recorded as a gap rather than silently omitted. Specifically: the passive external attack-surface sweep has been run across the organization's full public address inventory, ASN and certificate namespace in at least two independent indices, with every hit attributed, version-triaged and either confirmed as owned or excluded with a documented rationale; every vCenter appliance and ESX host in scope has had its version confirmed against the fixed-version list and its logs collected; the /sdk and /websso reconnaissance queries have been run across the full window on whichever of the reverse proxy, appliance syslog or endpoint telemetry legs exist, exhaustively for any instance the external sweep confirmed as exposed; the Single Sign-On account inventory has been enumerated and reconciled; the appliance file systems have been examined for writes inside the window; the guest fleet has been checked for VMXNET3 driver anomalies and crash clustering; and the virtualized OT asset inventory has been reconciled against the cluster topology so the blast radius is documented whether or not compromise is found.

A negative result is only reportable as a negative where the collection actually covered the question. Several of the queries in this plan will return nothing for reasons of instrumentation rather than of absence — the vCenter appliance runs no third-party EDR agent, ESX host logs may not survive a reboot if syslog forwarding is not configured, UDP syslog leaves no retrospective record without a running capture, and Armis has no packet capture at all. The external sweep has its own version of this limitation: passive indices scan on their own cadence from their own vantage points, so absence from an index is evidence of nothing more than that the index did not observe the host, and an exposure sweep bounded by an incomplete public IP inventory is bounded in exactly the places the organization does not know about. Every such case must be stated in the report as a limitation on coverage. A hunt that reports "no evidence found" without distinguishing "we looked and it was not there" from "we could not look" is worse than no hunt, because it manufactures confidence that the estate is clean.

The report must contain: the scope actually covered, including the specific vCenter and ESX instances examined and their version and patch status at the time of examination; the external exposure inventory with, for each confirmed-owned hit, the address, the observing indices and their scan timestamps, the banner version, the affected-range determination and the remediation status; the address ranges, ASNs and certificate namespaces the external sweep covered, and any part of the public estate it could not cover; the time window and any periods where telemetry was absent; each hypothesis with its verdict — confirmed, not confirmed, or not testable — and the evidence supporting that verdict; every finding with its supporting artifacts, its disposition against the change record and the maintenance calendar, and its escalation status; the reconciliation of observed administrative source hosts against the sanctioned pool, of observed syslog forwarders against the sanctioned forwarder inventory, and of externally observed hosts against the authoritative public asset inventory, all three of which are control findings in their own right; the blast-radius documentation showing which OT workloads share clusters with which other guests; the detection content deployed as a result of the hunt, including which SIGMA rules, Snort or Suricata rules, YARA rules, Datadog monitors, CrowdStrike Custom IOAs and NG-SIEM correlation rules were promoted to standing detections; and a coverage-gap list with a recommendation for each gap.

Any hypothesis that reached a not-testable verdict for want of instrumentation should carry a specific remediation recommendation — forward vCenter and ESX syslog to the central collector, enable Live Process Monitoring on the administrative hosts, extend PCAP retention across the management conduit, reconcile and maintain an authoritative public IP and certificate inventory so the external sweep is bounded by fact rather than by assumption — so the same hunt is answerable the next time it runs. The external sweep in particular should be established as a recurring control rather than a one-off hunt step, since new exposure is created continuously by ordinary infrastructure change.

Advisory IoC Reference