| name | penetration-test-plan |
| description | Plan a penetration test engagement for a web application, API, or infrastructure target. Produces scope definition, test methodology, rules of engagement, finding classification, and remediation SLAs. |
| argument-hint | ["target system","test type","compliance requirement","timeline"] |
| allowed-tools | Read, Write |
Penetration Test Plan
A penetration test is a controlled, authorized attempt to exploit vulnerabilities in a system. A well-defined plan ensures the test is safe, legally authorized, comprehensive, and produces actionable findings. Poor planning leads to scope creep, accidental outages, legal risk, or a report that cannot be acted on.
Test Types
| Type | Scope | When to use |
|---|
| Black box | No prior knowledge of system | Simulates external attacker; realistic but shallow |
| Gray box | Partial knowledge (user credentials, basic architecture) | Balances realism with coverage; most common |
| White box | Full knowledge (source code, architecture, credentials) | Maximum coverage; pre-production validation |
| Red team | Full adversarial simulation including social engineering | Mature security programs; tests detection capability |
| Bug bounty | Continuous, researcher-driven | Complements periodic pen tests |
OWASP Top 10 Coverage Checklist
Every web app pen test should cover:
Process
- Define the scope — exact systems, IP ranges, domains, APIs in scope and explicitly out of scope.
- Get written authorization — signed Rules of Engagement (ROE) from asset owner and legal.
- Identify test type — black/gray/white box; internal vs external; authenticated vs unauthenticated.
- Set timeline — reconnaissance, scanning, exploitation, reporting phases with dates.
- Define communication protocol — who to contact for critical findings, how to pause if something breaks.
- Establish test environment — production test or staging? Data handling requirements?
- Run the test — reconnaissance, scanning, vulnerability identification, exploitation, post-exploitation.
- Document findings — every finding with CVSS score, reproduction steps, evidence, remediation.
- Classify and triage — Critical/High/Medium/Low with remediation SLAs.
- Produce the report — executive summary + technical findings + remediation roadmap.
Output Format
Rules of Engagement Document
# Penetration Test — Rules of Engagement
**Engagement ID:** PT-[YYYY]-[NNN]
**Client:** [Organization name]
**Tester / Firm:** [Tester name or firm]
**Authorized by:** [Name, title, signature]
**Date:** [Start date] – [End date]
---
## Authorization
[Organization] hereby authorizes [Tester] to perform security testing against the systems defined
in this document for the period specified above. This document constitutes written authorization
as required by applicable computer fraud and unauthorized access laws.
**Asset owner signature:** ___________________ Date: ___________
**Legal approval:** ___________________ Date: ___________
**CISO / Security lead:** ___________________ Date: ___________
---
## Scope
### In Scope
| Target | Type | Environment | Notes |
|--------|------|-------------|-------|
| api.example.com | Web API | Production | All endpoints |
| app.example.com | Web app | Production | Authenticated + unauthenticated |
| 10.0.1.0/24 | Internal network | — | Jump box access provided |
### Explicitly Out of Scope
- Third-party SaaS services (Stripe, Salesforce, Sendgrid)
- DNS infrastructure (managed by registrar)
- Physical security
- Social engineering / phishing
- Denial of Service attacks
- aws.amazon.com (shared infrastructure)
---
## Test Parameters
Gray box — credentials for 3 user roles provided
Business hours only (09:00–17:00 [Timezone]) unless critical finding requires immediate notification
No real PII to be exfiltrated; test with synthetic data only
Not permitted without explicit prior approval for each action
---
[Name] — [phone] — [email]
[Name] — [phone] (24/7 for critical findings)
Within 2 hours of discovery by phone + email
Brief email by 17:00 each test day
Contact primary contact immediately if:
Production service disruption is detected
Real customer data is accessed unexpectedly
Attack infrastructure is detected by client security team
Finding Classification
## Severity Classification (CVSS v3.1 Base Score)
| Severity | CVSS Range | Remediation SLA | Example |
|----------|-----------|-----------------|---------|
| Critical | 9.0–10.0 | 24 hours | RCE without auth, SQLi with data dump |
| High | 7.0–8.9 | 7 days | Auth bypass, IDOR exposing all users |
| Medium | 4.0–6.9 | 30 days | Stored XSS, CSRF on state-changing actions |
| Low | 0.1–3.9 | 90 days | Missing security headers, verbose error messages |
| Informational | N/A | Best effort | Security improvement recommendations |
Finding Template
## Finding #[N]: [Title]
**Severity:** Critical / High / Medium / Low
**CVSS Score:** [X.X] — [Vector string]
**CWE:** [CWE-XXX: Name]
**OWASP:** [A0X: Category]
**Affected component:** [URL / endpoint / system]
### Description
[Clear explanation of the vulnerability — what it is and why it exists]
### Business Impact
[What an attacker can do if this is exploited — data breach, account takeover, service disruption, etc.]
### Steps to Reproduce
1. Navigate to [URL]
2. Submit the following payload in the [field] parameter:
[exact payload]
3. Observe [response / behavior]
### Evidence
[Screenshot or response snippet]
HTTP/1.1 200 OK
Content-Type: application/json
{"user_id": 1, "email": "admin@example.com", "role": "admin", ...}
### Root Cause
[Technical explanation of why this vulnerability exists]
### Remediation
[Specific, actionable fix]
**Short-term (mitigate immediately):**
- [Disable feature / add WAF rule / rotate credential]
**Long-term (fix properly):**
```python
# Vulnerable code
user = User.query.filter_by(id=request.args.get('id')).first()
# Fixed code — verify ownership before returning data
user = User.query.filter_by(
id=request.args.get('id'),
owner_id=current_user.id # enforce access control
).first_or_404()
References
### Executive Summary Template
```markdown
# Penetration Test — Executive Summary
**Engagement:** [Name] **Period:** [Dates] **Tester:** [Name/Firm]
## Risk Overview
| Severity | Count | Remediated during test |
|----------|-------|----------------------|
| Critical | 1 | 0 |
| High | 4 | 1 |
| Medium | 8 | 3 |
| Low | 12 | 0 |
| Informational | 6 | — |
**Overall risk rating:** HIGH
## Key Findings
1. **[Critical] SQL Injection in /api/search** — allows unauthenticated database dump of all user records. Immediate remediation required.
2. **[High] Broken Object Level Authorization in /api/orders** — authenticated users can access any order by ID enumeration.
3. **[High] Session tokens not invalidated on logout** — stolen tokens remain valid indefinitely.
## Positive Findings
- HTTPS enforced on all endpoints; HSTS configured correctly
- Password hashing uses bcrypt with appropriate work factor
- Rate limiting present on authentication endpoints
## Remediation Priorities
[Link to full technical report with remediation roadmap]
## Attestation
This report represents a point-in-time assessment. Remediation of findings does not guarantee
the absence of other vulnerabilities. We recommend scheduling a re-test after remediation of
Critical and High findings.
Test Methodology Phases
Phase 1 — Reconnaissance (Days 1–2)
- Passive: OSINT, DNS enum, certificate transparency, job postings
- Active: Port scan, service fingerprinting, web crawling, tech stack ID
Phase 2 — Scanning (Days 2–3)
- Automated: Burp Suite Pro, OWASP ZAP, Nikto, Nmap
- Manual: Review scan results; eliminate false positives
Phase 3 — Exploitation (Days 3–7)
- Attempt to exploit identified vulnerabilities
- Chain vulnerabilities where possible (e.g., SSRF → internal service access)
- Document reproduction steps for every confirmed finding
Phase 4 — Post-Exploitation (Days 6–7)
- Assess lateral movement from compromised position
- Data access: what can be reached from compromised account?
- Privilege escalation opportunities
Phase 5 — Reporting (Days 7–10)
- Document all findings with CVSS, steps to reproduce, evidence
- Executive summary + technical report
- Remediation roadmap
- Debrief call with client team
Testing Tools
Burp Suite
Configure proxy
Intercept/modify requests
Scanner for automated testing
OWASP ZAP
zap-cli quick-scan https://example.com
SQLMap
sqlmap -u "https://site.com?id=1" --dump
Nmap
nmap -sV -sC example.com
Severity Scoring (CVSS)
Critical (9.0-10.0): RCE, Auth bypass, Full DB access
High (7.0-8.9): Stored XSS, Privilege escalation
Medium (4.0-6.9): Reflected XSS, CSRF
Low (0.1-3.9): Info disclosure, Missing headers
Anti-Patterns to Avoid
| Anti-pattern | Risk | Fix |
|---|
| No written authorization | Legal liability for tester and client | ROE signed before first packet sent |
| Vague scope | Test too narrow; important targets missed | Enumerate exact IPs, domains, endpoints |
| Testing production without safeguards | Accidental outage or data exposure | Define pause triggers; test in staging first |
| No critical finding escalation path | Critical vuln sits in draft report for days | Phone escalation within 2 hours of critical discovery |
| Automated-only test | Many vulnerabilities require human logic | Manual testing for all business logic flows |
| No retesting | Fixes are assumed but not verified | Schedule retest for Critical and High findings |
Rules
- Written authorization before any testing — verbal permission is not protection against computer fraud charges.
- Explicit out-of-scope list — ambiguity always gets interpreted as in-scope during an active test.
- Critical findings get a phone call — do not wait for the report; notify within 2 hours.
- Never exfiltrate real customer data — use synthetic data; document that you could have accessed real data.
- Pause before destructive actions — confirm with client before dropping tables, crashing services, or overwriting data.
- Reproduce every finding before reporting it — unconfirmed vulnerabilities waste client remediation effort.
- CVSS score every finding — subjective severity labels cause argument; CVSS provides a consistent framework.
- Include remediation code — a finding without a fix is just a problem report; show the client how to fix it.
- Retest after remediation — findings closed without retest have unknown actual status.
- Point-in-time caveat in every report — a clean pen test does not mean a secure system.
