---
name: defend-memory-corruption
description: "Compiler and allocator hardening against memory-corruption exploitation - stack and heap buffer overflows, use-after-free, and integer overflows that attackers turn into code execution (MITRE ATT&CK T1203, T1068, T1210; D3FEND D3-PSEP, D3-SAOR, D3-SFCV, D3-SSC, D3-EHPV). Signals live in the Windows Application log (Event ID 1000, exception codes 0xc0000409, 0xc0000374, 0xc0000005), the Security-Mitigations channels, Sysmon process-creation events, and Linux journald/auditd segfault and glibc abort messages. Gives which hardening flags and allocator settings to deploy, how to verify posture across a fleet, and how to spot failed exploit attempts in crash telemetry. Use when hardening C or C++ builds, choosing GCC/Clang or MSVC security flags, enabling DEP/ASLR/CFG/CET or a hardened allocator, auditing exploit-protection posture, triaging repeated crashes on an internet-facing service, or hunting memory-corruption exploitation."
---

# Memory-Corruption Exploitation - 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

Memory corruption (stack and heap overflows, use-after-free, integer overflow) is the raw material of most binary exploitation. You cannot patch the whole class away, but every mitigation you turn on forces the attacker to chain more primitives, and each extra step is another chance to crash and get caught. Do three things: build first-party C and C++ with the full hardening flag set, enforce OS-level exploit protection (DEP, ASLR, CFG, CET, SafeSEH) across the fleet, and collect the crash and mitigation telemetry so a failed exploit attempt shows up as an alert instead of a silently restarted service. This skill is defensive: it explains exploitation only as far as hardening and detection need, and ships no exploit tooling.

## What it looks like, defender view

A real exploit attempt that fails against your mitigations does not look like malware; it looks like a crash. The hardening above converts a quiet memory overwrite into a loud, specific process termination: a `/GS` stack cookie mismatch ends the process with `STATUS_STACK_BUFFER_OVERRUN`, a corrupted heap with `STATUS_HEAP_CORRUPTION`, and a wild read or write with an access violation. A successful exploit is quieter - the tell moves downstream to an unexpected child process (a browser, Office, or PDF reader spawning a shell) or anomalous in-memory activity. So defenders watch two layers: the crash-level signal that a mitigation fired, and the behavioural signal that one did not.

## Log sources and signals

Windows, per host:

- **Application log, Event ID 1000 (Application Error)** and **Event ID 1001 (Windows Error Reporting)**. The load-bearing field is the exception code: `0xc0000409` (STATUS_STACK_BUFFER_OVERRUN) is the highest-signal value because it only fires when a stack canary or `__fastfail` guard was actually clobbered; `0xc0000374` (STATUS_HEAP_CORRUPTION) flags heap metadata damage; `0xc0000005` (access violation) is common but noisy. Record the faulting module name and offset to cluster crashes.
- **Microsoft-Windows-Security-Mitigations/UserMode** and **/KernelMode** operational channels. These log when a process mitigation policy (DEP, ASLR, CFG, child-process restriction, code integrity) blocks or audits an action. See Microsoft Learn "Troubleshoot exploit protection mitigations" for the per-event mapping rather than memorising IDs.
- **Kernel BugCheck 0x139 (KERNEL_SECURITY_CHECK_FAILURE)** in System log / minidumps for kernel-side corruption guard trips.
- **Sysmon**: Event ID 1 (ProcessCreate) for exploit-to-shell transitions (document or browser process as parent of `cmd.exe`, `powershell.exe`, `wscript.exe`, `rundll32.exe`), Event ID 8 (CreateRemoteThread), Event ID 10 (ProcessAccess) as post-exploitation tells.

Linux, per host (dmesg / journald / auditd):

- Kernel ring buffer lines of the form `segfault at <addr> ip <addr> sp <addr> error <n> in <module>` captured by journald.
- glibc abort messages written to the service's stderr and journal: `*** stack smashing detected ***` (stack protector), `*** buffer overflow detected ***` (FORTIFY_SOURCE), and allocator aborts such as `malloc(): corrupted top size`, `double free or corruption`, and `free(): invalid pointer`.
- auditd `type=ANOM_ABEND` records with `sig=11` (SIGSEGV) or `sig=6` (SIGABRT), and core dumps collected by systemd-coredump (`coredumpctl list`).

Normal baseline: healthy software crashes rarely and diffusely. The anomaly is a cluster - the same internet-facing daemon or parser aborting repeatedly in a short window, or any process ending with `0xc0000409` / a stack-smashing abort, which healthy code essentially never does.

## Detection approach

Alert on the mitigation-fired signals first because they are low-volume and high-confidence: any `0xc0000409` STATUS_STACK_BUFFER_OVERRUN, any `0xc0000374` heap-corruption termination, any `*** stack smashing detected ***` or FORTIFY abort, and any Security-Mitigations block event. Then correlate volume: N crashes of one image on one host inside a short window, which catches an attacker iterating on an unreliable exploit. Finally, layer the behavioural rule - a sandboxed document or browser process spawning an interpreter or `rundll32.exe` - to catch the exploit that did not crash.

No tuned UMBRASEC rule ships for this threat yet. For public, maintained starting points, see the SigmaHQ application-error and process-creation rules at [github.com/SigmaHQ/sigma](https://github.com/SigmaHQ/sigma/tree/master/rules/windows/builtin/application) and [.../rules/windows/process_creation](https://github.com/SigmaHQ/sigma/tree/master/rules/windows/process_creation), the Linux auditd and process rules under [.../rules/linux](https://github.com/SigmaHQ/sigma/tree/master/rules/linux), and the Microsoft Defender Exploit Guard guidance on Microsoft Learn. Baseline each in audit/report-only mode before you alert on it.

## Threat hunt

Posture drift is the hunt that fits this skill: a mitigation you believe is on is often off on some subset of the fleet. Hunt for the gap, not just the attack.

1. On Windows, run `Get-ProcessMitigation -System` for the machine policy and `Get-ProcessMitigation -Name <image>.exe` for key internet-facing or parser processes; flag any where DEP, ASLR (BottomUp + HighEntropy), CFG, or the mitigations you set via Intune/GPO are `OFF` or `NOTSET`.
2. Scan your own compiled binaries with winchecksec or BinSkim (Windows) and `checksec` (Linux) across the fleet; list every image missing stack canaries, NX/noexecstack, full RELRO, PIE/ASLR, or CET. Third-party binaries you cannot rebuild go on a risk register.
3. On Linux, confirm `kernel.randomize_va_space=2` and that production builds carry FORTIFY and stack-protector symbols rather than shipping unhardened.
4. Over a long window, pull Event ID 1000 grouped by faulting module and host; a module that crashes on multiple hosts, or repeatedly on one, is a hunt lead whether or not a mitigation fired. Join crashes against your asset inventory to rank by exposure and privilege.

## Hardening

Raise the cost of every corruption primitive. Build first-party code hardened, deploy OS exploit protection everywhere, and run a hardened allocator.

Compiler and linker (GCC / Clang): `-fstack-protector-strong`, `-D_FORTIFY_SOURCE=2` (use `=3` on GCC 12+/glibc 2.34+), `-fPIE -pie`, `-Wl,-z,relro,-z,now` (full RELRO), `-Wl,-z,noexecstack`, `-fstack-clash-protection`, `-fcf-protection=full` (x86 Intel CET: shadow stack + IBT), `-mbranch-protection=standard` (ARM PAC + BTI), and `-ftrivial-auto-var-init=zero`. The OpenSSF "Compiler Options Hardening Guide for C and C++" at [best.openssf.org](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html) is the maintained reference.

Compiler and linker (MSVC): `/GS`, `/sdl`, `/DYNAMICBASE`, `/HIGHENTROPYVA`, `/NXCOMPAT`, `/guard:cf` (Control Flow Guard), `/guard:ehcont` (EH continuation), `/CETCOMPAT` (hardware shadow stack), and `/SAFESEH` on x86.

Allocators: glibc hardens free-list pointers by default on modern versions; add `GLIBC_TUNABLES=glibc.malloc.check=3` and `glibc.malloc.perturb` for test builds. On Windows enable the Segment Heap for your image and `HeapEnableTerminationOnCorruption`. Where you control the runtime, adopt a security-focused allocator such as Scudo, GrapheneOS hardened_malloc, or Chromium's PartitionAlloc, and use ARM MTE (Memory Tagging) on hardware that supports it. For new code, follow the CISA "Case for Memory Safe Roadmaps" and ONCD "Back to the Building Blocks" direction and prefer memory-safe languages.

| Control | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|
| Patch memory-corruption CVEs in OS and applications fast | Patch applications; Patch operating systems | A.8.8 Technical vulnerabilities | ID.RA; PR.PS Platform Security |
| Enforce OS exploit protection (DEP, ASLR, CFG, CET, SafeSEH) fleet-wide | User application hardening | A.8.19 Software on systems | PR.PS Platform Security |
| Build first-party code with hardening flags and a hardened allocator | - | A.8.19 Software on systems | PR.PS Platform Security |
| Collect and alert on crash and mitigation telemetry | ML2/ML3 event-log requirements | A.8.15 Logging; A.8.16 Monitoring activities | DE.CM Continuous monitoring; DE.AE Adverse events |

Mappings follow the control codes used in the UMBRASEC guides ([foundation.html](https://umbrasec.dev/guide/foundation.html), [detection-and-response.html](https://umbrasec.dev/guide/detection-and-response.html)); a cell is left blank where no single strategy maps cleanly.

## Honest limitations

Crash telemetry sees only the attempts that fail. A reliable exploit that reuses existing code and never faults produces no crash event, so this layer is a tripwire for the sloppy attacker, not proof of safety. Mitigations have known edges: ASLR falls to any information leak that discloses a base address; Control Flow Guard protects only forward edges (indirect calls), leaving return-address attacks to CET, which needs both recent hardware and `/CETCOMPAT`-linked images; SafeSEH only helps if every loaded module opted in. You cannot recompile closed-source third-party binaries, so their hardening is whatever the vendor shipped. Memory-safe languages remove most of the class but not `unsafe` blocks or FFI boundaries. And no bespoke, tuned UMBRASEC rule exists for this threat yet, so treat the detection section as method plus public starting points, baselined in your own environment, not a drop-in alarm.

## ATT&CK and D3FEND

- MITRE ATT&CK: [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/). Mitigations: M1050 Exploit Protection, M1051 Update Software, M1048 Application Isolation and Sandboxing.
- MITRE D3FEND (Application Hardening): [D3-PSEP Process Segment Execution Prevention](https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/) (DEP/NX), [D3-SAOR Segment Address Offset Randomization](https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/) (ASLR), [D3-SFCV Stack Frame Canary Validation](https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/) (`/GS`, stack protector), [D3-SSC Shadow Stack Comparisons](https://d3fend.mitre.org/technique/d3f:ShadowStackComparisons/) (Intel CET shadow stack; ARM PAC maps instead to D3-PAN Pointer Authentication), [D3-EHPV Exception Handler Pointer Validation](https://d3fend.mitre.org/technique/d3f:ExceptionHandlerPointerValidation/) (SafeSEH).
- Public rule sources: [SigmaHQ](https://github.com/SigmaHQ/sigma) (windows/builtin/application, windows/process_creation, linux); Microsoft Learn "Troubleshoot exploit protection mitigations"; OpenSSF [Compiler Options Hardening Guide](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html).

**Scope note.** This is a defensive skill. It explains memory corruption only to the depth needed to harden against and detect it, and deliberately ships no exploit, shellcode, or bypass tooling. UMBRASEC publishes defense, not offense.