---
name: Windows Mitigations
slug: windows-mitigations
category: Quality
description: Windows Mitigations covers Windows exploit mitigations such as ASLR, DEP, CFG, CET, SEHOP, and ACG, including known bypass techniques. Use it when researching Windows hardening, planning mitigation bypass strategies, or analyzing crash dumps to identify which protection stopped an exploit.
github: "https://github.com/SnailSploit/Claude-Red/tree/main/Skills/infrastructure/offensive-windows-mitigations"
language: Python
stars: 2929
forks: 479
install: "npx degit https://github.com/SnailSploit/Claude-Red/tree/main/Skills/infrastructure/offensive-windows-mitigations ~/.claude/skills/offensive-windows-mitigations"
installs_to: ~/.claude/skills/offensive-windows-mitigations
source_path: Skills/infrastructure/offensive-windows-mitigations/SKILL.md
collection_size: 25
category_size: 1354
collection_url: "https://dirskills.com/collections/SnailSploit/Claude-Red"
added: 2026-08-17T07:10:01.972Z
last_synced: 2026-08-17T07:10:01.972Z
canonical_url: "https://dirskills.com/skills/windows-mitigations"
---

# Windows Mitigations

Windows Mitigations covers Windows exploit mitigations such as ASLR, DEP, CFG, CET, SEHOP, and ACG, including known bypass techniques. Use it when researching Windows hardening, planning mitigation bypass strategies, or analyzing crash dumps to identify which protection stopped an exploit.

**Install:**

```bash
npx degit https://github.com/SnailSploit/Claude-Red/tree/main/Skills/infrastructure/offensive-windows-mitigations ~/.claude/skills/offensive-windows-mitigations
```

## README

# SKILL: Week 6: Understanding Windows Mitigations

## Metadata
- **Skill Name**: windows-mitigations
- **Folder**: offensive-windows-mitigations
- **Source**: https://github.com/SnailSploit/offensive-checklist/blob/main/6-windows-mitigations.md

## Description
Deep-dive on Windows exploit mitigations: ASLR, DEP/NX, CFG, CET/Shadow Stack, SEHOP, Heap Guard, ACG, Arbitrary Code Guard. Covers both the protection mechanism and known bypass techniques. Use when researching Windows exploit mitigations, planning bypass strategies, or understanding protection depth.

## Trigger Phrases
Use this skill when the conversation involves any of:
`Windows mitigations, ASLR, DEP, NX, CFG, CET, shadow stack, SEHOP, heap guard, ACG, mitigation bypass, exploit mitigation, Windows hardening`

## Instructions for Claude

When this skill is active:
1. Load and apply the full methodology below as your operational checklist
2. Follow steps in order unless the user specifies otherwise
3. For each technique, consider applicability to the current target/context
4. Track which checklist items have been completed
5. Suggest next steps based on findings

---

## Full Methodology

# Week 6: Understanding Windows Mitigations

## Overview

_created by AnotherOne from @Pwn3rzs Telegram channel_.

Last week you learned basic exploitation in an environment without protections.
This week, you'll learn about the defensive mechanisms that modern Windows systems employ to prevent those attacks.
Understanding these mitigations is essential before learning to bypass them (Week 8). Week 7 continues with enterprise security topics (offensive reconnaissance, Windows 11 24H2/25H2 mitigations, cross-platform defenses).

**This Week's Focus**:

- Understand how each mitigation works
- Learn to detect active mitigations
- Verify mitigation effectiveness
- Test exploits against protected binaries
- Prepare for Week 7's boundaries and Week 8's bypass techniques

### Prerequisites

Before starting this week, ensure you have:

- Completed Week 5: Basic Exploitation (Linux) - you should be able to exploit stack overflows, build ROP chains, and use pwntools
- A Windows 11 VM (isolated, snapshot before each exercise)
- Visual Studio 2022 Build Tools installed
- WinDbg Preview installed
- Basic familiarity with x64 assembly and calling conventions

### Week 6 Deliverables

By the end of this week, you should have completed the following:

- [ ] **Lab Environment**: Windows 11 VM with Visual Studio Build Tools, WinDbg Preview, and Sysinternals installed
- [ ] **Test Binaries**: Compiled `vulnerable_suite_win_mitigated.c` and `vuln_server_win.c` with various mitigation flags
- [ ] **DEP Verified**: Demonstrated DEP blocking shellcode execution with crash analysis (Exception Code 0xC0000005, Param 8)
- [ ] **ASLR Measured**: Recorded addresses of `check_aslr.exe` across 3 reboots and documented randomization behavior
- [ ] **Stack Cookie Tested**: Triggered `/GS` cookie check failure and analyzed in WinDbg
- [ ] **CFG Validated**: Demonstrated CFG blocking indirect call to invalid target
- [ ] **Crash Dumps Analyzed**: Created at least 3 crash dumps and identified which mitigation caused each termination using `!analyze -v`
- [ ] **Week 5 Exploit Retesting**: Re-ran Week 5 exploits against mitigated binaries and documented failures
- [ ] **Mitigation Audit Report**: Generated system-wide and per-binary mitigation audit using PowerShell scripts
- [ ] **Hardening Capstone**: Completed the SecureServer v1.0 hardening exercise (Day 7)

### Context

Why Mitigations Matter: Modern exploits chain multiple vulnerabilities and bypass layers of protection. Understanding mitigations helps you:

- Recognize when an exploit is blocked vs. when it succeeds
- Analyze crash dumps to identify exploitation attempts
- Design defense-in-depth strategies
- Prepare for Weeks 7-8 (advanced mitigations and bypass techniques)

**Recent CVEs Demonstrating Mitigation Importance**:

| CVE            | Vulnerability                   | Mitigations Involved | Outcome                               |
| -------------- | ------------------------------- | -------------------- | ------------------------------------- |
| CVE-2024-21338 | AppLocker (appid.sys) EoP       | KASLR, SMEP, kCFG    | Admin-to-Kernel bypass of kCFG        |
| CVE-2024-30088 | Authz Kernel TOCTOU             | KASLR, SMEP, CFG     | Exploited via race condition          |
| CVE-2023-36802 | MSKSSRV Object Type Confusion   | KASLR, SMEP, CFG     | Pool spray + type confusion to EoP    |
| CVE-2025-29824 | CLFS Driver Use-After-Free      | KASLR, SMEP          | Zero-day exploited in wild (Apr 2025) |
| CVE-2024-49138 | CLFS Heap-Based Buffer Overflow | DEP, ASLR, KASLR     | EoP exploited in wild (Dec 2024)      |
| CVE-2023-32019 | Windows Kernel Info Disclosure  | KASLR                | Leaked kernel memory bypassing KASLR  |
| CVE-2023-28252 | CLFS Driver EoP                 | KASLR, SMEP          | Abused CLFS log file parsing          |
| CVE-2022-34718 | Windows TCP/IP RCE (EvilESP)    | DEP, ASLR, CFG       | Required sophisticated heap grooming  |

**Connection to Week 4 (Crash Analysis)**:

When you receive a crash dump, the exception codes reveal which mitigation stopped the exploit:

```text
Week 4 Crash Analysis -> Week 6 Mitigation Identification
─────────────────────────────────────────────────────────
Process Exit Code         WinDbg Exception Code        Mitigation
──────────────────────    ─────────────────────        ──────────
0xC0000005 (Param[0]=8)   0xC0000005                   DEP violation (execute on NX page)
0xC0000409                0xC0000409 (subcode 2)        /GS stack cookie corruption
0x80000003                0xC0000409 (subcode 10)       CFG indirect call validation failed
0x80000003                0xC0000407                    CET shadow stack mismatch
0xC0000374                0xC0000374                    Heap integrity check failed

IMPORTANT: Python/cmd see the PROCESS EXIT CODE. WinDbg sees the EXCEPTION CODE.
CFG and CET both use __fastfail() which raises int 0x29 -> exit code 0x80000003,
but the EXCEPTION RECORD inside WinDbg shows the original status code.
```

### Windows Mitigations Relevance

Understanding these bug classes prepares you for real-world vulnerability research:

| Bug Class        | Example CVE                | Mitigation Interaction                            | Week 8 Bypass        |
| ---------------- | -------------------------- | ------------------------------------------------- | -------------------- |
| Race Condition   | CVE-2024-30088 (Authz)     | TOCTOU bypasses simple checks                     | Timing manipulation  |
| Type Confusion   | CVE-2023-36802 (MSKSSRV)   | CFG validates calls, but confused object bypasses | Object spray         |
| Pointer Deref    | CVE-2024-21338 (appid.sys) | kCFG bypass via direct manipulation               | Arbitrary read/write |
| Integer Overflow | CVE-2021-34535 (RDP)       | Safe integer functions                            | Find unchecked paths |
| Arbitrary Write  | CVE-2023-28252 (CLFS)      | KASLR, SMEP                                       | Info leak chain      |

## Day 1: DEP and ASLR Fundamentals

- **Goal**: Understand the two foundational exploit mitigations: DEP and ASLR.
- **Activities**:
  - _Reading_:
    - [Microsoft DEP Documentation](https://learn.microsoft.com/en-us/windows/win32/memory/data-execution-prevention)
    - [Bypassing ASLR/DEP ](https://www.exploit-db.com/docs/english/17914-bypassing-aslrdep.pdf)
    - [ASLR Implementation Details](https://blackhat.com/presentations/bh-dc-07/Whitehouse/Paper/bh-dc-07-Whitehouse-WP.pdf)
  - _Online Resources_:
    - [OffensiveCon23 - Changing and Unchanged Things in Vulnerability Research](https://www.youtube.com/watch?v=hz9HiM2eKFY)
    - [Bypass Control Flow Guard Comprehensively](https://www.youtube.com/watch?v=K929gLPwlUs)
    - [BlueHat 2018 - Windows: Hardening with Hardware](https://www.youtube.com/watch?v=8V0wcqS22vc)
    - [OffensiveCon18 - The Evolution of CFI Attacks and Defenses](https://www.youtube.com/watch?v=oOqpl-2rMTw)
    - [Battle Of The SKM And IUM: How Windows 10 Rewrites OS Architecture](https://www.youtube.com/watch?v=LqaWIn4y26E)
  - _Tool Setup_:
    - Windows 11 VM (24H2 recommended)
    - Process Explorer / Process Monitor
    - dumpbin (Visual Studio tool)
    - WinDbg Preview with Time Travel Debugging
  - _Exercise_:
    - Verify DEP blocks shellcode execution
    - Observe ASLR randomization across reboots
    - Compile programs with/without protections
    - Analyze a real CVE crash dump to identify mitigation involvement

### Deliverables

- **Lab Report**: Documented observations of DEP crashes (Exception Code 0xC0000005, Param 8)
- **ASLR Log**: Recorded addresses of `check_aslr.exe` across 3 reboots
- **Crash Analysis**: Completed mitigation identification table for the 4 test dumps
- **Analysis Report**: Completed analysis table for all 4 crash dumps
- **Screenshots**: WinDbg output showing the "Smoking Gun" for each crash
- **Write-up**: 1-paragraph explanation of how you identified each mitigation

### Lab Directory Structure

```bash
C:\Windows_Mitigations_Lab\
- src\                          # Source code for test binaries
- bin\                          # Compiled binaries
- dumps\                        # Crash dumps from WER/ProcDump
- exploits\                     # Week 5 exploits for testing
- reports\                      # Mitigation audit reports
```

### Transitioning from Linux to Windows Debugging

If you are coming from Week 5 (Linux), use this table to map your `pwndbg` commands to WinDbg:

| Description        | Pwndbg Equivalent        | WinDbg Command |
| ------------------ | ------------------------ | -------------- |
| **Crash analysis** | `bt`, `regs`, `context`  | `!analyze -v`  |
| **Memory display** | `x/b`, `x/w`, `x/g`      | `db/dd/dq`     |
| **Smart pointers** | `telescope`              | `dps`          |
| **Disassembly**    | `x/i` or `disassemble`   | `u`            |
| **Set breakpoint** | `break` or `b`           | `bp`           |
| **Hardware watch** | `watch` or `rwatch`      | `ba w`         |
| **Continue**       | `continue` or `c`        | `g`            |
| **Step over/into** | `next` / `step`          | `p` / `t`      |
| **Search memory**  | `search "string"`        | `s -a`         |
| **List modules**   | `vmmap` or `info shared` | `lm`           |
| **Heap analysis**  | `heap`, `bins`, `arena`  | `!heap`        |

> [!TIP]
> **Week 4 Callback**: For more advanced WinDbg usage, refer back to **Week 4: Crash Analysis** where we covered TTD (Time Travel Debugging) and symbol configuration in detail.

### Standardized Vulnerable Targets

To maintain continuity with previous weeks, we will use a Windows port of the vulnerable suite and the capstone server. Save these into `C:\Windows_Mitigations_Lab\src`.

**1. The Mitigation Test Suite (`vulnerable_suite_win_mitigated.c`)**

This replaces generic tests (`dep_test.c`, etc.) with a unified suite mirroring Week 4's lab.

> [!IMPORTANT]
> **Modern MSVC removed `gets()`** - it was removed in C11 as too dangerous.
> We use `fgets()` with a size mismatch instead, which MSVC recognizes as needing `/GS` protection.

```c
/*
 * vulnerable_suite_win_mitigated.c
 * Windows Port of Week 4 Vulnerable Suite
 * Compile with varying flags to test mitigations.
 *
 * NOTE: gets() was removed in modern MSVC. We use fgets() with
 * intentional size mismatch to create the same vulnerability
 * while triggering MSVC's /GS heuristics.
 */
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#pragma comment(lib, "user32.lib")

void stack_overflow() {
    char buffer[64];

    printf("[*] Stack Overflow Target: Buffer at %p\n", buffer);
    printf("[*] Enter payload: ");
    fflush(stdout);

    // Vulnerable: fgets reads up to 256 bytes into 64-byte buffer!
    // This pattern triggers MSVC's /GS protection when compiled with /GS
    fgets(buffer, 256, stdin);
    buffer[strcspn(buffer, "\n")] = 0;  // Remove newline

    printf("[*] Received: %s\n", buffer);
}

void heap_overflow() {
    HANDLE hHeap = GetProcessHeap();
    char *chunk1 = (char*)HeapAlloc(hHeap, 0, 64);
    char *chunk2 = (char*)HeapAlloc(hHeap, 0, 64);

    printf("[*] Heap Chunks: %p, %p\n", chunk1, chunk2);
    printf("[*] Simulating linear overflow from Chunk1...\n");

    // Vulnerable: overflow into chunk2 metadata
    memset(chunk1, 'A', 128);

    printf("[*] Freeing corrupted Chunk2 (Should crash if Heap Integrity on)...\n");
    HeapFree(hHeap, 0, chunk2);
    HeapFree(hHeap, 0, chunk1);
}

void dep_trigger() {
    printf("[*] DEP Trigger: Executing data section...\n");
    // Int3 (0xCC) ; Ret (0xC3)
    unsigned char shellcode[] = { 0xCC, 0xC3 };
    void (*func)() = (void(*)())shellcode;
    func();
}

void funcptr_test() {
    void (*callback)() = dep_trigger;

    printf("[*] Function Pointer Test\n");
    printf("[*] Function pointer at: %p\n", &callback);
    printf("[*] Currently points to: %p\n", callback);
    printf("[*] Enter new function address (hex): ");
    fflush(stdout);

    unsigned long long addr;
    scanf("%llx", &addr);
    callback = (void(*)())addr;

    printf("[*] Calling function at %p...\n", callback);
    callback();  // CFG would block this if target is invalid
}

int main(int argc, char* argv[]) {
    if (argc < 2) {
        printf("Usage: %s <mode>\n", argv[0]);
        printf("Modes: stack, heap, dep, funcptr\n");
        return 1;
    }

    if (strcmp(argv[1], "stack") == 0) stack_overflow();
    else if (strcmp(argv[1], "heap") == 0) heap_overflow();
    else if (strcmp(argv[1], "dep") == 0) dep_trigger();
    else if (strcmp(argv[1], "funcptr") == 0) funcptr_test();

    return 0;
}
```

**2. The Capstone Server (`vuln_server_win.c`)**

A Winsock port of the Week 5 Capstone. Used to test network exploits against hardened Windows.

```c
/*
 * vuln_server_win.c - Winsock Port
 * Compile: cl vuln_server_win.c /link ws2_32.lib
 */
#include <winsock2.h>
#include <windows.h>
#include <stdio.h>

#pragma comment(lib, "ws2_32.lib")

void handle_client(SOCKET client_socket) {
    char buffer[512];
    char response[] = "Welcome to SecureServer v1.0 (Windows)\n";
    send(client_socket, response, strlen(response), 0);

    // VULNERABILITY: Stack Buffer Overflow
    // recv accepts up to 1024 bytes into a 512 byte buffer
    int bytes_received = recv(client_socket, buffer, 1024, 0);

    if (bytes_received > 0) {
        printf("[*] Received %d bytes\n", bytes_received);
        buffer[bytes_received] = '\0';
        // Echo back (Format String vuln potential if printf(buffer) used)
        send(client_socket, buffer, bytes_received, 0);
    }
    closesocket(client_socket);
}

int main() {
    WSADATA wsa;
    SOCKET server_fd, client_fd;
    struct sockaddr_in server, client;
    int c;

    WSAStartup(MAKEWORD(2,2), &wsa);
    server_fd = socket(AF_INET, SOCK_STREAM, 0);

    server.sin_family = AF_INET;
    server.sin_addr.s_addr = INADDR_ANY;
    server.sin_port = htons(8888);

    bind(server_fd, (struct sockaddr *)&server, sizeof(server));
    listen(server_fd, 3);

    printf("[*] Windows Vulnerable Server listening on port 8888...\n");

    c = sizeof(struct sockaddr_in);
    while((client_fd = accept(server_fd, (struct sockaddr *)&client, &c)) != INVALID_SOCKET) {
        printf("[*] Connection accepted\n");
        handle_client(client_fd);
    }

    closesocket(server_fd);
    WSACleanup();
    return 0;
}
```

**Per-Binary Mitigation Control**:

```bash
# RECOMMENDED: Control mitigations via compiler/linker flags per binary
# This is safer, doesn't require reboots, and mirrors enterprise practice

# Build WITHOUT mitigations (for Week 5-style testing):
cl /GS- /D_CRT_SECURE_NO_WARNINGS src\vulnerable_suite_win_mitigated.c /Fe:bin\dep_test.exe /link /NXCOMPAT:NO /DYNAMICBASE:NO /FIXED

# Build WITH mitigations (for Week 6 testing):
cl /GS /guard:cf /D_CRT_SECURE_NO_WARNINGS src\vulnerable_suite_win_mitigated.c /Fe:bin\mitigated_test.exe /link /NXCOMPAT /DYNAMICBASE /HIGHENTROPYVA /guard:cf

# Per-process mitigation control (Run in ADMIN POWERSHELL):
Set-ProcessMitigation -Name "bin\dep_test.exe" -Disable DEP,ForceRelocateImages,BottomUp
Set-ProcessMitigation -Name "bin\dep_test.exe" -Enable DEP,ForceRelocateImages,BottomUp

# NOTE: On x64 Windows, DEP is often MANDATORY for 64-bit processes
# regardless of linker flags. Use Set-ProcessMitigation to override.
```

**Compiler/Linker Flag Reference** (x64):

| Mitigation    | Enable Flag              | Disable Flag             |
| ------------- | ------------------------ | ------------------------ |
| DEP           | `/NXCOMPAT` (default)    | `/NXCOMPAT:NO`           |
| ASLR          | `/DYNAMICBASE` (default) | `/DYNAMICBASE:NO /FIXED` |
| High Entropy  | `/HIGHENTROPYVA`         | (omit flag)              |
| Stack Cookies | `/GS` (default)          | `/GS-`                   |
| CFG           | `/guard:cf`              | (omit flag)              |
| CET Compat    | `/CETCOMPAT`             | (omit flag)              |

### Graduated Mitigation Introduction

#### Step 1: DEP Only

**Setup** (Using Standardized Suite):

```bash
# PREFERRED: Use per-binary linker flags instead of system-wide changes

# Compile WITH DEP, WITHOUT ASLR (to isolate DEP testing)
cl /GS- /D_CRT_SECURE_NO_WARNINGS src\vulnerable_suite_win_mitigated.c /Fe:bin\dep_test.exe /link /NXCOMPAT /DYNAMICBASE:NO /FIXED

# Verify the binary has DEP enabled:
dumpbin /headers bin\dep_test.exe | findstr "NX compatible"
# Should show: "NX compatible"
```

#### Step 2: DEP + ASLR

**Setup**:

```bash
# Compile with BOTH DEP and ASLR enabled via linker flags
cl /GS- /D_CRT_SECURE_NO_WARNINGS src\vulnerable_suite_win_mitigated.c /Fe:bin\aslr_test.exe /link /NXCOMPAT /DYNAMICBASE /HIGHENTROPYVA

# Verify:
dumpbin /headers bin\aslr_test.exe | findstr "NX Dynamic High"
# Should show: NX compatible, Dynamic base, High Entropy Virtual Addresses
```

> [!CAUTION]
> **System DLL ASLR**
> Even if you compile your binary with `/DYNAMICBASE:NO /FIXED`, Windows 10/11 will still randomize the location of **system DLLs** like `kernel32.dll` and `kernelbase.dll` on each boot.
>
> To demonstrate the ASLR bypass working on `dep_test.exe`, you must:
>
> 1. Find the **current** addresses using WinDbg (see instructions below)
> 2. Update the address variables in your script
> 3. The exploit will work on `dep_test.exe` (binary has no ASLR)
> 4. The exploit will **fail** on `aslr_test.exe` (binary base is randomized)
> 5. After a **reboot**, even `dep_test.exe` addresses become invalid - demonstrating why ASLR matters

**Finding Gadget Addresses with WinDbg**:

```bash
# Launch WinDbg with the target
windbg C:\Windows_Mitigations_Lab\bin\dep_test.exe stack

# In WinDbg, run these commands:
0:000> g                                              # Run to the input prompt
0:000> lm                                             # List loaded modules
0:000> x KERNEL32!WinExec                             # Find WinExec address
0:000> s -b KERNELBASE <start> L<size> 59 c3          # Find 'pop rcx; ret' (59 c3)
0:000> u <address> L2                                 # Verify the gadget

# Example session:
# 0:000> x KERNEL32!WinExec
# 00007ffd`616907f0 KERNEL32!WinExec
# 0:000> s -b KERNELBASE 00007ffd`5f8d0000 L3ef000 59 c3
# 00007ffd`5f912303  59 c3 ...
# 0:000> u 00007ffd`5f912303 L2
# 00007ffd`5f912303 59       pop rcx
# 00007ffd`5f912304 c3       ret      <- Clean gadget!
```

**Test Your Week 5 ROP Exploit** (x64):

This script demonstrates a ROP chain that bypasses DEP using `WinExec`. Run it against both binaries to see ASLR's effect:

```python
#!/usr/bin/env python3
# c:\Windows_Mitigations_Lab\exploits\week5_aslr_test.py
"""
Test: Week 5 ROP/ret2lib exploit - Demonstrating ASLR's Effect

Usage:
  1. First, get current addres