--- name: triage-crashes-defensively description: "Exploitability triage of application and service crashes for defenders. A crash in software parsing untrusted input is both a prioritization problem (which memory-safety bug to hotfix first) and an exploitation signal (an access-violation spike on an internet-facing service is a possible exploit attempt), mapping to MITRE ATT&CK T1190, T1203, T1068, T1210, and DoS case T1499.004. Log sources: Windows Application log (Events 1000/1001), Microsoft-Windows-Security-Mitigations channels, Sysmon WerFault telemetry, Linux systemd-coredump and dmesg segfault lines, plus AddressSanitizer output. Gives a defender-safe severity ranking method, the signal-bearing fields, a hunt, and mitigation mapping. Use when triaging a WER Event 1000 or 1001 crash, deciding whether a fuzzer or ASAN crash is exploitable enough to hotfix, investigating a segfault or access-violation spike on a server, or prioritizing crash bugs for patching." --- # Crash Exploitability Triage - Defensive Methodology > **Tier 2 - methodology skill.** No bespoke UMBRASEC detection rule ships with this skill yet. It gives the defender's method, the log sources and signals, and the hardening, and points to public rule sources. Promotion to Tier 1 (a sourced, tuned UMBRASEC rule) is tracked in [COVERAGE.md](https://github.com/umbrasec-labs/umbra-blue/blob/main/COVERAGE.md). Do not treat the content below as citing a UMBRASEC rule; there is none for this threat yet. ## TL;DR for defenders Crash triage for a defender is two jobs, and everything below splits on which one you are doing. **Job A, prioritization:** rank crashes from your own fuzzing, CI, or sanitizer runs so you fix the memory-safety bugs that an attacker could realistically turn into code execution before the ones that only cause a clean abort. **Job B, exploitation signal:** read crash telemetry from production as evidence of an attempt, because the fuzzing an attacker does against your exposed service looks exactly like a cluster of access-violation crashes in one module. The highest-value rank signals are the low-volume, high-confidence ones: a Windows fail-fast (`0xc0000409`) or heap-corruption (`0xc0000374`) means a mitigation already caught a memory-safety bug, so it outranks the flood of ordinary `0xc0000005` access violations. On the sanitizer side, a WRITE outranks a READ, and a use-after-free or heap-overflow write outranks a near-null READ segfault. You do not need to build an exploit to triage; you rank by what the register and fault state imply, then patch and forward telemetry. ## What it looks like, defender view Software that handles attacker-reachable input (a file parser, a network service, a browser component) faults and the process dies. In telemetry this is a Windows Application Error event, a Windows Error Reporting bucket, a systemd-coredump entry, or a kernel `segfault at` line, often several in a short window hitting the same faulting module. A single reproducible crash at a fixed fault offset is a reliable bug; a burst of crashes in one internet-facing service, or crashes whose faulting state shows the program counter or a dereferenced pointer landing on attacker-shaped data, is the pattern worth escalating. No offensive how-to is needed to recognize any of this; it is all in the crash record. ## Log sources and signals **Windows, production telemetry** - **Application log, Event ID 1000, source "Application Error".** Fields: Faulting application name, Faulting module name, Exception code, Fault offset. Triage keys off the exception code: - `0xc0000005` ACCESS_VIOLATION - the high-volume case; most crashes, most of them benign or simple null derefs. - `0xc0000409` STATUS_STACK_BUFFER_OVERRUN - low volume, high signal. A stack cookie (`/GS`), Control Flow Guard, or another fail-fast check fired. A mitigation caught a memory-safety bug. Rank above `0xc0000005`. - `0xc0000374` STATUS_HEAP_CORRUPTION - low volume, high signal. The heap manager detected corruption. Rank above `0xc0000005`. - **Application log, Event ID 1001, source "Windows Error Reporting".** The Fault bucket and the P1 to P10 report parameters give you a free clustering key: the same bucket is the same bug, so you can collapse a noisy crash stream into distinct defects. - **Event ID 1002**, Application Hang, for the hang-not-crash case. - **Microsoft-Windows-Security-Mitigations/KernelMode** and **/UserMode** operational channels. Exploit Protection (the Windows Defender Exploit Guard successor to EMET) writes paired audit and block events per mitigation (DEP, ASLR, CFG, SEHOP, and others). A block event on an internet-facing process is a mitigation stopping a probable exploit primitive. Pull the exact event IDs from Microsoft Learn's exploit protection reference rather than hard-coding them, as they are per-mitigation. - **Sysmon Event ID 1 (process create) for Image ending in `WerFault.exe`.** The ParentImage is the process that just crashed. A crash immediately followed by an unusual new child of that same parent process is the "attempt, then success" sequence worth a closer look. - Crash artifacts on disk: `%LOCALAPPDATA%\CrashDumps`, and WER reports under `%ProgramData%\Microsoft\Windows\WER\ReportArchive` and `ReportQueue`. **Linux, production telemetry** - **systemd-coredump**, read through `coredumpctl list` and `coredumpctl info`, or directly from the journal. Journal fields that carry the signal: `COREDUMP_SIGNAL` / `COREDUMP_SIGNAL_NAME` (SIGSEGV, SIGABRT, SIGILL, SIGFPE, SIGBUS), `COREDUMP_EXE`, `COREDUMP_COMM`, `COREDUMP_UID`, `COREDUMP_CMDLINE`, and `_SYSTEMD_UNIT`. A spike of SIGSEGV on one service unit is the Linux equivalent of the Windows access-violation cluster. - **Kernel ring buffer (dmesg / journald)** `segfault at ADDR ip ADDR sp ADDR error N` lines, plus `general protection fault`, `BUG: KASAN:` (if the kernel is KASAN-built), and `Oops`. Read the `error` bits qualitatively rather than memorizing decimals: they encode user vs kernel, read vs write vs instruction fetch, and mapped vs unmapped page. The two you can state safely are `error 4` (user-mode read of an unmapped page) and `error 6` (user-mode write of an unmapped page); a write fault outranks a read fault for triage. - ABRT on RHEL-family hosts (`/var/spool/abrt`, `abrt-cli`), and `auditd` for the surrounding process context. - `kernel.core_pattern` and `ulimit -c` govern whether a dump even exists; check them before you trust the absence of coredumps. **Sanitizer output, your own builds (Job A)** AddressSanitizer is the richest triage source when you own the source and can rebuild. Read three lines: - The **header class**: `heap-buffer-overflow`, `heap-use-after-free`, `stack-buffer-overflow`, `global-buffer-overflow`, `double-free`, or `SEGV on unknown address`. - The **`READ of size N` / `WRITE of size N`** line. WRITE outranks READ. - The **`SUMMARY:`** line, which gives the faulting function and file for deduplication. A use-after-free or a heap-buffer-overflow WRITE is a stronger candidate for memory-corruption exploitation than a near-null READ SEGV. MemorySanitizer (uninitialized reads), UndefinedBehaviorSanitizer, and LeakSanitizer round out the picture but rank lower for exploitability. ## Detection approach For **Job B**, alert on crash telemetry for your internet-facing and high-value processes rather than on every crash host-wide. The signal is a short-window cluster of `0xc0000005` Event 1000 records with the same Faulting module name on a service that parses untrusted input, or the same clustering on `COREDUMP_EXE` / `_SYSTEMD_UNIT` from systemd-coredump. Treat any `0xc0000409` or `0xc0000374`, and any Exploit Protection block event, as individually alert-worthy because they are low volume and mean a mitigation fired. Use the Event 1001 Fault bucket (or the ASAN SUMMARY line) as the deduplication key so a single reliable crash reproduced a thousand times does not drown out a second, rarer bug. Public, maintained rule sources to adapt rather than inventing one: - SigmaHQ, the Windows rules tree at [github.com/SigmaHQ/sigma/tree/master/rules/windows](https://github.com/SigmaHQ/sigma/tree/master/rules/windows); look under the Application-log and Security-Mitigations areas for Event 1000 / 1001 application-crash and exploit-mitigation rules, and under the Sysmon rules for WerFault process-creation patterns. - SigmaHQ Linux rules at [github.com/SigmaHQ/sigma/tree/master/rules/linux](https://github.com/SigmaHQ/sigma/tree/master/rules/linux) for auditd and journal-backed signals. - Microsoft Learn, Exploit Protection reference, for the Security-Mitigations channel event IDs. - MITRE D3FEND, [d3fend.mitre.org](https://d3fend.mitre.org), for the platform-hardening countermeasures listed below. A tuned UMBRASEC rule is not yet shipped for this threat; build detections from the sources above and baseline them in report-only mode first. For **Job A**, do not alert; bucket. Defensive, open-source severity classifiers that assign EXPLOITABLE-style labels for patch prioritization: - `jfoote/exploitable`, the CERT GDB triage plugin ([github.com/jfoote/exploitable](https://github.com/jfoote/exploitable)). - `ispras/casr`, Crash Analysis and Severity Report ([github.com/ispras/casr](https://github.com/ispras/casr)). - `bnagy/crashwalk` for batch triage of fuzzer output ([github.com/bnagy/crashwalk](https://github.com/bnagy/crashwalk)). - CERT BFF and the CERT Coordination Center triage tools ([github.com/CERTCC](https://github.com/CERTCC)). - The archived Microsoft MSEC `!exploitable` WinDbg extension, historically influential but unmaintained. Use their output as a first-pass sort, not a verdict (see limitations). ## Threat hunt Hypothesis: an attacker is fuzzing or probing an exposed service, and early failed attempts show up as crashes before any successful compromise. 1. Over a long window, pull Windows Event 1000 (or systemd-coredump entries) for your internet-facing and privileged services only, excluding known-noisy internal apps. 2. Group by Faulting module name plus Event 1001 Fault bucket (Windows) or by `COREDUMP_EXE` plus a stack hash (Linux). Rank groups by crash count and by first-seen recency; a brand-new bucket appearing on an exposed service is more interesting than a long-standing noisy one. 3. Within each group, separate the exception codes. Pull every `0xc0000409`, `0xc0000374`, and Exploit Protection block to the top regardless of volume. 4. For the top groups, correlate the crash timestamps against network and WAF logs for the same service and source addresses: repeated crashes tied to a single external client, or to requests with oversized or malformed fields, raise confidence that this is probing rather than a flaky release. 5. Check whether any crashing process spawned an unexpected child (Sysmon Event 1 under WerFault's parent, or a new process under the service unit) around the crash time, which would move this from attempt to possible success. ## Hardening Shrink the window between a triaged crash and an exploitable deployed binary, and make sure you actually capture the telemetry above. Mappings follow the control codes used in the UMBRASEC security guide ([foundation](https://umbrasec.dev/guide/foundation.html) for the patching and hardening rows, [detection and response](https://umbrasec.dev/guide/detection-and-response.html) for the telemetry row); the NIST CSF 2.0 codes are category-level because that is how the guide grounds them. | Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 | |---|---|---|---|---| | Patch the crashing component and run vulnerability management | Closes the memory-safety bug a triaged crash points at, on a schedule, before it is weaponized | Patch applications; Patch operating systems | A.8.8 Technical vulnerabilities | ID.RA; PR.PS | | Enable exploit mitigations (DEP, ASLR, CFG, CET, stack cookies, Exploit Protection) | Raises the cost of turning a given crash into code execution, and many mitigations fire as detectable block events | User application hardening | A.8.19 Software on systems | PR.PS | | Collect crash telemetry centrally (forward WER, retain coredumps) | Without forwarded Event 1000/1001 and a non-discarding `core_pattern`, Job B has nothing to read | - | - | DE.CM | ## Honest limitations - **No crash is not no exploitation.** A reliable exploit does not crash the target; the attacker who gets the memory layout right the first time is invisible to every signal here. Crash telemetry catches failed and noisy attempts, not clean ones. - **The dumps are often not there.** Production hosts frequently run with `ulimit -c 0` or a `core_pattern` that discards, and WER is commonly disabled or never forwarded off the endpoint. Confirm collection before relying on absence. - **Sanitizers need source.** ASAN, MSAN, and UBSan apply to code you can rebuild, which excludes most closed third-party components in production. - **Classifier verdicts are heuristic.** `exploitable`, CASR, crashwalk, and the legacy `!exploitable` all misclassify in both directions: they call unexploitable crashes EXPLOITABLE and miss genuinely exploitable ones. Treat the label as a sort key for human review, never as a final severity. ## ATT&CK and D3FEND - MITRE ATT&CK: [T1190 Exploit Public-Facing Application](https://attack.mitre.org/techniques/T1190/), [T1203 Exploitation for Client Execution](https://attack.mitre.org/techniques/T1203/), [T1068 Exploitation for Privilege Escalation](https://attack.mitre.org/techniques/T1068/), [T1210 Exploitation of Remote Services](https://attack.mitre.org/techniques/T1210/), and [T1499.004 Endpoint Denial of Service: Application or System Exploitation](https://attack.mitre.org/techniques/T1499/004/) for the triage outcome of "crashes but is not code-execution exploitable". - MITRE D3FEND: the countermeasures map to the hardening row above, not to triage itself. Relevant platform-hardening techniques: D3-PSEP Process Segment Execution Prevention (DEP/NX), D3-SAOR Segment Address Offset Randomization (ASLR), D3-SFCV Stack Frame Canary Validation, and D3-EHPV Exception Handler Pointer Validation. Browse them at [d3fend.mitre.org](https://d3fend.mitre.org). - Public rule and tool sources: [SigmaHQ Windows rules](https://github.com/SigmaHQ/sigma/tree/master/rules/windows), [SigmaHQ Linux rules](https://github.com/SigmaHQ/sigma/tree/master/rules/linux), Microsoft Learn Exploit Protection reference, AddressSanitizer documentation, and the triage classifiers listed under Detection approach. **Scope note.** This is a defensive skill. It explains crash exploitability only to the depth needed to rank bugs for patching and to detect exploitation attempts, and deliberately ships no debugger weaponization steps, no exploit primitives, and no offensive tooling. UMBRASEC publishes defense, not offense.