Exploit Development Fundamentals

Exploit development transforms a vulnerability — a software defect that causes unintended behavior — into a controlled capability: arbitrary code execution, privilege escalation, or information disclosure. Modern exploit development must contend with a full stack of mitigations (ASLR, DEP/NX, stack canaries, CFG, CET) that individually raise the bar and collectively require multi-stage bypass chains. This chapter establishes the mental model: memory layout, vulnerability primitives, and the mitigation landscape that every subsequent exploit chapter builds on.

Process Memory Model (x64)

Exploit Mitigations

Vulnerability Classes

// STACK BUFFER OVERFLOW — write past end of stack-allocated buffer
void vuln_stack(const char* input) {
    char buf[64];
    strcpy(buf, input);  // no bounds check → overflow if input > 64 bytes
    // Overwrites: local vars → saved RBP → saved RIP → caller's stack
}

// HEAP BUFFER OVERFLOW — write past end of heap allocation
void vuln_heap(int size, const char* data) {
    char* buf = (char*)malloc(size);
    memcpy(buf, data, strlen(data));  // strlen(data) may exceed size
    // Overwrites adjacent heap chunk headers → heap metadata corruption
}

// USE-AFTER-FREE — access memory after it has been freed
struct Obj { void(*vfptr)(); int data; };
void vuln_uaf() {
    Obj* o = (Obj*)malloc(sizeof(Obj));
    o->vfptr = legit_function;
    free(o);
    // Attacker allocates same-size chunk → fills with controlled data including fake vfptr
    o->vfptr();  // calls attacker-controlled address if reallocated with attacker data
}

// TYPE CONFUSION — cast object to wrong type; access fields at wrong offsets
// INTEGER OVERFLOW — arithmetic wraps, causing undersized allocation
//   malloc(user_count * sizeof(record)) where user_count * size overflows DWORD
// FORMAT STRING — printf(user_input) → %n writes to arbitrary address

Fuzzing and Vulnerability Discovery

// Fuzzing: feed malformed/mutated input to target; monitor for crashes.
// Crash → potential exploitable condition (especially AccessViolation).
// Tools: WinAFL (coverage-guided), libFuzzer (LLVM sanitizers), boofuzz (network).

// Minimal WinAFL harness for a file parser:
// Compile target with AFL instrumentation; run WinAFL to mutate input files.

// Crash triage: !exploitable (WinDbg extension) categorizes:
//   EXPLOITABLE:     corrupted stack or heap pointer → execution redirected
//   PROBABLY EXPLOITABLE: controlled data near corruption
//   UNKNOWN:         crash but no obvious control
//   NOT EXPLOITABLE: null deref or assertion in trusted code

// AddressSanitizer (ASAN) in MSVC /fsanitize=address:
// Instruments every memory access; reports heap/stack OOB, UAF, double-free.
// Essential for finding exploitable bugs during fuzz corpus analysis.

// Cyclic pattern for offset discovery (e.g., pwntools cyclic()):
// Send AAAABBBBCCCCDDDD... as input
// On crash, RSP contains part of the pattern → offset = cyclic_find(rsp_value)

Exploit Primitive Hierarchy

Detection Engineering

title: Process Crash with Suspicious Module Context (Potential Exploitation)
logsource:
  product: windows
  service: application
detection:
  selection:
    EventID: 1000  # Application Error (WER)
    ExceptionCode: '0xc0000005'  # Access Violation
  suspicious_offset:
    FaultingModuleOffset|startswith: '0x00000000000041'  # 0x41414141 pattern
  condition: selection or suspicious_offset
level: high
tags: [attack.initial_access, T1203]

title: WER Fault Bucket — Repeated Crashes of Same Process (Fuzz/Exploit Attempt)
logsource:
  product: windows
  service: application
detection:
  selection:
    EventID: 1001  # WER Fault Bucket
  timeframe: 5m
  condition: selection | count() by EventData.AppName > 5
level: medium

-- MDE KQL: application crashes with access violation (potential exploitation)
DeviceEvents
| where ActionType == "ExploitGuardExploitDetected"
    or ActionType == "ExploitGuardNetworkProtectionBlocked"
| project Timestamp, DeviceName, InitiatingProcessFileName,
    AdditionalFields

-- MDE KQL: WER crash dump creation (may indicate exploit attempt)
DeviceFileEvents
| where Timestamp > ago(1d)
| where FolderPath has @"\CrashDumps\" or FolderPath has @"\WER\"
| where FileName endswith ".dmp"
| where InitiatingProcessFileName =~ "WerFault.exe"
| summarize crash_count = count()
    by DeviceName, bin(Timestamp, 1h)
| where crash_count > 5
| order by crash_count desc

Q&A