AI Fuzzing

AI-Assisted Fuzzing

Supplementary Files:

• payloads.md — Tool commands and payloads organized by 9 phases (target analysis, corpus preparation, AFL++ execution, libFuzzer, Honggfuzz, web API fuzzing, protocol fuzzing, crash analysis, quick start checklist)
• test-cases.md — Structured test case templates (4 cases covering binary discovery, web API, protocol, and file format fuzzing)

Extended Guides (guides/):

• guides/coverage-guided-fuzzing.md — AFL++ internals, corpus management, mutation operators, parallel fuzzing, crash triage
• guides/web-api-fuzzing.md — OpenAPI schema fuzzing, GraphQL fuzzing, REST boundary testing, authentication fuzzing
• guides/protocol-fuzzing.md — Network protocol fuzzing, TLS/SSL fuzzing, custom binary protocols, BooFuzz framework

Summary

Coverage-guided fuzzing engines, AI-driven seed generation, intelligent mutation strategies, and systematic crash triage.

Tools: AFL++, libFuzzer, Honggfuzz, radare2, BooFuzz, wfuzz

Domain: ai

Skill Identity

Description

AI-assisted fuzzing for automated vulnerability discovery. Coverage-guided fuzzing engines, AI-driven seed generation, intelligent mutation strategies, and systematic crash triage. Integrates with AFL++, libFuzzer, and Honggfuzz to maximize path exploration and uncover memory corruption, logic errors, and parsing flaws in binaries, web APIs, and network protocols.

Fuzzing is the single most effective technique for discovering unknown vulnerabilities at scale. This skill combines traditional coverage-guided approaches with AI-enhanced seed selection and mutation to dramatically increase the probability of reaching deep code paths that manual testing misses.

Use Cases

1. Binary Vulnerability Discovery — Fuzz native binaries (C/C++/Rust) for memory corruption: buffer overflows, use-after-free, integer overflows, and null pointer dereferences
2. Web API Fuzzing — Systematically test REST/GraphQL endpoints with malformed inputs, boundary values, and unexpected content types to uncover auth bypasses and injection flaws
3. Protocol Fuzzing — Fuzz network protocol implementations (TLS, SSH, HTTP parsers, DNS resolvers) by generating malformed packets and invalid state transitions
4. File Format Fuzzing — Fuzz parsers for complex file formats (images, documents, archives, media) to discover parsing vulnerabilities in consumer software
5. Regression Testing — Maintain continuous fuzzing in CI/CD pipelines to catch regressions and newly introduced vulnerabilities before release

Core Tools

Methodology

Attack Chain

  Phase 1              Phase 2              Phase 3
 Target Analysis    Corpus Preparation    Fuzzing Execution
 ┌────────────┐     ┌──────────────┐     ┌──────────────┐
 │ Binary ID  │     │ Seed         │     │ AFL++ /      │
 │ Attack     │────>│ Creation &   │────>│ libFuzzer /  │
 │ Surface    │     │ Minimization │     │ Honggfuzz    │
 │ Map        │     │ Quality      │     │ Execution    │
 └────────────┘     └──────────────┘     └──────┬───────┘
                                               │
  Phase 6              Phase 5              Phase 4
  Report &             Crash               Verification
  Hardening            Triage              & PoC
 ┌────────────┐     ┌──────────────┐     ┌──────────────┐
 │ Root Cause │<────│ Dedup &      │<────│ Independent  │
 │ Analysis   │     │ Severity     │     │ Crash        │
 │ Advisory   │     │ Classify     │     │ Reproduction │
 └────────────┘     └──────────────┘     └──────────────┘

Phase Details:

1. Target Analysis — Identify binary format, architecture, and attack surface. Map input parsing functions, file format structures, and protocol state machines. Select fuzzer based on target type and available source/binary.
2. Corpus Preparation — Collect seed inputs representing diverse code paths. Minimize corpus with afl-cmin/afl-tmin. Generate dictionaries from format specifications and string analysis.
3. Fuzzing Execution — Launch fuzzer with appropriate instrumentation. Monitor coverage growth and stability. Tune mutation parameters, dictionaries, and memory limits. Run parallel instances for multi-core utilization.
4. Verification — Reproduce each unique crash independently. Eliminate false positives (ASAN glitches, OOM, timeout). Confirm exploitability with radare2/GDB analysis.
5. Crash Triage — Deduplicate crashes by root cause. Classify severity (code execution, denial of service, information leak). Assess exploitability with exploitability metrics.
6. Report & Hardening — Document root cause, affected versions, and reproduction steps. Recommend fixes (input validation, bounds checking, sanitizer integration). Feed crash patterns to knowledge-ops for future reference.

Defense Perspective

Practical Steps

For detailed commands and payloads see payloads.md, and for the complete test checklist see test-cases.md. Below is a summary of core operations for each phase.

1. Binary Fuzzing with AFL++

# Step 1: Instrument the target (source available)
afl-clang-fast -o target_fuzz target.c -fsanitize=address

# Step 2: Prepare minimal seed corpus
mkdir seeds/ && echo "sample" > seeds/seed1
afl-cmin -i seeds/ -o seeds_min/ -- ./target_fuzz @@

# Step 3: Launch fuzzer
afl-fuzz -i seeds_min/ -o findings/ -m none -- ./target_fuzz @@

# Step 4: Analyze crashes
afl-showmap -o /dev/null -- ./target_fuzz findings/default/crashes/id:000001*

2. Web API Fuzzing

# Fuzz API parameters with wfuzz
wfuzz -z file,/usr/share/seclists/Fuzzing/big.txt \
  --hc 404,400 http://target/api/v1/FUZZ

# Boundary value testing
wfuzz -z range,0-255 http://target/api/v1/users?id=FUZZ

# Content-type manipulation
for ct in application/json text/xml application/x-www-form-urlencoded; do
  curl -X POST -H "Content-Type: $ct" -d '{"test":"data"}' http://target/api/v1/endpoint
done

3. Protocol Fuzzing with BooFuzz

# Define protocol structure and fuzz
from boofuzz import *
session = Session(target=Target(connection=TCPSocketConnection("target", 8080)))
s_initialize("request")
s_string("GET", fuzzable=True)
s_delim(" ", fuzzable=True)
s_string("/api/endpoint", fuzzable=True)
s_delim(" ", fuzzable=True)
s_string("HTTP/1.1", fuzzable=True)
s_static("\r\n\r\n")
session.connect(s_get("request"))
session.fuzz()

4. Crash Analysis Workflow

# Analyze crash with radare2
r2 -A findings/default/crashes/id:000001*
aaa                          # Full analysis
pdf @ sym.vulnerable_func   # Disassemble crash location
db sym.vulnerable_func      # Set breakpoint at crash site
dc                          # Run until breakpoint

# Analyze ASAN report for root cause
# Look for heap-buffer-overflow, stack-use-after-scope, etc.
ASAN_SYMBOLIZER_PATH=llvm-symbolizer ./target_fuzz crash_input

Detection Methods

Fuzzer Process Detection

• Process names: afl-fuzz, libFuzzer, honggfuzz, boofuzz, peach, winAFL running on production systems.
• High CPU signatures: Sustained 100% CPU on a single process; pattern of crashes + restarts.
• Mutator signatures: Distinctive mutations in input (long strings, hex patterns, special characters).
• Coverage instrumentation: SanitizerCoverage / DynamoRIO / Pin agent loaded into target binary.

Target Application Indicators

• Crash dumps accumulation: Spike in core files, .dmp files, /var/crash/ entries.
• ASAN/MSAN reports: Sanitizer error reports in stderr or syslog.
• OOM kills: Linux OOM killer activity; Windows low-memory events.
• Watchdog triggers: Service watchdog restart loops; systemd unit restart count spikes.
• Network protocol anomalies: Boofuzz/Peach patterns in protocol captures; malformed magic bytes; oversized lengths.

SIEM Detection Rules

• Splunk SPL: index=linux sourcetype=auditd type=EXECVE | search a0 IN ("afl-fuzz","honggfuzz","boofuzz","Peach")
• Sysmon Event ID 1: Process creation; alert on afl-fuzz.exe, winAFL.exe, boofuzz-* on production.
• Sigma rule: sigma/rules/linux/fuzzing_tool_execution.yml
• Container runtime: Falco rule Launching fuzzing tool in container.

Defense Evasion Techniques

Fuzzer Obfuscation

• Rename binary: Rename afl-fuzz to network_monitor to evade process name detection.
• Static build: Statically compile fuzzer to avoid dynamic library dependencies.
• Memory-only execution: Load fuzzer via memfd_create; no file artifacts.
• Slow fuzzing: Pace fuzzing below detection threshold (e.g., 10 exec/sec instead of 1000).
• Distribute load: Run fuzzer across multiple compromised hosts; aggregate crashes centrally.

Coverage Stealth

• User-mode-only instrumentation: Avoid kernel hooks (eBPF detection); use compile-time instrumentation.
• Standalone harness: Build custom harness rather than using LibFuzzer (avoid known signatures).
• Sanitizer alternatives: Use custom signal handlers instead of ASAN (avoid sanitizer signatures in core dumps).
• Process injection: Inject fuzzer into legitimate process (e.g., chrome.exe, python); inherits legitimate identity.

Crash Artifact Cleanup

• Immediate cleanup: Delete core files, ASAN logs after each crash extraction.
• Custom logger: Replace default ASAN symbol printer with custom logger that writes to encrypted location.
• Stream test cases: Don't save crashing inputs to disk; stream over network to attacker-controlled collector.
• Disable apport/abrtd: Disable crash reporters on Linux (systemctl stop apport).

Hacker Laws

Orchestration

ECC Pattern: Learning Cycle

┌─────────────────────────────────────────────────────────┐
│                   Learning Cycle                         │
│                                                         │
│  ┌──────────┐    ┌──────────┐    ┌──────────────┐      │
│  │ Analyze  │───>│  Fuzz    │───>│   Triage     │      │
│  │ Coverage │    │  Cycle   │    │   Crashes    │      │
│  └────┬─────┘    └──────────┘    └──────┬───────┘      │
│       │                                 │              │
│       │        ┌──────────┐             │              │
│       └────────│ Refine   │<────────────┘              │
│                │ Strategy │                            │
│                └──────────┘                             │
└─────────────────────────────────────────────────────────┘

• Pattern: Learning Cycle (iterative refinement of fuzzing strategies based on coverage feedback)
• Rationale: Fuzzing is inherently iterative — seed quality, mutation strategies, and coverage improve with each cycle. Each round of triage informs the next fuzzing strategy.
• Integration:
  • binary-reverse — Crash analysis and root cause identification
  • verification-loop — Independent finding confirmation before reporting
  • knowledge-ops — Persisting crash patterns and successful mutation strategies for future campaigns

Cross-Skill Pipeline

codebase-onboarding → ai-fuzzing → verification-loop → article-writing
      (target          (discover      (confirm each       (document
       analysis)        crashes)       crash)              findings)

Quality Gate

Learning Resources

Supplementary files for this skill:

• payloads.md — Complete command collection organized by 9 phases (ready to copy and use)
• test-cases.md — Structured test cases (4 scenarios with preconditions and expected results)

Extended guides (guides/):

• guides/coverage-guided-fuzzing.md — AFL++ internals, mutation operators, corpus management, parallel fuzzing, crash triage, performance tuning
• guides/web-api-fuzzing.md — OpenAPI schema fuzzing, GraphQL fuzzing, REST boundary testing, authentication fuzzing, Burp Suite integration
• guides/protocol-fuzzing.md — Network protocol fuzzing, TLS/SSL fuzzing, custom binary protocol analysis, BooFuzz framework, real-world examples

Related skills:

• skills/binary-reverse/SKILL.md — Crash analysis and reverse engineering (used in Phase 4/5)
• skills/verification-loop/SKILL.md — Finding confirmation protocol (used in Quality Gate)
• skills/api-security/SKILL.md — API attack surface analysis (informs web API fuzzing)

External resources:

• AFL++ Documentation — AFL++ architecture, usage, and best practices
• libFuzzer Documentation — LLVM fuzzing library reference
• OSS-Fuzz — Google's continuous fuzzing service for open-source software
• Fuzzing101 — Step-by-step fuzzing tutorial with AFL++
• The Fuzzing Book — Comprehensive fuzzing techniques reference