Pentest Methodology skill for Codex
Scope, exploit, document, report. This skill drives an authorized penetration test through a disciplined workflow: it refuses to act until written scope and rules of engagement are confirmed, then recon, enumeration, ranked analysis, least-intrusive exploitation, evidence capture and a remediation-focused report. It keeps every active action tied to an authorizing clause and leaves no artifacts behind.
curl -fsSL codexskills.dev/install.sh \ | sh -s -- pentest-methodologyInstalls to ~/.agents/skills/pentest-methodology/ for every project on this machine.
curl -fsSL codexskills.dev/cli.mjs -o codex-skills.mjsnode codex-skills.mjs install pentest-methodologyThe CLI also searches, updates and removes skills. Run it with no arguments to pick from a list. Needs Node 20.12+.
curl -fsSL codexskills.dev/install.sh \ | sh -s -- --project pentest-methodologyInstalls to .agents/skills/pentest-methodology/ in the current repository. Commit it and everyone who runs Codex there gets it.
curl -fsSLO codexskills.dev/downloads/pentest-methodology.zipunzip -o pentest-methodology.zip -d ~/.agents/skills/The archive holds the skill folder with its generated agents/openai.yaml. Unzip into .agents/skills/ to scope it to a repo.
& ([scriptblock]::Create((irm codexskills.dev/install.ps1))) pentest-methodologyPowerShell 5.1 or 7. Installs to %USERPROFILE%\.agents\skills\. Add -Project for the current repo.
104-line POSIX script. No sudo, no telemetry. Read install.sh
Use it in Codex
Start a prompt with $pentest-methodology, or pick it from /skills.
You can also just describe the task: Codex reads the description below and loads the playbook when your request matches.
What Codex reads before loading it
Runs an authorized penetration test end to end — confirm scope and rules of engagement, recon, enumerate, exploit within limits, document, and report with remediation. Use when you have written authorization to test a target and need a disciplined workflow, evidence handling and a findings report. Not for testing systems you do not own or lack written permission to assess.
Use it when
- You have written authorization to test a specific target
- You need a repeatable, evidenced pentest workflow
- You must produce an auditable report with remediation
Use something else when
- You lack written permission to test the target: do not proceed
- The focus is only web-app testing against WSTG: use web-app-pentest
- You only need network scanning and service enumeration: use nmap-scanning
How to check the result
Every active action maps to an authorizing clause, each finding reproduces from the logged commands, and cleanup confirms no test accounts, shells or background scans remain.
The mistake it prevents
Running scans or payloads before scope and rules of engagement are confirmed in writing, or exceeding the agreed limits with destructive proofs.
A penetration test is authorized, scoped, evidenced and reported. The value is not a shell — it is a clear picture of exploitable risk, proven with reproducible evidence and tied to fixes the owner can act on. Work only inside the written scope, stop at the agreed limits, and never touch anything outside it.
Gate 0 — authorization (do this first, every time)
Do not run a single scan, probe or payload until you have confirmed, in writing:
- Written authorization (signed scope / RoE / contract or an explicit statement from the system owner) naming the tester and the engagement.
- In-scope targets: exact domains, IP ranges, apps, accounts, cloud resources.
- Out-of-scope: what must never be touched (third-party services, prod data, specific hosts, other tenants).
- Allowed techniques and limits: is active exploitation permitted? DoS/stress? social engineering? data exfiltration (and of what)? Default to the most restrictive.
- Testing window, timezone, and any maintenance freeze.
- Emergency contact and the rule for stopping (what triggers an immediate halt).
- Rules for handling any sensitive data discovered (do not download PII unless the RoE allows it; mask it in evidence).
If any of these is missing or ambiguous, stop and ask the user to provide it. Testing without this is out of bounds. Many steps below need network access and tool installs — Codex runs in a sandbox, so call out when a step needs network or an approval, and keep a timestamped command log for the report.
Phases
- [ ] 0. Authorization confirmed (above)
- [ ] 1. Recon — map the in-scope attack surface
- [ ] 2. Enumeration — services, versions, endpoints, users
- [ ] 3. Vulnerability analysis — candidate weaknesses, ranked
- [ ] 4. Exploitation — prove impact, within RoE limits
- [ ] 5. Post-exploitation — only if RoE allows; document reachable impact
- [ ] 6. Reporting — findings, evidence, remediation, retest1–2. Recon and enumeration
Passive first, then active within scope. Map before you poke.
- Network/host discovery and service/version enumeration: hand off to nmap-scanning.
- Attack-surface and OSINT mapping (subdomains, exposed assets): hand off to recon-osint.
- Web app enumeration against the WSTG checklist: hand off to web-app-pentest.
- API enumeration (endpoints, auth, object IDs): hand off to api-security-testing.
Keep a running inventory: host → open ports → service/version → app/endpoints → auth model.
3. Vulnerability analysis
For each enumerated service, list candidate weaknesses ranked by likelihood × impact. Correlate versions against known advisories; confirm, do not assume. Note which candidates are testable within the RoE and which are not (e.g. no DoS allowed → mark theoretical).
4. Exploitation (within limits)
- Confirm each candidate with the least intrusive proof that demonstrates impact. Prefer a read-only proof (retrieve a benign marker, show the version, trigger a harmless callback) over anything destructive.
- Never run stress/DoS, mass deletion, lateral spread, or exfiltration of real data unless the RoE explicitly permits it — and even then, to the minimum needed.
- Chain findings to show real impact (e.g. SSRF → metadata → credential) only within scope.
- Capture evidence as you go: request/response, command + output, screenshot, timestamp. Mask secrets and PII in captured evidence.
5. Post-exploitation
Only if the RoE allows. Document what the foothold could reach (privilege, data, pivot) to quantify impact — do not expand access beyond what proving impact requires. Leave no persistence; remove any test artifacts (uploaded files, created accounts) and record their removal.
6. Reporting
Hand off report drafting to security-audit-report. Each finding needs: title, severity (CVSS vector), affected asset, reproduction steps, evidence, impact, and remediation.
Evidence discipline
- One directory per target; name files
<host>_<finding>_<step>.<ext>. - Log every command with a timestamp so the test is reproducible and auditable.
- Redact credentials, tokens and PII from evidence before it goes in the report.
- Keep a scope-check note next to each active action: which RoE clause authorized it.
Cleanup
- Remove test accounts, uploaded files, web shells and any changes you made.
- Restore modified data where possible; report anything that cannot be restored.
- Confirm no test traffic is still running (no background scans, no scheduled jobs).
Output contract
## Penetration test report — <engagement> (<window>)
Authorization: <reference>. Scope: <in/out>. Limits: <techniques allowed/denied>.
### Executive summary
<risk in plain language; count by severity; top risks>
### Findings
#### [Critical] <title> — <asset>
CVSS: <vector + score>
Steps to reproduce: <numbered, with the exact requests/commands>
Evidence: <files>
Impact: <what an attacker gains>
Remediation: <fix + reference>
### Methodology, tools, timeline, cleanup confirmationHard rules
- No authorization, or anything ambiguous → stop and ask. Never test out of scope.
- Default to the least intrusive proof. No DoS, destructive actions or real-data exfiltration unless the RoE explicitly allows it.
- Stop immediately and contact the owner if you hit something unexpected (another tenant’s data, a production outage risk, evidence of a prior real breach).
- Never leave persistence or test artifacts behind.
What the zip contains
SKILL.md plus the interface file below. Nothing runs on install.
agents/openai.yaml
Gives the Codex app a display name, a one-line description and a starter prompt for this skill.
interface:
display_name: "Pentest Methodology"
short_description: "Scope, exploit, document, report"
default_prompt: "$pentest-methodology I have signed authorization to test this app — walk the engagement with me"About this skill
Written and maintained by the Codex Skills editors to the same editorial standard as every skill here: a selective description, a real workflow, known pitfalls and a way to verify the work. First published , last updated . MIT licensed. Something wrong or out of date? Tell us.