Exploit Protection

Exploit Protection

CMMC Control Mapping Matrix

Windows 11 ships with the four system-wide process mitigations NIST 800-171 3.14.1 cares about already enabled by default:

Acronym	What it stands for	What it stops
DEP	Data Execution Prevention	Code execution from memory regions marked as data (heap, stack) — defeats classic shellcode injection that smuggles attacker code into a buffer and jumps to it
ASLR	Address Space Layout Randomization	Predictable memory addresses that exploits rely on. Two flavors matter here: BottomUp randomizes stack/heap base addresses on every process start; ForceRelocateImages ("mandatory ASLR") relocates module images even when a binary wasn't compiled with the /DYNAMICBASE linker flag
SEHOP	Structured Exception Handler Overwrite Protection	Exploits that corrupt the exception-handler chain to hijack control flow when an exception fires
CFG	Control Flow Guard	Indirect calls or jumps to addresses the compiler didn't sanction — defeats many use-after-free and ROP (return-oriented programming) payloads

The gap CMMC L2 expects you to close is tamper protection: a user with local admin can flip any of these off from Windows Security → App & browser control → Exploit protection settings unless you push the lockdown explicitly. This appendix delivers both halves — explicit enforcement plus tamper protection — through one Intune Settings Catalog policy backed by the ExploitGuard CSP.

Why not the XML upload path

The legacy workflow (export an XML from a "golden" Windows machine via Export-ProcessMitigation, upload to an Endpoint Security → Attack Surface Reduction → Exploit Protection profile) still works but isn't what Microsoft is steering new tenants toward. Intune profiles created after April 5, 2022 use the Settings Catalog format; both paths write to the same CSP node. Settings Catalog is more legible in policy reports, easier to diff, and doesn't carry an external XML artifact you have to track. Per-program EMET-style mitigations (Office, Acrobat, line-of-business apps) remain XML-territory — see "Going further" below.

Step 1: Create the Settings Catalog policy

1. In the Intune admin center, navigate to Devices → Configuration → Create → New policy.

2. Platform: Windows 10 and later. Profile type: Settings catalog. Click Create.

3. Basics tab:

   • Name: Win - Custom - ES - Exploit Protection
   • Description: Enforces DEP, ASLR (BottomUp + ForceRelocateImages), SEHOP, and CFG system-wide and prevents user override via the Windows Security UI.

4. Configuration settings tab → + Add settings. In the picker, search for Exploit Guard to filter to the relevant category, then add the two settings in the table below to the policy.

   Setting	Value	What it does
   Disallow Exploit Protection Override	Enabled	Removes the per-mitigation toggles from Windows Security → App & browser control so users (including local admins) cannot disable mitigations from the GUI. CSP node: ExploitGuard/DisallowExploitProtectionOverride. This is the load-bearing tamper-protection setting — without it, the rest is advisory.
   Exploit Protection Settings	(paste the XML below)	Pins per-mitigation values in the policy itself rather than relying on Windows defaults — gives a C3PAO an explicit policy artifact rather than "trust the OS." CSP node: ExploitGuard/ExploitProtectionSettings.

   The minimal XML to paste into the Exploit Protection Settings value (covers system-wide DEP / ASLR / SEHOP / CFG, with mandatory ASLR enabled):

   <MitigationPolicy>
     <SystemConfig>
       <DEP Enable="true" EmulateAtlThunks="false" />
       <ASLR ForceRelocateImages="true" RequireInfo="false" BottomUp="true" HighEntropy="true" />
       <ControlFlowGuard Enable="true" SuppressExports="false" />
       <StructuredExceptionHandling SEHOP="true" SEHOPTelemetry="false" />
     </SystemConfig>
   </MitigationPolicy>

   The one upgrade beyond Windows defaults is ASLR ForceRelocateImages="true" (mandatory ASLR — modules built without /DYNAMICBASE are relocated anyway). If you have known-incompatible legacy software, set this to false and document the exception in your SSP.

5. Scope tags — accept Default unless you have RBAC scope tags in use.

6. Assignments — target the workstation device group, and Servers-MDE (or your server endpoint-security group) as a second target on the same policy. The policy is server-safe on modern Microsoft server roles; see Chapter 12 § Server Endpoint Security set for the conditions that justify forking to a separate Svr - variant.

7. Review + create.

Verification

After deployment to a pilot device:

Check	Where	Expected
Policy reached the device	Intune → Devices → <device> → Device configuration	Win - Custom - ES - Exploit Protection shows Succeeded
Mitigations enforced	PowerShell on the pilot device: Get-ProcessMitigation -System	DEP ON; ASLR BottomUp: ON, ForceRelocateImages: ON, HighEntropy: ON; SEHOP ON; CFG ON
Tamper protection enforced	On the pilot device, open Windows Security → App & browser control → Exploit protection settings	The system-settings toggles show "Some settings are managed by your organization" and are not user-editable
Registry tattoo	Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender ExploitGuard\Exploit Protection'	DisallowExploitProtectionOverride = 1; ExploitProtectionSettings populated with the XML you pasted

Going further (out of scope for the baseline)

• Per-program (EMET-style) mitigations. Office, Edge, Acrobat, and any line-of-business binary that processes untrusted content are good candidates for per-program hardening — child-process restriction, strict handle checks, EAF / EAF+, validate stack integrity, etc. Add <AppConfig Executable="winword.exe">…</AppConfig> blocks to the MitigationPolicy XML above. Microsoft's Customize exploit protection reference has the full attribute list.
• Audit-mode rollout for compatibility-sensitive mitigations. For per-program mitigations on binaries you're not sure are compatible, add the Audit="true" attribute first, watch the Microsoft-Windows-Security-Mitigations/KernelMode and UserMode event channels for affected processes, then promote to enforce after a clean run.
• Servers with legacy line-of-business code. The baseline default is to assign this same policy to both workstation and server groups (see Step 1 → Assignments). Fork to a separate Svr - Custom - ES - Exploit Protection policy only when you have legacy server software that breaks under mandatory ASLR, or per-program mitigations that need audit-mode rollout role-by-role. See Chapter 12 § Server Endpoint Security set.