Correlating vCenter reverse SSH with suspicious ESXi shell activity

Contribution

This post adds a cross-plane tripwire for the active vCenter campaign: correlate a vulnerable management appliance making a new outbound connection with reverse_ssh evidence, then raise the case again if ESXi shell telemetry shows command construction or changes to logging and virtual-machine state. The source reports do not join those layers. QUIRSO covers the exploited vCenter systems and reverse SSH persistence; CrowdStrike separately shows why literal command matching fails on ESXi. The added detection logic connects initial access, durable remote control and the first signs of hypervisor action without claiming that the observed campaign has already used ESXi obfuscation.

The pattern

Broadcom published VMSA-2026-0006 on 29 July 2026 and updated it to revision 0006.2 on 19 August. The advisory describes CVE-2026-59310 as a directory traversal flaw in the vCenter Syslog server. An attacker with network access to vCenter can use it to execute arbitrary code without authentication. Broadcom rates it 9.8 under CVSS v3.1, provides fixed releases for the supported vCenter branches and states that no workaround is available. The current response matrix lists 9.1.0.0300, 9.0.2.0100, 8.0 U3k and 8.0 U2f; vCenter 7.0 customers need an extended-support path through Broadcom.

The exposure condition deserves careful wording. This is not an internet-only bug. Publicly reachable vCenter systems are the easiest targets, but an attacker who already has network access to a management segment can reach the same service. Rapid7 made that distinction in its initial analysis: restricting vCenter to an internal or dedicated management network reduces exposure to internet scanning but does not remove the risk from an intruder already inside the organisation.

QUIRSO then supplied the incident evidence. Its responders found compromised vCenter systems connecting to attacker-controlled infrastructure from 3 August, five calendar days after Broadcom's disclosure. The researchers associated 361 victim IP addresses across 47 countries with the campaign. They also warned that an IP address is not the same thing as a unique victim organisation because hosting, cloud and shared infrastructure can place several systems behind one address.

The post-exploitation detail matters more than the count. QUIRSO observed the attacker deploy reverse_ssh, an open-source reverse-shell framework with connect-back access, port forwarding, file transfer and remote shell support. An outbound session is attractive on a management appliance because it can cross controls built to stop unsolicited inbound administration. A successful patch does not close an established reverse channel or remove a binary already placed on the appliance.

The available reporting stops there. QUIRSO has not published attacker-specific infrastructure or a full post-exploitation sequence, and it does not say that this actor moved from vCenter into ESXi. That boundary is useful rather than frustrating. It tells defenders which facts belong in a campaign detector and which belong in a forward hunt. The confirmed sequence is vulnerable vCenter, code execution, reverse_ssh, then outbound remote access. ESXi shell activity, virtual-machine changes, data access and encryption remain investigation branches until telemetry proves them.

QUIRSO's generic YARA rule can identify reverse_ssh client builds, but the researchers explicitly note that the tool has legitimate penetration-testing uses. A file match alone is therefore a lead. On a vulnerable vCenter appliance, a new match combined with an unfamiliar outbound destination is much stronger. Add an unapproved file write or process start and the case is no longer a generic dual-use-tool alert.

Why it matters to cloud defenders

vCenter is a private-cloud control plane. It manages ESXi hosts, virtual machines, resource allocation, configuration and access permissions. Compromise does not have to touch an AWS, Azure or GCP API to become a cloud detection problem. The same operating model applies: one management identity and one control surface sit above many workloads.

That concentration changes the response priority. A compromised application server may expose one service and the credentials present in its process. A compromised vCenter can place the attacker next to guest consoles, VM configuration, snapshots, datastores and host administration. It can also affect workloads that security teams mentally assign to separate business services. Treating the appliance as ordinary Linux leaves the valuable part of the evidence, the relationship between the appliance and its managed hosts, out of the incident graph.

The first blind spot is egress. Management appliances are often allowed to reach update services, identity providers, DNS, NTP, backup systems and administrators' networks. A new long-lived outbound session can hide among that permitted traffic, particularly if the detector looks only for destination port 22. Reverse SSH can use different transports and ports, so destination novelty, connection duration and the appliance's normal egress set are more useful than a single port test.

The second blind spot is the hand-off to ESXi. CrowdStrike's separate research found that ESX shell logs preserve commands before shell expansion. An attacker can construct esxcli through printf, awk, environment-variable slicing or encoded text. The command runs after expansion, while the log retains the obfuscated source. A search for the literal string esxcli can therefore miss the action that changed syslog configuration, enumerated virtual machines or prepared a VMFS file.

The third blind spot is impact evidence. CrowdStrike notes that ransomware operators target ESXi because host-level access can stop or encrypt many virtual machines and interfere with logging. There is no published evidence that the CVE-2026-59310 actor has done this. Defenders should still prepare the branch because the time to collect shell, task and datastore telemetry is before an intruder disables forwarding. The correct alert says 'vCenter persistence followed by suspicious host action', not 'this campaign is ransomware'.

ATT&CK mapping

The confirmed entry maps to T1190, Exploit Public-Facing Application, where vCenter is reachable from an untrusted network, and more broadly to exploitation of a network-accessible management service where exposure is internal. Broadcom's description supports arbitrary code execution through the vCenter Syslog server. T1190 captures the observable entry behaviour.

The execution layer maps to T1059, Command and Scripting Interpreter. Shell-based construction maps to T1059.004, Unix Shell, while a decoded esxcli action can map to T1059.012, Hypervisor CLI. CrowdStrike tested its patterns against ESX shell telemetry and showed commands assembled through substitutions, escape sequences and awk before being passed to a shell. T1059 is listed in the metadata; the sub-techniques stay in prose because the parent page is the maintained cross-link surface.

The confirmed persistence channel fits T1572, Protocol Tunnelling when reverse SSH carries control traffic through an outbound tunnel. Keep the evidential limit in view: QUIRSO observed reverse_ssh after compromise, but has withheld campaign infrastructure and later tradecraft. The technique belongs in the investigation, not as proof of every action available through the tunnel.

The impact branch can map to T1486, Data Encrypted for Impact, if host or VM evidence shows encryption. Collection from virtual disks or datastores needs its own evidence before it is labelled. No data payoff has been reported for this campaign, so this post does not assign one by assumption. Instead, the detector preserves the point at which the chain can fork: remote administration, guest access, data collection or destructive action.

Detection guidance

Build the detector as a scored case across three telemetry planes. Do not require every stage. Appliance coverage is uneven, and an attacker may remove local evidence. One high-confidence campaign artefact plus one independent control-plane signal should be enough to open an urgent investigation.

Stage one is the vCenter appliance. Start with an asset condition: the appliance is running an affected release from VMSA-2026-0006 or was exposed before it was patched. Join that to either a QUIRSO YARA match for reverse_ssh or a newly created executable that starts an outbound connection. Add weight when the destination has never appeared in the appliance's baseline, the connection persists beyond normal service calls, or the binary is absent from the approved software inventory.

A portable stage-one record can use these fields:

| Field | Test | | --- | --- | | asset.id | Known vCenter appliance | | asset.patch_state | Affected now, or affected during the incident window | | file.yara_rule | QUIRSO generic reverse_ssh match | | process.executable | New or unapproved executable on the appliance | | network.direction | Outbound | | destination.first_seen | First seen for this appliance | | network.duration | Outside the appliance's service baseline |

A YARA match without network or process context stays medium priority because administrators and red teams can use the same tool. A match on a vCenter appliance that was vulnerable, followed by a new outbound session, should be high priority. If YARA is unavailable, use the file's first-seen time, signer or package ownership, process ancestry and destination novelty as the independent checks.

Stage two watches the control plane and managed hosts. Forward vCenter administrative events and ESXi shell telemetry to storage the appliance cannot rewrite. Alert on shell activation, unexpected SSH sessions, new local accounts, changes to remote syslog settings, disabled forwarding, unusual virtual-machine power actions or snapshot and datastore operations. Compare the actor, source and maintenance ticket with the approved change window rather than treating every administrator action as hostile.

For ESXi shell commands, match construction primitives instead of a decoded command name. CrowdStrike's tested classes give defenders a practical vocabulary: printf inside command substitution; repeated octal or hexadecimal escapes; ANSI-C quoted escape strings; awk character generation with %c; bitwise operations in awk; and generated output piped into sh. A separate branch should catch several variable slices or substitutions chained together. These patterns have more investigative value when the same session also changes syslog, touches VMFS or invokes VM management actions.

Normal ESXi work still creates shell noise. Backup programs, certificate renewal, hardware tools and network diagnostics may use pipes or shell scripts. Tune by approved script path, expected account, host group and change window. Do not suppress an entire utility such as awk or printf; an attacker can combine a common utility with an uncommon execution shape. The risky unit is the syntax plus the host action that follows.

Stage three tests impact. Correlate the case with bursts of VM power changes, snapshot creation outside backup windows, new virtual disks or VM configuration files, datastore reads from an unusual administrator path, and logging changes. A sequence that starts with vCenter persistence and ends with host-wide VM operations is more important than either event alone. Preserve the original command text as bytes where possible because invisible Unicode can disappear during normalisation or rendering.

The case can be expressed without tying it to one SIEM:

1. Mark every vCenter appliance that was vulnerable during the relevant period.
2. Within that set, find new binaries or YARA matches followed by novel outbound sessions.
3. Within the next investigation window, collect vCenter administration and ESXi shell events for managed hosts.
4. Raise severity when command-construction syntax, syslog changes or unusual VM and datastore actions appear.
5. Suppress only when the executable, destination, account and change record all match an approved maintenance pattern.

This logic does not claim to detect the CVE request itself. No public source used here provides a stable exploit request pattern, and fabricating one would create false confidence. It detects successful post-exploitation while retaining the management relationship needed to see what happens next.

What to do now

1. Patch to the fixed vCenter release in the current Broadcom VMSA-2026-0006.2 response matrix. Broadcom lists no workaround. Check every vCenter instance, including lab, disaster-recovery and externally hosted management systems; route vCenter 7.0 through Broadcom extended support.

2. Treat pre-patch exposure as an incident question, not a completed maintenance task. Hunt for the QUIRSO reverse_ssh evidence, unapproved binaries and unfamiliar outbound sessions. Isolate a suspicious appliance before rotating credentials or rebuilding it.

3. Export vCenter and ESXi telemetry to a separate security account or logging system. Verify that remote forwarding still works and compare current settings with the approved baseline. Local logs on a compromised control plane are evidence, but they are not a trustworthy archive.

4. Search ESXi shell telemetry for construction primitives from CrowdStrike's tested research, then join matches to changes in syslog, VM power state and VMFS. Retain raw command bytes so zero-width characters survive collection.

5. Review the blast radius before declaring recovery. Check managed hosts, administrative accounts, snapshots, VM configuration changes and datastore activity. Rotate credentials that the vCenter appliance could access, restore logging first and rebuild from known-good media when compromise is confirmed.