CVE-2025-31277 Elastic Security · Elastic

Detect Apple Multiple Products Buffer Overflow Exploitation (CVE-2025-31277) in Elastic Security

Detects potential exploitation of CVE-2025-31277, a buffer overflow vulnerability (CWE-119) affecting multiple Apple products. This vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog, indicating active exploitation in the wild. Successful exploitation may allow attackers to execute arbitrary code, escalate privileges, or cause denial of service on affected Apple devices and systems.

MITRE ATT&CK

Tactic
Execution Privilege Escalation Defense Evasion

Elastic Detection Query

Elastic Security (Elastic)
eql
sequence by host.id with maxspan=5m
  [process where host.os.type in ("macos", "ios") and
   process.name in ("mdmclient", "mobileassetd", "softwareupdated", "nsurlsessiond", "trustd", "accountsd", "apsd", "securityd") and
   event.action in ("process_stopped", "process_error", "crash")]
  [process where host.os.type in ("macos", "ios") and
   process.parent.name in ("mdmclient", "mobileassetd", "softwareupdated", "nsurlsessiond", "trustd", "accountsd", "apsd", "securityd") and
   process.name in ("sh", "bash", "zsh", "python3", "perl", "ruby", "osascript")]
high severity high confidence

EQL sequence rule detecting a two-stage exploitation pattern: an Apple system daemon crash followed within 5 minutes by a child shell or scripting process spawned from the same daemon, indicative of CVE-2025-31277 buffer overflow exploitation.

Data Sources

Elastic AgentmacOS Endpoint Security FrameworkAuditbeat

Required Tables

logs-endpoint.events.process-*auditbeat-*

False Positives & Tuning

  • Automated software update workflows that restart daemons and trigger post-update scripts
  • System integrity protection repairs that restart services and execute validation scripts
  • Enterprise MDM solutions that use daemon context to execute management scripts

Other platforms for CVE-2025-31277


Testing Methodology

Validate this detection against 3 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 Apple System Daemon Crash with Non-Zero Exit

    Expected signal: Process crash event for 'trustd' (or mock process) with SIGSEGV signal, non-zero exit code, and EXC_BAD_ACCESS exception type visible in /Library/Logs/DiagnosticReports/ and EDR crash telemetry

  2. Test 2Spawn Shell from Apple Daemon Context (Post-Exploitation Simulation)

    Expected signal: ProcessCreate event showing bash spawning /tmp/daemon_spawn_test.sh, with subsequent child processes for whoami, uname, id, and ls commands — EDR should record full process ancestry and command lines

  3. Test 3Generate Crash Report Artifact for Apple Daemon

    Expected signal: File creation event in ~/Library/Logs/DiagnosticReports/ for trustd crash file; log collection agents (Elastic Agent, CrowdStrike) should ingest the .crash file and surface EXC_BAD_ACCESS exception type in SIEM


Response Playbook

Triage

  1. Identify affected Apple device(s) by correlating crash telemetry with device inventory — confirm OS version and patch level against Apple security advisory HT213840 and linked support pages (124147, 124149, 124152, 124153, 124155).
  2. Determine exploitation scope: review process crash dumps and exception logs (/Library/Logs/DiagnosticReports/ on macOS) for patterns consistent with buffer overflow — look for EXC_BAD_ACCESS, SIGSEGV, or heap corruption indicators in the affected Apple system daemons.
  3. Check for post-exploitation activity: examine process ancestry for shells (sh, bash, zsh) or scripting runtimes (python3, osascript) spawned by Apple system daemons such as trustd, accountsd, or securityd, which would indicate successful code execution.
  4. Assess network behavior: review outbound connections initiated by Apple system daemons around the time of the crash event — anomalous C2 connections, DNS lookups to non-Apple infrastructure, or unexpected data transfers may indicate active compromise.

Containment

  1. Immediately isolate the affected Apple device from the network using MDM-enforced network restrictions or EDR isolation features (CrowdStrike 'contain host', Jamf remote lock) to prevent lateral movement or data exfiltration from a potentially compromised system.
  2. Apply Apple security patches immediately — update macOS, iOS, iPadOS, and other affected Apple products to the versions specified in Apple support pages 124147, 124149, 124152, 124153, and 124155. For managed devices, push updates via MDM.

Evidence Collection

  1. Collect macOS crash reports from /Library/Logs/DiagnosticReports/ and /var/folders/ for all affected Apple system processes — preserve .ips and .crash files with cryptographic hashes (SHA-256) before patching. On iOS, use sysdiagnose (Settings > Privacy & Security > Analytics > Share With App Developers) to capture device diagnostics.
  2. Export process execution logs from EDR platform (CrowdStrike Event Search, Jamf Protect alerts) covering 48 hours before and after the first detected crash — include full command lines, process ancestry trees, network connections, and file system modifications by affected processes.

Escalation Criteria

  • !Escalate to IR if post-exploitation indicators are confirmed — specifically: shell or scripting interpreter spawned as child of Apple system daemon, outbound network connections to non-Apple IP ranges from system daemons, new privileged user accounts created, or persistence mechanisms installed (LaunchAgents, LaunchDaemons, cron jobs) after the crash event.
  • !Escalate if more than three Apple devices in the environment show simultaneous crash patterns in the same Apple system daemon within a 24-hour window, indicating possible targeted campaign or worm-like propagation leveraging CVE-2025-31277.

Investigation Guide

Related Techniques

Forensic Artifacts

  • >macOS crash reports in /Library/Logs/DiagnosticReports/ (.ips and .crash files) for affected daemons — contain exception type, faulting instruction pointer, and memory maps useful for confirming buffer overflow exploitation
  • >Apple System Log (ASL) and Unified Logging entries: `log show --predicate 'subsystem == "com.apple.securityd" OR subsystem == "com.apple.trustd"' --last 24h` — look for memory corruption or unexpected termination messages
  • >LaunchDaemon and LaunchAgent plist files in /Library/LaunchDaemons/, /Library/LaunchAgents/, ~/Library/LaunchAgents/ — attacker may install persistence after gaining code execution via the buffer overflow
  • >Network connection history from /private/var/db/diagnostics/ and UTun/UTUN interface logs for unexpected outbound connections established by Apple system daemons post-exploit

Tuning Guidance

This detection targets exploitation of a buffer overflow in Apple system daemons. Tune by building an allowlist of known-good parent-child process relationships for your environment's MDM and endpoint management stack (e.g., Jamf Pro, Mosyle, Kandji) — these tools legitimately execute scripts in daemon contexts. Filter on specific MDM binary paths (/usr/local/jamf/, /usr/bin/profiles) as parent processes to reduce noise. For crash-based detections, filter out known Apple update bundle IDs (com.apple.SoftwareUpdate, com.apple.MobileAsset) during planned maintenance windows. Increase confidence threshold by requiring both crash event AND subsequent shell spawn on the same host within 5 minutes, rather than triggering on either independently.


Hunting Queries

Broad 7-day threat hunt across Apple endpoint telemetry to identify any historical instances of shells or network utilities spawned from Apple system daemons — surfaces both confirmed CVE-2025-31277 exploitation and previously undetected incidents from the same vulnerability class

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(7d)
| where OSPlatform has_any ("macOS", "iOS")
| where InitiatingProcessFileName in~ ("mdmclient", "mobileassetd", "softwareupdated", "nsurlsessiond", "trustd", "accountsd", "apsd", "securityd", "notifyd")
| where FileName in~ ("sh", "bash", "zsh", "python3", "python", "perl", "ruby", "osascript", "curl", "wget", "nc", "ncat")
| summarize ShellCount = count(), Commands = make_set(ProcessCommandLine, 10), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by DeviceName, InitiatingProcessFileName, FileName
| where ShellCount >= 1
| sort by ShellCount desc
Hunting — SPL
spl
index=endpoint (sourcetype="jamf:pro" OR sourcetype="crowdstrike:events") event_type="ProcessCreate"
| where parent_process_name IN ("mdmclient", "mobileassetd", "softwareupdated", "nsurlsessiond", "trustd", "accountsd", "apsd", "securityd")
  AND process_name IN ("sh", "bash", "zsh", "python3", "perl", "osascript", "curl", "wget", "nc")
| eval days_ago=round((now() - _time) / 86400, 1)
| stats count AS spawn_count, values(process_commandline) AS commands, min(_time) AS first_seen, max(_time) AS last_seen, values(days_ago) AS days BY host, parent_process_name, process_name
| sort - spawn_count

Atomic Red Team Tests

Test 1 Simulate Apple System Daemon Crash with Non-Zero Exit
macos

Simulates the crash of an Apple system daemon process to generate telemetry consistent with CVE-2025-31277 exploitation. Uses a controlled process termination to mimic the observable artifacts without triggering actual vulnerability exploitation.

Command

bash
#!/bin/bash
# LAB ENVIRONMENT ONLY - Simulates daemon crash telemetry
# Create a mock daemon process and crash it
cat > /tmp/mock_trustd.sh << 'EOF'
#!/bin/bash
echo "[mock-trustd] Starting..."
sleep 5
# Simulate abnormal exit (buffer overflow crash exit code)
kill -SIGSEGV $$
EOF
chmod +x /tmp/mock_trustd.sh
# Execute with process name mimicking trustd for telemetry
exec -a trustd /tmp/mock_trustd.sh &
MOCK_PID=$!
echo "Mock trustd PID: $MOCK_PID"
wait $MOCK_PID
echo "Mock trustd exited with: $?"

Cleanup

bash
rm -f /tmp/mock_trustd.sh; killall -q mock_trustd 2>/dev/null || true

Expected Telemetry

Process crash event for 'trustd' (or mock process) with SIGSEGV signal, non-zero exit code, and EXC_BAD_ACCESS exception type visible in /Library/Logs/DiagnosticReports/ and EDR crash telemetry

Expected Detection

Detection rule should fire on ProcessExceptionEvent or process crash with process name matching Apple system daemon list and non-zero exit code

Test 2 Spawn Shell from Apple Daemon Context (Post-Exploitation Simulation)
macos

Simulates the post-exploitation behavior where an attacker achieves code execution via CVE-2025-31277 and spawns a shell from an Apple system daemon context. Uses sudo to approximate daemon-level privilege for telemetry generation.

Command

bash
#!/bin/bash
# LAB ENVIRONMENT ONLY - Simulates post-exploitation shell spawn
# This simulates what an attacker would achieve after exploiting CVE-2025-31277
# by spawning a shell in a context that mimics Apple daemon execution

# Create a script that appears to be launched from a daemon context
cat > /tmp/daemon_spawn_test.sh << 'EOF'
#!/bin/bash
# Simulated post-exploitation command execution
echo "[CVE-2025-31277 simulation] Shell spawned from daemon context"
whoami
uname -a
# Simulate reconnaissance commands an attacker might run
id
ls /Users/
EOF
chmod +x /tmp/daemon_spawn_test.sh

# Execute the script - in real exploitation this would be spawned by the vulnerable daemon
bash /tmp/daemon_spawn_test.sh
echo "Test completed - check EDR for ProcessCreate event with parent context"

Cleanup

bash
rm -f /tmp/daemon_spawn_test.sh

Expected Telemetry

ProcessCreate event showing bash spawning /tmp/daemon_spawn_test.sh, with subsequent child processes for whoami, uname, id, and ls commands — EDR should record full process ancestry and command lines

Expected Detection

Detection rule for shell spawn from Apple system daemon context should fire; process ancestry analysis should flag the unusual parent-child relationship

Test 3 Generate Crash Report Artifact for Apple Daemon
macos

Generates a synthetic crash report artifact in the macOS DiagnosticReports directory consistent with what CVE-2025-31277 exploitation would produce, enabling forensic artifact collection testing and SIEM ingestion validation.

Command

bash
#!/bin/bash
# LAB ENVIRONMENT ONLY - Generates synthetic crash report for detection testing
# Real CVE-2025-31277 exploitation would produce similar crash reports

CRASH_DIR="$HOME/Library/Logs/DiagnosticReports"
mkdir -p "$CRASH_DIR"

cat > "$CRASH_DIR/trustd_CVE202531277_sim.crash" << 'EOF'
Process:               trustd [1234]
Path:                  /usr/libexec/trustd
Identifier:            com.apple.trustd
Version:               ???
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
Responsible:           trustd [1234]

Date/Time:             2026-06-19 12:00:00.000 +0000
OS Version:            macOS 14.0 (23A344)
Report Version:        12

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000041
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [12345]

Thread 0 Crashed:
0   trustd                        0x0000000100004abc buffer_process + 0x2bc
1   trustd                        0x0000000100003def handle_input + 0x1ef
2   trustd                        0x0000000100002abc main + 0x3bc

Binary Images:
0x100000000 - 0x10001ffff trustd (1.0) <AABBCCDD-1234-5678-ABCD-AABBCCDDEEFF> /usr/libexec/trustd
EOF

echo "Synthetic crash report created at: $CRASH_DIR/trustd_CVE202531277_sim.crash"
echo "Verify your log collection agent picks up this artifact"

Cleanup

bash
rm -f "$HOME/Library/Logs/DiagnosticReports/trustd_CVE202531277_sim.crash"

Expected Telemetry

File creation event in ~/Library/Logs/DiagnosticReports/ for trustd crash file; log collection agents (Elastic Agent, CrowdStrike) should ingest the .crash file and surface EXC_BAD_ACCESS exception type in SIEM

Expected Detection

Log ingestion pipeline should forward crash report content to SIEM; file monitoring rules should alert on new .crash files for Apple system processes; forensic artifact collection runbooks should be triggered for IR teams

Related Detections