Active Pentest (EXPLOIT harness)

Overview

This is the shared execution harness for the FIND/EXPLOIT specialists. They decide what to test — access-control-testing, authentication-testing, business-logic-testing, api-security-testing (and Tier-2 classes like injection / client-side / file-upload). This skill is how you run their tests safely against a live app: set up the lab/proxy/scanners, drive the tools, and capture proof in a consistent format.

Core principle: A finding isn't real until you've reproduced it. A PoC ends the debate. The specialists own the attack recipes; this skill owns safe execution and evidence.

⚠️ Authorization Gate — STOP if not all true

Do not proceed unless all hold:

• You own the target, or have written authorization to test it.
• Target is a lab / staging / local instance — not third-party production.
• You will not run destructive or DoS techniques, and won't touch real user data.

If any box is unchecked → stop and stay in security-code-audit on code you control.

Scope discipline (non-destructive by default)

• Allowed: read-only recon, fingerprinting, single-request PoCs, reading your own test data,

proving an IDOR with two test accounts you created.

• Avoid: load/stress/DoS, mass scanning, automated exploitation that writes/deletes real data,

techniques whose only purpose is evasion of monitoring. Throttle scanners; use test accounts.

Workflow (recon → map → validate → prove)

1. Recon / fingerprint — what's exposed, what stack, what version.
2. Map — enumerate endpoints, params, auth flows (mirror the threat model).
3. Validate — take the attack recipe from the relevant specialist skill and run it with

the smallest request that proves the bug. (This skill = the tooling; the specialist = the payload.)

1. Prove — capture the exact request/response as the PoC; note impact.

See references/tool-playbook.md for how to drive each tool. For what to send, go to the specialist (e.g. IDOR recipes → access-control-testing, ATO flows → authentication-testing).

Quick reference — tool per goal

Output: validated findings

For each confirmed item:

• Finding ID (link back to the audit register)
• Reproduction: exact command / request
• Evidence: response excerpt proving impact (redact real data)
• Confirmed severity & impact
• → hand to security-hardening for the fix and re-test.

Common mistakes

• Testing prod or third-party assets "just to check" — that's the line you don't cross.
• Running sqlmap/scanners full-throttle and knocking over your own staging.
• Calling something exploitable from theory alone — reproduce it.
• Keeping noisy PoCs — minimal request, minimal blast radius.