pentest-exploit-execution-payload-control

Exploit Execution & Payload Control

Use When

• A validated primitive exists and the next phase is controlled exploit implementation, payload hardening, chaining, reliability testing, or impact proof.
• The task is explicitly a lab exploit-development exercise with clear boundaries.

Handoff Criteria

• Hand off to CVE, input/protocol, authz, XSS, OOB, or business-logic workflows when the primitive is not yet validated.
• Hand off to reporting when impact proof and reproducibility are complete.

Output Schema

• Exploit plan: preconditions, primitive, payload strategy, safety guardrails
• Execution log: step, result, evidence
• Final capability statement: what attacker can do after exploitation

Instructions

1. Require at least one validated security primitive before exploit implementation.
2. Choose deterministic payloads with clear rollback or containment strategy.
3. Execute in smallest viable sequence to prove impact with minimal disruption.
4. Record exact preconditions and environmental dependencies.
5. Separate exploit reliability issues from vulnerability existence.
6. Produce reproducible commands and evidence suitable for independent verification.

Verification Gate

• Prefer deterministic, low-noise payloads over broad spray strategies.
• Preserve proof artifacts that map directly to attacker capability.
• Stop when impact is proven; avoid unnecessary escalation.
• Claim successful exploitation only from direct capability evidence, not partial side effects.
• Run destructive payloads only when explicitly authorized.
• Check tool status and dependencies before relying on them; if unavailable, use the safest fallback and report the gap.