CVE-2024-37079 Google Chronicle · YARA-L

Detect VMware vCenter Server Out-of-bounds Write (CVE-2024-37079) in Google Chronicle

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

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule cve_2024_37079_vcenter_oob_write {
  meta:
    author = "df00tech"
    description = "Detects CVE-2024-37079 exploitation: VMware vCenter Server out-of-bounds write via memory corruption signals and anomalous management port activity"
    severity = "CRITICAL"
    priority = "HIGH"
    reference = "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/24453"
    cve = "CVE-2024-37079"
    mitre_attack = "T1190"

  events:
    (
      (
        $e1.metadata.event_type = "PROCESS_UNCAUGHT_EXCEPTION"
        and $e1.principal.hostname = /vcenter|vcs/
        and $e1.target.process.file.full_path = /vpxd|vmdir|vmdird|vmafdd/
      )
      or
      (
        $e1.metadata.event_type = "NETWORK_CONNECTION"
        and (
          $e1.target.port = 443
          or $e1.target.port = 902
          or $e1.target.port = 5480
          or $e1.target.port = 9443
        )
        and $e1.target.hostname = /vcenter|vcs/
        and not $e1.principal.ip in %authorized_management_cidrs
      )
      or
      (
        $e1.metadata.event_type = "GENERIC_EVENT"
        and $e1.principal.hostname = /vcenter|vcs/
        and $e1.metadata.description = /segfault|heap-buffer-overflow|SIGSEGV|core dump|DCERPC|out.of.bounds|CVE-2024-37079/
      )
    )

  condition:
    $e1
}
critical severity medium confidence

Chronicle YARA-L rule detecting CVE-2024-37079 exploitation through process crash events on vCenter hosts, anomalous inbound connections to vCenter management ports from unauthorized sources, and memory corruption log entries.

Data Sources

Chronicle UDM eventsEndpoint telemetryNetwork telemetry

Required Tables

Process eventsNetwork connection eventsGeneric/log events

False Positives & Tuning

  • vCenter processes restarted by VMware lifecycle manager during patching generating PROCESS_UNCAUGHT_EXCEPTION events
  • Authorized monitoring platforms connecting to vCenter management ports from IPs outside documented management CIDRs
  • Penetration testing engagements with authorized scope covering vCenter infrastructure
  • High-availability failover events triggering abnormal vCenter process termination signals

Other platforms for CVE-2024-37079

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) 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