redteam-exploit-validation

name	redteam-exploit-validation
description	Focused workflow for validating exploitability safely and turning candidate issues into reproducible, bounded proof.

Red Team Exploit Validation Skill

Focused workflow for validating exploitability safely and turning candidate issues into reproducible, bounded proof.

Activate when the user asks to:

• Validate whether a vulnerability is exploitable
• Build a safe proof of concept for an authorized target, lab, or CTF
• Analyze a CVE, advisory, PoC, or exploit chain
• Add negative controls, cleanup, and detection notes to exploit steps

Workflow

1. Scope and authorization gate
   • Confirm target, environment, permission to exploit, allowed impact level, safe-test window, cleanup expectations, and forbidden actions.
   • If exploitation approval is unclear, stop at analysis and provide benign verification only.
2. Exploitability model
   • Identify affected component, version/build, reachable route/function, auth requirements, attacker-controlled inputs, sink, impact boundary, and environmental dependencies.
3. Evidence review
   • Check vendor advisories, CVEs, patch diffs, package metadata, source code, public PoCs, and existing recon evidence.
   • Treat public PoC claims as untrusted until verified.
4. Proof ladder
   • Start with affected-state proof, then benign canary, then current-user or non-sensitive impact, then higher-impact proof only if explicitly approved.
   • Include a negative control for each meaningful claim.
5. Safety controls
   • Add rate limits, dry-run/non-destructive mode, canary markers, owned callbacks, timeout boundaries, cleanup commands, and stop conditions.
6. Telemetry and OPSEC
   • List logs, WAF events, auth events, process/file/network telemetry, and likely defender detections.
   • Avoid persistence, lateral movement, broad data access, or denial of service unless explicitly authorized.
7. Verifier and report handoff
   • Verify all proof steps and outputs independently.
   • Write a detailed report after verification.

Output contract

Return Markdown with:

• Scope and approval state
• Exploitability model
• Affected-state evidence
• Proof ladder
• Commands / payloads
• Expected output
• Negative controls
• Cleanup and rollback
• Telemetry and detection opportunities
• Stop conditions
• Verifier handoff
• Report notes

Safe PoC requirements

Please refer to references/poc-requirements.md for the rules governing safe Proof of Concept development.

Evidence bar

Confirmed or partially confirmed exploitability requires:

• Affected asset/component
• Proof of affected state
• Proof of exploitability or impact
• Negative control
• Reproduction metadata
• Remediation retest steps

Advanced Exploitation & OOB Validation

• Out-of-Band (OOB) Testing: Utilize interactsh or custom DNS logger for blind SSRF, blind RCE, and blind XXE validation.

• Memory Corruption: Validate buffer overflows by confirming precise EIP/RIP overwrites, identifying bad characters, and testing ASLR/DEP bypass chains (ROP).

• Blind & Time-Based Data Exfiltration: Validate blind SQLi using bit-shifting or binary search inference techniques to limit request volume and avoid WAF blocks.

• Payload Naming (OPSEC): Never use blatant backdoor names like shell.php, cmd.php, or test.php. Blend into the target environment by using convincing names related to the application's context (e.g., class-wp-cache-helper.php, config-update.php, or index_backup.php).