About active-pentest
active-pentest is an execution harness for security testing specialists, intended for authorized testing of lab, staging, or local applications. It organizes scoped tool use and reproducible proof, with explicit safeguards against destructive testing and production targets.
Key features
- 01Authorization and target-scope gate
- 02Non-destructive testing guidance
- 03Recon-to-validation workflow
- 04Tool selection by testing goal
- 05Consistent PoC evidence capture
Use cases
- 01Testing an authorized staging application
- 02Validating a suspected flaw with a minimal request
- 03Recording reproducible request and response evidence
- 04Handing confirmed findings to security-hardening
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ mn-youssef/ security-skills --skill active-pentestAfter installing, type/active-pentestin Claude Code to confirm it loaded.
Bundled filesreferences/tool-playbook.md
Details
From the project READMEActive 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)
- Recon / fingerprint — what's exposed, what stack, what version.
- Map — enumerate endpoints, params, auth flows (mirror the threat model).
- 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.)
- 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
| Goal | Tool |
|---|---|
| Port/service/version | nmap -sV |
| TLS config | testssl.sh, sslscan |
| Web server quick issues | nikto |
| Content/endpoint discovery | ffuf, gobuster, feroxbuster |
| Manual request crafting | curl, httpie, Burp Repeater |
| Intercept / spider / scan | OWASP ZAP, Burp Suite |
| SQLi confirmation | sqlmap (on your own app, --batch, scoped) |
| Mobile traffic | Burp/ZAP proxy + device, Frida (pinning), objection |
| Secrets in code/binary | trufflehog, gitleaks, apktool+jadx |
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-hardeningfor 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.