---
name: defend-exploit-mitigations
description: "Coverage-and-gaps methodology for the memory-corruption exploit mitigations that break an exploit before it runs attacker code: ASLR, DEP/NX, Control Flow Guard (CFG), and CET shadow stack (MITRE ATT&CK T1203, T1190, T1068, T1211, T1210; mitigation M1050). Signals: Windows Security-Mitigations channels, Application log Event IDs 1000 and 1001 with fast-fail and access-violation codes, Defender for Endpoint ExploitGuard events, and Linux auditd ANOM_ABEND, dmesg segfaults, and randomize_va_space. Shows which mitigations are enforced per image and host, how to find gaps with Get-ProcessMitigation, dumpbin, BinSkim, winchecksec, and checksec, how to hunt crash clusters, and how to harden with the Essential Eight. Use when verifying ASLR, DEP, CFG, or CET coverage, auditing exploit protection on a fleet, finding binaries without CFG or CETCOMPAT, triaging a 0xc0000409 fast-fail crash cluster, or building an exploit-mitigation baseline."
---

# Exploit Mitigations (ASLR, DEP, CFG, CET) - 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, the hunt, and the hardening, and points to public, maintained rule sources by URL. 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

Exploit mitigations are a hardening control first and a detection source second. ASLR, DEP/NX, CFG, and CET each remove a primitive an exploit depends on, so the highest-value work is coverage: knowing which mitigations are actually enforced on every process and every image, then closing the gaps where a binary ships without CFG or without a CETCOMPAT load-config. The detection value is secondary but real: when a mitigation fires or an exploit fails mid-run, the process crashes, and a cluster of fast-fail (`0xc0000409`) or access-violation (`0xc0000005`) crashes on an internet-facing service is a strong exploitation signal. Audit coverage with `Get-ProcessMitigation`, `dumpbin`, BinSkim, winchecksec, and `checksec`; watch the Security-Mitigations channels and Windows Error Reporting for the crashes; harden with the Essential Eight. No single mitigation is complete, so measure the set end to end.

## What it looks like, defender view

A mitigation doing its job is usually a crash, not a clean alert. When an exploit violates CFG or the CET shadow stack, Windows raises a fast-fail and the process terminates with exception code `0xc0000409`, while a DEP violation raises an access violation, `0xc0000005`, on the execute attempt (STATUS_STACK_BUFFER_OVERRUN, which the OS reuses for the whole family of security fast-fails including `/GS`, CFG indirect-call failures, and CET return-address mismatches). A failed exploit that does not trip a specific check instead shows as an access violation, `0xc0000005`, or heap corruption, `0xc0000374`. Either way the tell is a cluster: the same image, often a browser, Office component, PDF reader, or an internet-facing service, crashing repeatedly in a short window on one or many hosts, rather than the occasional lone crash normal software produces. For the mitigations that have an audit mode (ACG and the image-load guards), Exploit Protection records the same attempt without the kill, so the Security-Mitigations channel carries the evidence even when the process survives; CFG and DEP have no audit mode and show up only as the crash; CET user-mode shadow stack (Hardware-enforced Stack Protection) does offer an audit mode (AuditUserShadowStack) that records violations in the Security-Mitigations channel without terminating the process. The coverage side has no telemetry at all: an image compiled without `/GUARD:CF` or without `/CETCOMPAT` simply never produces these events, which is exactly why the audit half of this skill matters as much as the hunt half.

## Log sources and signals

Enforcement-and-failure signals (something fired or crashed):

- **Microsoft-Windows-Security-Mitigations/KernelMode** and **Microsoft-Windows-Security-Mitigations/UserMode** operational channels record Exploit Protection mitigation events per process, in both audit and enforce/block variants, for the mitigations that support audit mode: ACG (returns STATUS_DYNAMIC_CODE_BLOCKED), code-integrity guard (STATUS_INVALID_IMAGE_HASH), and the image-load blocks. Enable those mitigations in audit mode first so these channels populate without killing apps. Per Microsoft, CFG and mandatory/bottom-up ASLR have no audit mode, so a CFG violation does not appear here; it surfaces as the `0xc0000409` fast-fail below.
- **Application** log, **Event ID 1000** (source Application Error) and **Event ID 1001** (source Windows Error Reporting): carry the faulting image name, module, and the exception code. Key on `0xc0000409` (security fast-fail, the CFG/CET/`/GS` family), `0xc0000005` (access violation), and `0xc0000374` (heap corruption). Windows Error Reporting also drops report folders under `%ProgramData%\Microsoft\Windows\WER`.
- **Microsoft Defender for Endpoint advanced hunting**, table **DeviceEvents**, where `ActionType` starts with `ExploitGuard` (both audited and blocked variants) surfaces the same mitigation events fleet-wide without touching per-host Event Viewer.
- **Linux**: `auditd` **ANOM_ABEND** records abnormal process termination; `dmesg` / kernel ring buffer shows `segfault` lines with the faulting address and `error` code; `coredumpctl list` enumerates crashes; a repeated crash of a network daemon is the equivalent signal.

Coverage signals (what is or is not protected, read on demand, not from a log):

- **`Get-ProcessMitigation -System`** and **`Get-ProcessMitigation -Name <image.exe>`** report the effective ASLR (BottomUp, ForceRelocateImages/mandatory), DEP, CFG, and CET (UserShadowStack) state per system and per image.
- **`dumpbin /headers`** shows the image characteristics: Dynamic base (ASLR), High Entropy VA (64-bit ASLR), NX compatible (DEP), and Control Flow Guard; **`dumpbin /loadconfig`** shows the CFG table, and the CETCompat flag appears in the extended DLL characteristics debug directory entry shown by `dumpbin /headers`.
- **BinSkim** ([github.com/microsoft/binskim](https://github.com/microsoft/binskim)) and **winchecksec** ([github.com/trailofbits/winchecksec](https://github.com/trailofbits/winchecksec)) audit PE images at scale for exactly these flags; **`checksec`** and Debian **`hardening-check`** do the same for ELF (RELRO, NX, PIE for ASLR, stack canary, FORTIFY). `cat /proc/sys/kernel/randomize_va_space` (2 = full ASLR) reports the Linux kernel ASLR setting.

What normal looks like: a mature baseline has mandatory ASLR, DEP, and CFG on for the internet-facing app set, CET on where the silicon and the images support it, and a known, small rate of benign crashes per image. The anomaly is a crash cluster on a monitored image, or an audit scan finding a high-value binary with CFG or CETCompat absent.

## Detection approach

Alert and audit on two distinct things; do not conflate them.

1. **Mitigation-fired / exploit-failed crashes.** Alert when a monitored image produces a burst of `0xc0000409`, `0xc0000005`, or `0xc0000374` faults in a short window on an internet-facing service or a commonly targeted client app, correlating Application log 1000/1001 by image name and host. Treat a Security-Mitigations enforce/block event (ACG, code-integrity guard, image-load) as higher precision because the OS already judged the behavior malicious. A single crash is noise; the cluster, or any block event on a server that should never be executing dynamic code, is the signal.
2. **Coverage gaps.** On a schedule, run BinSkim or winchecksec across the app inventory and `Get-ProcessMitigation` across the fleet, and raise a finding for any high-value image missing `/GUARD:CF` or `/CETCOMPAT`, or any host where mandatory ASLR or DEP is not enforced system-wide. This is the detection with no log source: it is a configuration audit, and it is where most real risk lives.

Use public, maintained rules rather than inventing one; a tuned UMBRASEC rule is not yet shipped for this threat. Real starting points:

- **SigmaHQ**, the `rules/windows/builtin/security_mitigations/` directory for Security-Mitigations channel rules, and `rules/windows/builtin/application/` for Application channel rules, at [github.com/SigmaHQ/sigma](https://github.com/SigmaHQ/sigma).
- **Microsoft Learn - Exploit protection reference** ([learn.microsoft.com/en-us/defender-endpoint/exploit-protection-reference](https://learn.microsoft.com/en-us/defender-endpoint/exploit-protection-reference)) for the per-mitigation audit/enforce behavior and status codes, and the advanced-hunting `DeviceEvents` ExploitGuard schema.
- **MITRE D3FEND** ([d3fend.mitre.org](https://d3fend.mitre.org/)) to tie each mitigation to its countermeasure.

## Threat hunt

Hypothesis: an attacker is exploiting a monitored process, or a high-value image is running without the mitigations that would stop them.

1. **Crash-cluster hunt.** Over 7 to 30 days of Application log 1000/1001 (or MDE `DeviceEvents`), group faults by (image name, host) and count `0xc0000409`, `0xc0000005`, and `0xc0000374`. Rank by rate and by whether the image is internet-facing. A browser renderer crashing a handful of times is normal; a web service or a document parser spiking to dozens of fast-fails is a T1190/T1203 candidate. Pull the WER report folder for the top hits to see the faulting module.
2. **Block-event hunt.** List every Security-Mitigations enforce/block event (ACG STATUS_DYNAMIC_CODE_BLOCKED, code-integrity STATUS_INVALID_IMAGE_HASH, image-load blocks) on servers. Benign dynamic-code generation is rare outside browsers and JIT runtimes, so a block on a back-end service warrants investigation.
3. **Coverage-gap hunt.** Run winchecksec or BinSkim over the full binary inventory of the internet-facing and privileged app set. Produce a table of (image, ASLR, DEP, CFG, CETCompat). Every row missing CFG or CETCompat on a reachable, high-value image is a prioritized hardening finding; join it to `Get-ProcessMitigation -System` to confirm the host-level defaults are not silently off.
4. **CET-readiness hunt.** Cross-reference hosts whose CPU supports CET (Intel Tiger Lake / AMD Zen 3 or newer) and OS supports user-mode shadow stacks against those where `Get-ProcessMitigation` shows UserShadowStack actually enabled. The delta is CET coverage you are entitled to but not using.

## Hardening

Shrink the surface by making the mitigations mandatory and by keeping software current enough to carry CFG and CET. The controls below ground in the UMBRASEC [foundation guide](https://umbrasec.dev/guide/foundation.html), which maps the Essential Eight to ISO 27001:2022 and NIST CSF 2.0 directly.

| Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|---|
| Enforce Exploit Protection on the app set (mandatory ASLR, DEP, CFG, CET where supported) | Turns mitigations on system-wide and per-image so an exploit loses the primitives it needs, after audit mode confirms compatibility | User application hardening | A.8.7 Malware; A.8.19 Software on systems | PR.PS Platform Security |
| Patch applications and operating systems | Pulls in recompiled binaries that ship CFG and CETCompat and closes the memory-corruption bugs mitigations only paper over | Patch applications; Patch operating systems | A.8.8 Technical vulnerabilities | ID.RA; PR.PS Platform Security |
| Application control (allow only approved software) | Blocks unmitigated or attacker-supplied binaries from executing at all | Application control (from ML1 on workstations) | A.8.19 Software on systems | PR.PS Platform Security |
| Restrict administrative privileges | Limits the blast radius of an exploit that does land, so a user-context bug is not an instant takeover | Restrict administrative privileges | A.8.2 Privileged access rights | PR.AA-05 Least privilege |

## Honest limitations

Mitigations raise the cost of exploitation; they do not end it, and the telemetry only exists when they fire. An information leak that discloses a module base defeats ASLR before any crash occurs. Data-only and counterfeit-object attacks operate within the control-flow graph CFG and CET permit, so neither is tripped. CET user-mode shadow stacks need Intel Tiger Lake / AMD Zen 3 or newer silicon and a CETCOMPAT-linked image, so unsupported hardware or a legacy binary leaves a gap you cannot log your way around. Audit mode records but does not block, and the crash-cluster signal fires only when an exploit fails; a reliable, quiet exploit that works first try produces one clean crash or none. CFG has no audit mode because it is compiled in, so an image built without `/GUARD:CF` simply has no CFG and no event either way. That is why the coverage audit is the load-bearing half of this skill: measure what is actually enforced per image and per host, treat the crash hunt as a tripwire for the exploits that fail, and never assume a mitigation named in policy is live on the binary in front of you.

## ATT&CK and D3FEND

- MITRE ATT&CK: [T1203 Exploitation for Client Execution](https://attack.mitre.org/techniques/T1203/), [T1190 Exploit Public-Facing Application](https://attack.mitre.org/techniques/T1190/), [T1068 Exploitation for Privilege Escalation](https://attack.mitre.org/techniques/T1068/), [T1211 Exploitation for Defense Evasion](https://attack.mitre.org/techniques/T1211/), [T1210 Exploitation of Remote Services](https://attack.mitre.org/techniques/T1210/).
- MITRE ATT&CK mitigation: [M1050 Exploit Protection](https://attack.mitre.org/mitigations/M1050/), the canonical mitigation for this whole skill.
- MITRE D3FEND: [D3-SAOR Segment Address Offset Randomization](https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/) (ASLR) and [D3-PSEP Process Segment Execution Prevention](https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/) (DEP/NX). CET shadow stacks map to [D3-SSC Shadow Stack Comparisons](https://d3fend.mitre.org/technique/d3f:ShadowStackComparisons/); D3FEND has no dedicated technique that maps cleanly to CFG, so forward-edge control-flow integrity is described in prose.
- Public rule sources: SigmaHQ `rules/windows/builtin/security_mitigations/` and `rules/windows/builtin/application/` at [github.com/SigmaHQ/sigma](https://github.com/SigmaHQ/sigma); Microsoft Learn exploit protection reference; MITRE D3FEND.

**Scope note.** This is a defensive skill. It explains exploitation only to the depth needed to verify, detect, and harden the mitigations against it, and deliberately ships no exploit code, bypass techniques, or offensive tooling.