CVE-2024-37079 Sumo Logic CSE · Sumo

Detect VMware vCenter Server Out-of-bounds Write (CVE-2024-37079) in Sumo Logic CSE

Detects exploitation attempts targeting CVE-2024-37079, an out-of-bounds write vulnerability (CWE-787) in Broadcom VMware vCenter Server. This KEV-listed vulnerability allows unauthenticated remote attackers to trigger memory corruption via malformed DCERPC requests to the vCenter management interface, potentially leading to remote code execution with SYSTEM-level privileges on the vCenter appliance.

MITRE ATT&CK

Tactic
Initial Access Execution Lateral Movement

Sumo Detection Query

Sumo Logic CSE (Sumo)
sql 
_sourceCategory=*vmware* OR _sourceCategory=*vcenter*
| parse "*" as raw_message
| where raw_message matches /segfault|heap-buffer-overflow|SIGSEGV|SIGABRT|core dump(ed)?|stack smashing|out.of.bounds|DCERPC|RPC fault|malformed request|CVE-2024-37079/ OR
  (_sourceCategory matches /firewall|network|palo_alto|cisco_asa/ and (raw_message matches /:(443|902|5480|9443)/ and raw_message matches /vcenter|vcs/))
| extract "(?P<process>vpxd|vmdir|vmdird|vmafdd|vmcad)" from raw_message nodrop
| extract "(?P<src_ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})" from raw_message nodrop
| eval crash_indicator = if(raw_message matches /segfault|SIGSEGV|core dump|heap-buffer-overflow/, "true", "false")
| eval rpc_indicator = if(raw_message matches /DCERPC|RPC fault|malformed request/, "true", "false")
| timeslice 5m
| stats count as event_count, count_distinct(src_ip) as unique_sources, values(process) as affected_processes, sum(if(crash_indicator="true",1,0)) as crash_events, sum(if(rpc_indicator="true",1,0)) as rpc_events by _timeslice, _sourceHost
| where event_count > 0
| sort by _timeslice desc
critical severity medium confidence

Sumo Logic query aggregating vCenter memory corruption crash signals and anomalous DCERPC/RPC fault entries across 5-minute windows to detect CVE-2024-37079 exploitation patterns.

Data Sources

VMware vCenter logsSyslogNetwork/Firewall logs

Required Tables

_sourceCategory=*vmware*_sourceCategory=*vcenter*

False Positives & Tuning

  • Scheduled vCenter backup agents triggering process activity that resembles crash patterns
  • vCenter API version mismatches with older integrations generating malformed request log entries
  • Burst network activity from authorized vSphere client pools scanning management interfaces
  • Log forwarding delays causing time-windowed aggregation to overcount single events

Other platforms for CVE-2024-37079

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate vCenter DCERPC Malformed Request (Lab Only)

    Expected signal: Network flow log entry showing TCP connection attempt to target:135 with large payload; vCenter DCERPC service log entry showing parse error or malformed packet rejection

  2. Test 2Trigger vCenter vpxd Process Crash via Resource Exhaustion (Lab Only)

    Expected signal: Syslog entry on vCenter appliance: vpxd[PID]: segfault at [address]; core dump file created at /var/core/vpxd-[timestamp].core

  3. Test 3Probe vCenter Management Ports from Unauthorized IP (Lab Only)

    Expected signal: Firewall/network logs showing TCP SYN packets from scanner IP to vCenter management ports; vCenter access logs showing connection attempts to /ui, /sdk, VAMI endpoints

  4. Test 4Validate vCenter Log Forwarding and Crash Pattern Matching

    Expected signal: Syslog message appearing in SIEM ingestion pipeline with process name vpxd and severity daemon.crit containing the synthetic crash string

Last updated: 2026-06-19 Research depth: standard
References (2)

Response Playbook

Triage

  1. Confirm the targeted host is a VMware vCenter Server instance by validating hostname, management IP, and product version against your CMDB; cross-reference against known vCenter IPs to rule out false-positive log source misattribution.
  2. Review vCenter service logs at /var/log/vmware/vpxd/vpxd.log and /var/log/vmware/vmdird/vmdird.log for crash signals (SIGSEGV, SIGABRT, core dump), out-of-bounds write stack traces, and anomalous DCERPC parse errors within the detection window.
  3. Identify the external source IP triggering the event; check whether it belongs to known authorized management subnets, internal scanners, or backup agents — if external or unexpected, escalate immediately.
  4. Determine the current patch level of the vCenter instance; cross-reference with Broadcom security advisory SA-24453 to confirm whether the version is within the affected range and whether the patch has been applied.

Containment

  1. Immediately restrict inbound access to vCenter management ports (443, 902, 5480, 9443) at the network perimeter firewall to only authorized management IP ranges; enable emergency ACLs if targeted exploitation is confirmed.
  2. If active exploitation is confirmed via crash analysis or forensic indicators, isolate the vCenter appliance from the management network and spin up a secondary vCenter instance from a known-good snapshot while forensics are conducted.

Evidence Collection

  1. Collect and preserve full vCenter service logs (/var/log/vmware/vpxd/, /var/log/vmware/vmdird/, /var/log/vmware/vmafdd/) and any generated core dump files from /var/core/ for off-box forensic analysis.
  2. Capture a memory dump of the vCenter appliance VM via VMware snapshot or ESXi-level memory acquisition tools to support heap analysis and identify shellcode or injected payloads if remote code execution occurred.

Escalation Criteria

  • !Escalate to incident response if the vCenter process core dump analysis reveals shellcode, unexpected network listeners, or new administrative accounts created on the appliance after the crash event.
  • !Escalate to CISO and activate IR retainer if lateral movement from the vCenter host to connected ESXi hosts, VMs, or Active Directory is detected, as full hypervisor-level compromise may have occurred.

Investigation Guide

Related Techniques

[object Object][object Object][object Object]

Forensic Artifacts

  • >Core dump files in /var/core/ on the vCenter VCSA appliance generated at crash time, containing heap state at the moment of memory corruption
  • >vpxd.log and vmdird.log entries with SIGSEGV/SIGABRT/heap-buffer-overflow stack traces timestamped during the exploitation window
  • >Network flow logs showing the source IP, timing, and payload size of connections to TCP 5480 (VAMI) or TCP 443 (vSphere) immediately before the crash
  • >ESXi host audit logs (/var/log/hostd.log, /var/log/auth.log) for unauthorized VM console access or host configuration changes following vCenter compromise

Tuning Guidance

Reduce false positives by building a reference list of known vCenter appliance hostnames and management IPs and filtering events to only those hosts. Suppress crash-signal alerts during documented maintenance windows by adding a time-based exclusion tied to your change management calendar. For network-based detections, maintain an allowlist of authorized management station CIDRs and exclude their traffic from port-probe alerts. If vCenter is behind a WAF or API gateway, correlate with WAF block/allow logs to distinguish scan noise from targeted exploitation. Tune confidence upward to 'high' if a crash event and an external source IP probe to vCenter management ports occur within the same 5-minute window from the same source.

Hunting Queries

Retrospective 7-day hunt across vCenter daemon logs for memory corruption crash signatures that may indicate prior exploitation attempts or successful compromise before detection coverage was in place

Hunting — KQL
kql 
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName in ("vpxd", "vmdir", "vmdird", "vmafdd")
| where SyslogMessage has_any ("segfault", "core dump", "SIGSEGV", "SIGABRT", "heap-buffer-overflow", "stack smashing", "out of bounds")
| summarize event_count=count(), crash_types=make_set(SyslogMessage), first_seen=min(TimeGenerated), last_seen=max(TimeGenerated) by HostName, HostIP, ProcessName
| where event_count > 0
| order by last_seen desc
Hunting — SPL
spl 
index=* sourcetype="vmware:vcenter:log" earliest=-7d
("segfault" OR "SIGSEGV" OR "SIGABRT" OR "core dump" OR "heap-buffer-overflow" OR "out of bounds")
| rex field=_raw "(?P<process>vpxd|vmdir|vmdird|vmafdd|vmcad)"
| stats count as crashes, values(process) as processes, earliest(_time) as first_seen, latest(_time) as last_seen by host
| sort - crashes

Atomic Red Team Tests

Test 1 Simulate vCenter DCERPC Malformed Request (Lab Only)
linux

Sends a crafted oversized DCERPC request to the vCenter management interface to simulate the type of malformed input that triggers the CWE-787 out-of-bounds write. Used in isolated lab environments to validate detection coverage without exploiting a real vulnerability.

Command

bash 
python3 -c "
import socket, struct
target = '${VCENTER_IP}'
port = 135
payload = b'\x05\x00\x0b\x03' + b'\xff' * 4096
try:
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.settimeout(5)
    s.connect((target, port))
    s.send(payload)
    resp = s.recv(1024)
    print(f'Response: {resp[:64].hex()}')
    s.close()
except Exception as e:
    print(f'Connection result: {e}')
"

Cleanup

bash 
No cleanup required — connection attempt only, no persistent changes to target system

Expected Telemetry

Network flow log entry showing TCP connection attempt to target:135 with large payload; vCenter DCERPC service log entry showing parse error or malformed packet rejection

Expected Detection

QRadar AQL and Splunk queries should surface the DCERPC parse-error log entry; network detections should flag the management port probe from non-authorized source

Test 2 Trigger vCenter vpxd Process Crash via Resource Exhaustion (Lab Only)
linux

Simulates abnormal vpxd process termination on a lab vCenter appliance to validate that process-crash detection logic fires correctly and that core dumps are generated and captured.

Command

bash 
ssh -p 22 root@${VCENTER_LAB_IP} 'kill -SIGSEGV $(pgrep vpxd) && sleep 2 && ls -lh /var/core/'

Cleanup

bash 
ssh -p 22 root@${VCENTER_LAB_IP} 'service-control --start vpxd && rm -f /var/core/vpxd.core*'

Expected Telemetry

Syslog entry on vCenter appliance: vpxd[PID]: segfault at [address]; core dump file created at /var/core/vpxd-[timestamp].core

Expected Detection

Sentinel Syslog query and Splunk vmware:vcenter:log query should surface the segfault log entry within 60 seconds of the kill signal

Test 3 Probe vCenter Management Ports from Unauthorized IP (Lab Only)
linux

Performs a TCP port scan of vCenter management ports (443, 902, 5480, 9443) from a host outside the authorized management CIDR to simulate an attacker reconnaissance phase preceding CVE-2024-37079 exploitation.

Command

bash 
nmap -sT -p 443,902,5480,9443 --open -oN /tmp/vcenter_probe_$(date +%Y%m%d%H%M%S).txt ${VCENTER_LAB_IP}

Cleanup

bash 
rm -f /tmp/vcenter_probe_*.txt

Expected Telemetry

Firewall/network logs showing TCP SYN packets from scanner IP to vCenter management ports; vCenter access logs showing connection attempts to /ui, /sdk, VAMI endpoints

Expected Detection

Chronicle YARA-L rule and Sentinel KQL network detection should flag the management port probe from unauthorized source IP within the detection window

Test 4 Validate vCenter Log Forwarding and Crash Pattern Matching
linux

Injects a synthetic log entry matching the out-of-bounds write crash signature directly into the vCenter syslog stream to verify that log collection, forwarding, and SIEM detection rules are functioning end-to-end without requiring actual exploitation.

Command

bash 
ssh root@${VCENTER_LAB_IP} 'logger -t vpxd -p daemon.crit "SIGSEGV received — heap-buffer-overflow detected in DCERPC handler at 0x7f4a3b2c1d00; core dumped to /var/core/vpxd.core — potential CVE-2024-37079 exploitation"'

Cleanup

bash 
No cleanup required — synthetic log entry only; purge from SIEM after test by filtering on exact log string

Expected Telemetry

Syslog message appearing in SIEM ingestion pipeline with process name vpxd and severity daemon.crit containing the synthetic crash string

Expected Detection

All seven SIEM platform queries (KQL, SPL, EQL, AQL, Sumo Logic, Chronicle, CrowdStrike) should surface the injected log entry within their respective ingestion latency windows

Related Detections

Tactic Hubs

TA0001Initial AccessTA0002ExecutionTA0008Lateral Movement

Related Techniques

T1190Exploit Public-Facing ApplicationT1210Exploitation of Remote ServicesT1059Command and Scripting Interpreter

Same Tactic: Initial Access

Popular Detections