mcpField
A
active-pentest

active-pentest

github.com/mn-youssefSecurity4940 installsUpdated 20w ago
Repository

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

  1. 01Authorization and target-scope gate
  2. 02Non-destructive testing guidance
  3. 03Recon-to-validation workflow
  4. 04Tool selection by testing goal
  5. 05Consistent PoC evidence capture

Use cases

  1. 01Testing an authorized staging application
  2. 02Validating a suspected flaw with a minimal request
  3. 03Recording reproducible request and response evidence
  4. 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-pentest

After installing, type/active-pentestin Claude Code to confirm it loaded.

Bundled filesreferences/tool-playbook.md

Details

From the project README

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.)
  4. 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

GoalTool
Port/service/versionnmap -sV
TLS configtestssl.sh, sslscan
Web server quick issuesnikto
Content/endpoint discoveryffuf, gobuster, feroxbuster
Manual request craftingcurl, httpie, Burp Repeater
Intercept / spider / scanOWASP ZAP, Burp Suite
SQLi confirmationsqlmap (on your own app, --batch, scoped)
Mobile trafficBurp/ZAP proxy + device, Frida (pinning), objection
Secrets in code/binarytrufflehog, 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-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.

Comments

Markdown supported