Awesome Pentest

Penetration Test Assessment

Run an authorized penetration test the way a professional engagement does: scope and rules of engagement first, then work the target from an attacker's perspective through recognized methodology, and end with a report a client could act on. This skill is the engagement lifecycle and orchestration layer — it drives the deep-dive siblings (awesome-security-audit for static code review, awesome-dependency-audit for supply chain, awesome-leak-audit for client disclosure) and adds what they don't cover: scoping, attack-surface enumeration, dynamic/runtime testing, exploitation-to-proof, post-exploitation impact, and the engagement report.

It is defensive by intent: the goal is to find and prove real risk so it can be fixed, using a proof-of-concept that demonstrates impact — never a weaponized exploit, never persistence or data theft beyond what the rules of engagement permit. It refuses to attack a target the user is not authorized to test.

This skill produces three things: a rules-of-engagement record, a findings list (each with file:line or endpoint, a source→sink or attack path, CWE/CVSS, and reproduction), and a report with an executive summary, technical detail, and a retest section.

Reference files (load on demand — read the one the target needs, don't inline both):

• [references/test-catalog.md](references/test-catalog.md) — the per-target-class test catalogs (web, API, network/infra, cloud, mobile, auth/session, business logic, AI/LLM) with the concrete checks, mapped to WSTG/MASTG/ATT&CK IDs. This is the working checklist — load it after you know the target class.
• [references/report-template.md](references/report-template.md) — the engagement report structure, the rules-of-engagement record, the standards crosswalk, and CVSS/EPSS/KEV scoring guidance.

Authorization and scope (hard gate)

No active testing without written authorization. Passive review of source, config, and manifests that the user owns or is clearly authorized to read needs no separate gate — that is the same permission awesome-security-audit operates under. Everything else is gated:

• Passive (no gate): reading the target's own code, config, IaC, and manifests; static attack-surface mapping; threat modeling on paper.
• Active (hard gate — requires explicit authorization + scope before running): any network probe, port/vuln scan, fuzzing, request that reaches a live host or third-party service, credential test, exploitation, or post-exploitation step.

Before any active step, confirm in the conversation: the user owns or is authorized to test the target, the exact scope (in-scope hosts/origins/accounts/repos and explicitly out-of-scope), the window and any rate/impact limits, and who to contact if something breaks. Record it (see the rules-of-engagement record in references/report-template.md). Set the egress mode with the scope and name it before the first active command — offline (static and local only, no outbound packet), lab_only (lab/VM ranges you control), or authorized_target_only (only the assets named in scope) — it is the field that catches the two classic overreaches: a "static-only" review that resolves a live domain, and a scoped web test whose scanner follows a redirect off-estate. Confirm any active tool is installed at a known version before you lean on it (nmap --version, exit 0); for a helper server or MCP, installed ≠ running. If authorization is missing or the target is a third party the user can't show permission for, stay passive and say what that leaves unverified — do not probe to "just check." A bug-bounty program's published scope and safe-harbor terms count as authorization for exactly what they list, nothing more.

This is a legitimate authorized-assessment tool. It does not build malware, mass-targeting or DoS tooling, or detection-evasion for unauthorized use; a request in that direction is out of scope regardless of framing.

When to Activate

• User asks for a "pentest", "penetration test", "red team", "offensive assessment", or "attack surface review"
• Preparing for or simulating an engagement against an app, API, service, or infrastructure the user controls
• Working a bug-bounty target within its published scope and safe harbor
• Validating that a set of fixes actually closed previously found issues (retest)
• The user names a methodology: OWASP WSTG/MASTG/API Top 10, PTES, NIST SP 800-115, OSSTMM

Not for: static code/diff review (awesome-security-audit), public-client disclosure (awesome-leak-audit), dependency CVEs (awesome-dependency-audit), or a design-level threat model with no target to test (that is a section of awesome-security-audit).

Work Process

The phases follow PTES, mapped to NIST SP 800-115's four stages (Planning → Discovery → Attack → Reporting). Scale to the request: a "pentest my repo" with no live system is phases 0–4 and 7 (passive, static-heavy); a full authorized engagement runs all of them. Never skip phase 0.

Phase 0 — Pre-engagement (Planning)

Pin the scope, authorization, and box color. Box color sets what you're given: black-box (no internal knowledge — you enumerate from outside), grey-box (some credentials/docs), white-box (full source and config — the repo case). Most repo-targeted pentests are white-box: you have the code, so recon is reading it. Confirm the target class (web app, API, network/host, cloud account, mobile app, CLI/library, monorepo), the objectives (what a realistic attacker wants here — data, funds, takeover), and the rules of engagement. Gate every active step per the section above.

Phase 1 — Detect the target class

Indicator files pick the applicable catalogs before any testing:

• package.json/requirements.txt/go.mod/Gemfile/pom.xml → language and framework, which sets framework-specific mitigations and escape hatches.
• Routes/controllers, an OpenAPI/GraphQL schema, Dockerfile/compose, *.tf/serverless.yml/k8s manifests, AndroidManifest.xml/Info.plist → the target class (web, API, container/cloud, mobile).
• CI config, .env*, IaC → deployment surface.

Load the matching catalog(s) from references/test-catalog.md. A repo is often several classes at once (a web app + its API + its container + its IaC) — run each applicable catalog and say in the report which classes were in scope.

Phase 2 — Intelligence gathering / recon (Discovery)

Build the map an attacker would. White-box: read the code — entry points, routes, auth flow, trust boundaries, external integrations, secrets surface, deployment. Black/grey-box (gated, active): DNS/subdomain enumeration, service and version discovery, technology fingerprinting, content discovery — passive OSINT before active scans, and only within scope. Enumerate: every input the target accepts, every identity it trusts, every place it talks to something else.

Phase 3 — Attack-surface mapping and threat modeling

Turn the recon into an attack plan. Map each trust boundary (client→server, service→service, user→admin, tenant→tenant) and run a STRIDE pass per boundary — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Walk each boundary against the attacker models that can reach it: anonymous, authenticated user, user from another tenant, privileged user, compromised account, malicious integration, insider, automated bot, resource-exhaustion attacker. Prioritize by attacker value × reachability. Where it helps a reader, tie techniques to MITRE ATT&CK IDs. Capture the result as a prioritized test plan — the highest-value, most-reachable surfaces first.

Phase 4 — Vulnerability analysis

Work the prioritized surface against the class catalog in references/test-catalog.md. For the static code portion, drive awesome-security-audit (injection, secrets, authz, crypto, CI/CD) rather than re-deriving it here; for dependencies, drive awesome-dependency-audit; for a public client's disclosure, drive awesome-leak-audit. This skill owns what those don't: the dynamic and cross-component checks — authentication/session behavior at runtime, IDOR and multi-tenant isolation, business-logic abuse, rate-limit and workflow bypass, SSRF/redirect chains, and configuration/deployment exposure. Trace every lead as a source→sink data flow (taint chain); a lead is a lead, not a finding, until both the vulnerable pattern and attacker-controlled input are confirmed. Keep a candidate worklist and drive each lead to an explicit verdict (confirmed / traced-safe / needs-PoC); before a confirmed finding enters the report, run it through adversarial revalidation — argue the code is safe and go find the control that refutes you — and check it against what actually ships (git log ..origin/main -- ), the same verification discipline awesome-security-audit applies to static findings.

Variant sweep — run it on every confirmed finding, before Phase 5. One confirmed bug is a sample of a class the target's authors are prone to. Take its shape (the sink, the missing check, the assumption that failed) and sweep the rest of the surface for it: the same endpoint pattern under a different resource, the same object-id parameter on sibling routes, the same tenant filter absent in the other read paths, the same header trusted by a second service. Sweep both directions — the same flaw in other components, and other flaws in the component that produced this one, since a module with one missing authorization check rarely has exactly one. Record each variant with its own reachability; a class fixed in the one place the report named, while four siblings stay live, is a retest that passes and an engagement that failed.

Phase 5 — Exploitation (to proof, Attack)

Gated. Prove a confirmed vulnerability with the minimum proof of concept that demonstrates impact — a benign marker (alert(document.domain) for XSS, reading a row you're not entitled to, a SELECT version() for SQLi), not a destructive or data-stealing payload. Chain vulnerabilities only to show a realistic path. Stop-on-impact: if a step shows signs of affecting the running system or its data (errors, state changes, lockouts, another user's real data), stop that step and report before continuing. Never run a denial-of-service or resource-exhaustion attack to "prove" it — describe it and its preconditions instead.

Phase 6 — Post-exploitation (impact, Attack)

Gated, and only within the rules of engagement. Establish what the access is worth: what data is reachable, what privilege escalation or lateral movement is possible, what the blast radius is — demonstrated with the least intrusive evidence. Do not exfiltrate real user data, install persistence, pivot to out-of-scope systems, or alter/destroy data. The deliverable is the documented impact and the shortest path to it, not a foothold.

Phase 7 — Reporting

Write the report per references/report-template.md: executive summary (risk in business terms for a non-technical reader), scope and rules-of-engagement record, methodology and standards used, findings ordered by severity with reproduction and evidence, remediation, and an overall risk posture. Escalate any confirmed Critical (RCE, auth bypass, exposed live secret, bulk-PII exposure) to the user the moment it's confirmed with the immediate containment step — don't hold it for the final report.

Phase 8 — Retest

After fixes land, re-run the exact check that produced each finding and assign a status (see Retesting below). A fix that "looks right" is not verified until the original reproduction no longer works.

Engagement state (the durable record)

An engagement outlives a session. Anything not written to a durable record is silently lost — the next session redoes it or contradicts it, and a credential or artifact you cannot account for becomes a problem in the report or on the client's estate. Keep these in one file in the case folder, updated as you work, not reconstructed at the end:

• Scope, authorization, and egress mode — copied verbatim (paraphrased scope is how the wrong estate gets tested), plus the egress mode from the gate above.
• Credential provenance — for every credential, hash, token, or key: what it is, where it came from, how it was obtained, and what it has been used against. A credential you cannot trace is unusable in a report and indistinguishable from a planted one — mark it provenance: UNKNOWN and treat it as suspect.
• Access inventory — each access obtained (host, account, privilege, method) and whether it still works; access decays.
• Artifact register — the cleanup list — every write to a target recorded at the moment you make it (files dropped, accounts or tasks created, config edits, cloud resources). Written from memory at the end it is always incomplete, and what it omits stays on production; the client's blue team also needs it to tell your artifacts from a real intrusion.
• Findings with evidence — captured when you see it; the state that proved it will not survive remediation or a reboot.
• Dead ends — what was tried, against what, and why it failed. This is the difference between "we found nothing there" and "we did not look", and it stops the next session re-running the six-hour crack.

Before a session ends — planned or not — the record must answer: what access do I hold and does it still work, what have I left on target, what was I mid-way through, and what did I rule out. A handoff is that same record plus the immediate next action and anything time-sensitive (a running crack, an expiring token).

Delegation map

The engagement drives the deep-dive siblings; it does not duplicate them.

| Part of the engagement | Owner | |---|---| | Static code review (injection, secrets, authz, crypto, CI/CD) | awesome-security-audit | | Dependency / supply-chain CVEs, typosquats, install scripts | awesome-dependency-audit | | What a public client leaks about its backend; client hardening | awesome-leak-audit | | Database-layer exposure (schema, tenancy, injection surface) | awesome-db-audit | | Regression tests that prove a fix | awesome-test-writing | | Scoping, recon, attack-surface, dynamic testing, exploitation, report | this skill |

When you hand a portion to a sibling, say so in the report and fold its findings into the single severity-ordered list — don't emit two disconnected reports.

What not to flag (false-positive control)

• Server-controlled sources are not attacker input: config, env vars, hardcoded constants, admin-only CLI args. Attacker-controlled: request params/headers/cookies/body, uploads, WebSocket messages, third-party webhooks, and data written by other users.
• Framework-mitigated patterns are safe by default: auto-escaping templates, ORM-parameterized queries, CSRF tokens the framework injects. Flag only the escape hatches (mark_safe, dangerouslySetInnerHTML, .raw(), string-built queries, disabled CSRF).
• Centralized controls before per-route: check for auth middleware, a WAF, a gateway rate-limiter, or a shared authorization layer before flagging a single route as missing one — the #1 pentest false positive is a control that lives one layer up.
• Test/staging affordances intentionally hold insecure patterns and fake credentials — separate bucket; flag only if they ship or the credentials are real.
• "Potentially" is not a finding. Every reported issue needs a concrete attacker, input, and result. Theoretical items go to a "Needs verification" section with the specific open question; defense-in-depth ideas go to "Hardening notes", never into findings.
• A designed rejection is not a bug. An explicit 429, a buffer-full reject, an intentional error return at a boundary is by design; a crash or panic at the

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: khasky
• Source: khasky/awesome-agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.