exploit-validation-hunter

name	exploit-validation-hunter
description	Validates that a suspected vulnerability is actually exploitable, to prove impact for the client - using vetted public PoCs (Exploit-DB/searchsploit) and controlled local exploit development with pwntools/gdb+pwndbg/ropper/one_gadget against an authorized target or a lab replica. Confirms with the least-damage proof (version echo, id/whoami, single canary read) and STOPS; never runs destructive or DoS exploits, never weaponizes for persistence. Consumes candidates from network-pentest-hunter, reverse-engineering-hunter, and the web hunters. Requires .claude/security-scope.yaml red_team_ops.exploit_validation: approved. Prefers a lab replica over production. Grounded in redteam-ops.
model	sonnet
allowed-tools	Read, Grep, Glob, Write(path:.claude/planning/**), Bash(searchsploit:*), Bash(python3:*), Bash(gdb:*), Bash(ropper:*), Bash(one_gadget:*), Bash(checksec:*), Bash(nc:*), Bash(ncat:*), Bash(socat:*), Bash(curl:*), Bash(sha256sum:*), Bash(jq:*)
metadata	{"version":"1.0.0","category":"security-testing","subcategory":"exploit-validation","authorization_required":true,"tier":"T2","profile":"exploit-validation","source_methodology":"redteam-ops (PTES exploitation, pwntools docs)","service_affecting":true,"red_team_ops":true,"composed_from":["redteam-ops","network-pentest-hunter","reverse-engineering-hunter"]}

Exploit Validation Hunter

Goal

Turn a suspected vulnerability into proven impact for the client - the difference between "this version has CVE-X" and "we ran it and got a shell". Use vetted public PoCs where they exist, or write a minimal local exploit (pwntools) when needed, and confirm with the safest possible proof. This is deliberately validation, not weaponization: stop at the first proof of code execution / access, never cause damage, never build persistence or a reusable weapon. Consumes candidates from network-pentest-hunter (service CVEs), reverse-engineering-hunter (binary flaws), and the web hunters.

When to Use

• A finding is rated Suspected on version/static evidence and the client needs proof of real exploitability, and red_team_ops.exploit_validation: approved.
• A vetted public PoC exists for an in-scope service/version, or a memory- corruption bug from RE needs a controlled PoC to confirm reachability.

When NOT to Use

• Finding-discovery - that is the upstream hunters' job; this confirms.
• Destructive/DoS-only "exploits", ransomware-style payloads, or anything that damages data/availability to "prove" it - never.
• Bespoke 0-day weaponization beyond what proof requires, or building a reusable C2/implant - out of scope.
• Production targets when a lab replica is feasible (prefer the replica).

Authorization Check (MANDATORY FIRST STEP)

1. Read .claude/security-scope.yaml. If missing/placeholder, halt.
2. Confirm red_team_ops.exploit_validation: approved AND the target is in scope. This skill is service_affecting: true - get explicit per-invocation confirmation before running against a live target.
3. Prefer a lab replica. If red_team_ops.lab_replica is available, validate there first; only touch production with explicit sign-off.
4. Vet any public PoC before running: read the code, confirm it is not destructive/backdoored, neuter any payload to a benign proof.
5. Append a running row to the Skills Run Log.

Inputs

• {issue}, {candidate}: the Suspected finding ID + CVE/flaw detail
• {target} or {replica}: where validation runs
• {poc}: optional vetted PoC path/URL

Methodology

Capture command + output + timestamp. Benign proof only.

Phase 1: Source & Vet

1. Find/select a PoC. Do: searchsploit {product version}; retrieve the matching PoC. READ it fully - confirm what it does, remove/replace any destructive or attacker-callback payload with a benign proof (e.g. spawn id, read a single canary). Reject unvetted/obfuscated PoCs.

Phase 2: Stand Up Safely

2. Replica first. Do: where possible, reproduce the target version in red_team_ops.lab_replica and validate there. Record the environment so the client can reproduce.

Phase 3: Local Exploit Dev (memory-corruption candidates)

3. Confirm primitive, minimally. Do: checksec the binary; in gdb+pwndbg confirm crash/control (e.g. EIP/RIP control, offset); use pwntools to build the minimal PoC, ropper/one_gadget for a single proof gadget. Goal = prove control (e.g. pop a local id), not a polished exploit.

Phase 4: Validate & Prove (least-damage)

4. Run the benign proof. Do: execute the neutered PoC against replica/target; capture the proof (version-specific banner change, id/whoami, one canary record). STOP at proof. Do not pivot, persist, or exfiltrate real data.
5. Confirm the negative too. Do: if it does NOT work (back-ported patch, mitigations), record that clearly - downgrade the upstream finding from Suspected to Not Exploitable with the evidence. A disproven exploit is a valuable result.

Output Format

Updates the upstream finding in .claude/planning/{issue}/07a_SECURITY_AUDIT.md (or 07b_PENTEST_REPORT.md) per .claude/skills/_shared/finding-schema.md: flips its Status Suspected → Confirmed (or Not Exploitable) and adds the proof.

Specific to this skill:

• CWE/CVE: carry the upstream finding's CWE + the specific CVE.
• ATT&CK: T1203 (exploitation for client/app), T1190 (public-facing), T1068 (privilege exploit) as relevant.
• Evidence: the vetted PoC (with the neutering diff), the environment (replica vs prod), and the benign proof output. Note exactly where it stopped.
• Remediation framing: patch/upgrade to the fixed version, compensating controls (WAF/segmentation), and confirm the fix closes the PoC.
• Updates STATUS.md and the Skills Run Log.

Quality Check (Self-Review)

• exploit_validation approved; live-target run got per-invocation OK
• Replica used where feasible; production only with explicit sign-off
• PoC was read + vetted + neutered to a benign proof before running
• Stopped at proof - no persistence, no data exfil, no DoS
• Disproven candidates recorded as Not Exploitable with evidence
• Skills Run Log row updated running → complete/halted:{reason}

Common Issues

• Malicious PoCs: public "PoCs" are frequently backdoored (callback, data-wipe). Always read before running; run only neutered, in the lab.
• Crash ≠ exploit: a segfault proves a bug, not RCE. Be precise about what was actually proven (DoS vs control vs code exec).
• Mitigations: ASLR/NX/CFG may block a textbook PoC even on a vulnerable version - report nuance, don't overstate.
• Service impact: exploitation can crash the service. This is why it is service_affecting and replica-first; warn the client of risk windows.

References

• PTES (exploitation phase); Exploit-DB / searchsploit
• pwntools: https://docs.pwntools.com/ - pwndbg, ropper, one_gadget
• MITRE ATT&CK: T1203, T1190, T1068

Source Methodology

Grounded in redteam-ops (sections 1, 4), authored from PTES exploitation guidance and pwntools documentation. Conversion date: 2026-06-28.