Detecting CVE-2026-59310 Exploitation: vCenter Path Traversal and reverse_ssh APT Persistence

CVE-2026-59310 is a CVSS 9.8 directory-traversal vulnerability in VMware vCenter’s Syslog server component, patched July 29 in VMSA-2026-0006. Five days later, QUIRSO GmbH observed confirmed exploitation activity — APT actors traversing directory boundaries within the Syslog component to achieve unauthenticated remote code execution, then establishing persistent access via a malicious cron job deploying reverse_ssh, an open-source SSH tunnelling tool. By August 13, 361 victim IP addresses across 47 countries had confirmed connections to attacker-controlled infrastructure.

This guide covers detection at three stages: initial exploitation (path traversal in vCenter logs), cron persistence installation, and the outbound reverse_ssh tunnelling that constitutes the C2 channel.

MITRE ATT&CK Mapping

Detection Surface 1: Path Traversal in vCenter Syslog Logs

The exploit traverses directory boundaries within the vCenter Syslog server’s request handling. vCenter’s vpxd-svcs.log and the underlying service access logs record incoming requests including path components. Path traversal sequences (../, %2e%2e%2f, %252e%252e%252f) in vCenter service logs are reliable indicators of active exploitation.

vCenter 8.x writes service logs to /var/log/vmware/vpxd-svcs/ on the vCenter Server Appliance (vCSA). Defenders forwarding vCSA syslog to a SIEM should see these as structured log events.

Sigma Rule — Path Traversal in vCenter Service Logs

title: VMware vCenter CVE-2026-59310 Path Traversal Exploitation Attempt
id: 7f3a1b9e-4c82-4d1a-b3f5-2e0a9c7d6841
status: experimental
description: Detects directory traversal patterns in VMware vCenter service logs
  consistent with exploitation of CVE-2026-59310 in the Syslog server component.
author: SOC Analyst Hub
date: 2026-08-14
tags:
  - attack.initial_access
  - attack.t1190
  - cve.2026-59310
logsource:
  product: vmware
  service: vcenter
detection:
  keywords:
    - '../'
    - '..\\'
    - '%2e%2e%2f'
    - '%252e%252e%252f'
    - '%c0%ae%c0%ae'
  filter_main:
    - 'vpxd-svcs'
    - 'syslog'
  condition: keywords and filter_main
falsepositives:
  - Legitimate vulnerability scans against vCenter
  - Penetration testing activity
level: high

KQL — vCenter Syslog Path Traversal (Sentinel / Log Analytics)

Assuming vCSA syslog is forwarded to the Syslog table in Log Analytics:

Syslog
| where TimeGenerated > ago(24h)
| where ProcessName has_any ("vpxd", "vmware-syslog", "vpxd-svcs")
| where SyslogMessage has_any ("../", "..\\", "%2e%2e%2f", "%252e%252e", "%c0%ae")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, HostName
| order by TimeGenerated desc

Detection Surface 2: Cron Job Persistence Installation

The documented attack chain deploys a malicious cron job on the vCSA after achieving RCE. The cron job configures reverse_ssh to call back to attacker infrastructure on a schedule or at boot. On vCSA (Photon OS-based), cron entries are written to /etc/cron.d/ or via crontab -e for the root user.

Detection requires auditd on the vCSA or file integrity monitoring. If you forward auditd logs, the key events are:

• SYSCALL records for write() or open() on cron paths
• EXECVE records showing cron daemon execution of unfamiliar binaries

Sigma Rule — Malicious Cron Creation on Linux vCenter Appliance

title: Suspicious Cron Job Created on VMware vCenter Appliance
id: 2d8e4a71-f9b3-41c6-a7d2-5b3c8e2f1094
status: experimental
description: Detects creation or modification of cron entries on a VMware vCenter
  Server Appliance host — a documented persistence mechanism in CVE-2026-59310 exploitation.
  Focus on entries written after the July 29 patch release.
author: SOC Analyst Hub
date: 2026-08-14
tags:
  - attack.persistence
  - attack.t1053.003
logsource:
  product: linux
  service: auditd
detection:
  selection_paths:
    type: PATH
    name|startswith:
      - '/etc/cron.d/'
      - '/var/spool/cron/'
      - '/etc/crontab'
  selection_write:
    type: SYSCALL
    syscall:
      - 'write'
      - 'openat'
    success: 'yes'
  filter_legitimate:
    comm:
      - 'crond'
      - 'anacron'
      - 'atd'
      - 'vmware-watchdog'
  condition: selection_paths and selection_write and not filter_legitimate
falsepositives:
  - Scheduled VMware infrastructure updates
  - Legitimate administrator cron job creation
level: high

KQL — Cron Modification Events (Linux Security Events via AMA)

Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("/etc/cron.d/", "/var/spool/cron/", "/etc/crontab")
| where SyslogMessage has_any ("OPENAT", "WRITE", "open(", "write(")
| where Computer has_any ("vcenter", "vcs", "vcsa")
| project TimeGenerated, Computer, SyslogMessage
| order by TimeGenerated desc

Detection Surface 3: Outbound reverse_ssh Tunnelling

reverse_ssh (GitHub: NHAS/reverse_ssh) establishes a persistent SSH tunnel from the compromised host to an attacker-controlled server. The tunnelling works by connecting outbound — bypassing inbound firewall rules — and creating a reverse SSH shell through the established tunnel. Network detection is more reliable than host-based detection here because the binary name and behaviour may vary.

Key network indicators:

• Persistent outbound SSH connections (port 22, 2222, or non-standard high ports) from the vCSA management IP
• SSH handshakes where the connecting host is the vCSA (not a human workstation)
• Connections to external IPs not in your organisation’s IP space
• Long-lived SSH sessions (hours) without corresponding legitimate admin sessions in ITSM

Sigma Rule — reverse_ssh Execution on Linux Host

title: reverse_ssh Binary Execution on VMware vCenter Appliance
id: 9c2e7f15-3b84-4a09-d8e1-6f4a0b3c2971
status: experimental
description: Detects execution of reverse_ssh — an open-source SSH tunnelling tool
  used by the APT actor in documented CVE-2026-59310 post-exploitation persistence.
author: SOC Analyst Hub
date: 2026-08-14
tags:
  - attack.command_and_control
  - attack.t1572
  - attack.t1071.002
logsource:
  product: linux
  service: auditd
detection:
  selection_exec:
    type: EXECVE
    a0|contains:
      - 'reverse_ssh'
      - 'rssh'
  selection_args:
    type: EXECVE
    a1|contains:
      - '-p'
      - '-R'
      - 'autossh'
  condition: selection_exec or selection_args
falsepositives:
  - Legitimate reverse SSH tunnelling tools used by administrators
  - Bastion host infrastructure (validate against known admin tooling inventory)
level: critical

KQL — Persistent Outbound SSH from vCenter IP Range

// Replace 10.0.0.0/24 with your vCenter management network range
let vCenterSubnet = "10.0.0.";
NetworkFlows
| where TimeGenerated > ago(7d)
| where SrcIP startswith vCenterSubnet
| where DestPort in (22, 2222, 2224, 443)
| where FlowDuration > 3600  // sessions lasting over 1 hour
| where DestCountry !in ("US", "GB")  // adjust to your org's expected geographies
| summarize 
    SessionCount = count(),
    TotalBytes = sum(FlowBytesSent + FlowBytesReceived),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
  by SrcIP, DestIP, DestPort, DestCountry
| where SessionCount > 3
| order by TotalBytes desc

Investigation Checklist

When a detection fires, prioritise the following:

Immediate (within 1 hour):

• Check vCSA patch level: rpm -qa | grep vmware-vcenter — confirm version is ≥ 9.1.0.0300 / 9.0.2.0100 / 8.0 U3k / 8.0 U2f
• Audit cron entries: crontab -l -u root and ls -la /etc/cron.d/
• Check for reverse_ssh binary: find / -name "reverse_ssh" -o -name "rssh" 2>/dev/null
• Review active network connections: ss -tnp | grep -E ':22|:2222'
• Check for new user accounts: getent passwd | awk -F: '$3 >= 1000'

Within 4 hours:

• Review /var/log/vmware/vpxd/ for path traversal sequences around the exploitation window
• Pull DHCP/DNS logs to map all IPs the vCSA has communicated with externally
• Check all managed VMs for lateral movement originating from vCSA management plane

Assume breach criteria: Any unpatched vCSA that has been internet-accessible or reachable from an untrusted network segment since July 29 should be treated as potentially compromised regardless of whether detections fired.

Baseline and Tuning Notes

The path traversal Sigma rule will generate false positives from vulnerability scanners and penetration testing. Suppress known scanner IPs in your SIEM rule configuration. The cron modification rule is high fidelity on vCSA specifically because legitimate writes to /etc/cron.d/ on the appliance are rare — focus investigation on any process other than crond, vmware-watchdog, or rpm writing to cron paths.

The network rule for persistent outbound SSH requires baselining. Log all long-lived outbound SSH sessions from vCenter IPs over the past 30 days before the CVE announcement to establish a legitimate baseline, then alert on new sessions not matching that baseline.