Security Testing

Penetration Testing Methodology: From Scoping to Report

HelpMeTest

HelpMeTest

— 6 min read
Penetration Testing Methodology: From Scoping to Report

Penetration testing (pentesting) is authorized, controlled hacking to identify exploitable vulnerabilities before attackers do. A structured methodology prevents scope creep, legal problems, and missed findings. The phases: scoping (what's in scope, rules of engagement), reconnaissance (gather information), scanning (enumerate attack surface), exploitation (verify vulnerabilities), post-exploitation (assess impact), and reporting (communicate findings and remediation). Pentesting is not the same as a vulnerability scan—a scanner tells you what might be vulnerable; a pentester tells you what's actually exploitable and what the real business impact is.

Key Takeaways

Scope definition is everything. Testing systems outside agreed scope can be illegal. Get written authorization before touching anything. Define explicitly what IP ranges, domains, and applications are in scope.

Reconnaissance is the most valuable phase. The information gathered before touching a single system shapes the entire test. Weak recon leads to missed attack paths.

Distinguish confirmed exploitation from theoretical vulnerabilities. A scanner finding is a lead. A pentest finding is a confirmed exploit with proof—screenshot, request/response, or extracted data (within scope).

The report is the deliverable, not the hacking. A pentest that finds 20 vulnerabilities but delivers an unactionable report failed. Every finding needs: description, CVSS score, reproduction steps, evidence, and specific remediation guidance.

Remediation verification is a separate engagement. After you patch, schedule a retest. Fixes often don't address the root cause. Retest confirms the specific vulnerability is closed, not just that the scan output changed.

Engagement Types

Type Attacker Knowledge Typical Use
Black Box No internal knowledge Simulates external attacker
Grey Box Some knowledge (user credentials, API docs) Most common; balances depth and efficiency
White Box Full knowledge (source code, architecture) Most thorough; used for critical systems
Scope What's Tested
External Network Internet-facing systems, perimeter
Internal Network What an insider or post-breach attacker can access
Web Application Specific application, authenticated and unauthenticated
Mobile Application iOS/Android app + its API backend
API REST/GraphQL endpoints
Social Engineering Phishing, vishing, pretexting
Physical Building access, hardware security

Phase 1: Scoping and Rules of Engagement

Before any testing begins, define:

In-scope systems:

IP ranges: 203.0.113.0/24, 198.51.100.15
Domains: app.example.com, api.example.com
Applications: Customer portal, Admin dashboard, REST API

Out-of-scope systems:

IP ranges: 203.0.113.100-120 (third-party hosted systems)
Domains: partner.example.com (not owned by client)
Staging environment: staging.example.com (client requested exclusion)

Rules of Engagement:

  • Testing hours: Weekdays 09:00–17:00 local time (or 24/7 with production safeguards)
  • Destructive testing: Yes/No (DDoS, data deletion)
  • Social engineering: In/Out of scope
  • Emergency contact: [Name, phone] to call if critical finding or testing causes disruption
  • Communication channel: [Encrypted messaging platform]

Get it in writing. A signed Statement of Work (SoW) or Rules of Engagement document protects both parties legally.

Phase 2: Reconnaissance

Gather maximum information about the target without triggering alerts.

Passive Reconnaissance (No direct target interaction)

# WHOIS information
whois example.com

# DNS enumeration
dig example.com ANY
dnsenum example.com

# Certificate transparency logs (find subdomains)
curl "https://crt.sh/?q=%.example.com&output=json" | jq '.[].name_value' | sort -u

# Google dorking
site:example.com filetype:pdf
site:example.com inurl:admin
"example.com" ext:sql OR ext:log

# Shodan (internet-facing services)
shodan search "org:Example Corp"

# LinkedIn (employees, tech stack clues)
# GitHub (leaked credentials, internal code)
# Job postings (reveals tech stack: "experience with AWS, Node.js, PostgreSQL...")

Active Reconnaissance (Direct interaction with target)

# DNS brute force
gobuster dns -d example.com -w /usr/share/wordlists/subdomains.txt

# Web crawling
gospider -s https://example.com -d 3

# Technology fingerprinting
whatweb https://example.com
wappalyzer https://example.com

Phase 3: Scanning and Enumeration

Map the attack surface in detail.

Network Scanning

# Host discovery
nmap -sn 203.0.113.0/24 -oN hosts.txt

# Port scan (top 1000 ports)
nmap -sV -sC -oN scan.txt 203.0.113.0/24

# Full port scan with service detection
nmap -p- -sV -T4 --open target.example.com

# UDP scan (often missed)
nmap -sU --top-ports 100 target.example.com

Web Application Enumeration

# Directory and file enumeration
gobuster dir -u https://app.example.com -w /usr/share/seclists/Discovery/Web-Content/common.txt
feroxbuster -u https://app.example.com

# API endpoint discovery
ffuf -w /usr/share/seclists/Discovery/Web-Content/api-endpoints.txt \
     -u https://app.example.com/api/FUZZ \
     -mc 200,201,204,301,302

# Parameter discovery
arjun -u https://app.example.com/search

# JavaScript analysis (find hidden endpoints, tokens)
linkfinder -i https://app.example.com -o results.html

Automated Vulnerability Scanning

# Web application scanner
nikto -h https://app.example.com -o nikto-results.html

# OWASP ZAP automated scan
zap-cli quick-scan --self-contained --start-options "-config api.disablekey=true" \
  -r zap-report.html https://app.example.com

# SSL/TLS configuration
testssl.sh https://app.example.com

Phase 4: Exploitation

Verify that discovered vulnerabilities are actually exploitable.

Document everything. Every request, every response, every tool command. The difference between a finding and a claim is evidence.

Web Application Testing

Authentication testing:

# Test for username enumeration
POST /login HTTP/1.1
{"email": "valid@example.com", "password": "wrong"}
→ "Invalid password"  ← Different error = username enumeration vulnerability

{"email": "nonexistent@example.com", "password": "wrong"}
→ "Invalid email"  ← Confirms username enumeration

Authorization testing (IDOR):

# As user A (ID: 12345), try to access user B's data (ID: 12346)
GET /api/users/12346/profile HTTP/1.1
Authorization: Bearer <user_A_token>
→ If 200 OK with user B's data: IDOR confirmed

SQL Injection verification:

# Time-based blind SQLi
GET /api/search?q=test' AND SLEEP(5)-- HTTP/1.1
→ If response takes ~5 seconds: SQL injection confirmed

# Error-based SQLi
GET /api/products?id=1' AND EXTRACTVALUE(1,CONCAT(0x7e,@@version))-- HTTP/1.1
→ MySQL version in error message: SQL injection + DB version confirmed

Capturing Evidence

For each confirmed finding, capture:

  1. HTTP request (Burp Suite → Copy as curl)
  2. HTTP response (full body)
  3. Screenshot of impact (data extracted, unauthorized access granted)
  4. CVSS vector string you calculated

Phase 5: Post-Exploitation (Impact Assessment)

Post-exploitation demonstrates real business impact, moving beyond "we found a vulnerability" to "here's what an attacker could do with it."

Lateral movement: From an exploited web server, what internal systems are reachable?

# From compromised server
ip route  # What networks can we reach?
nmap -sn 10.0.0.0/24  # What hosts exist internally?

Sensitive data access: What data can be reached through this vulnerability?

  • Can an attacker read customer PII?
  • Can they access payment card data?
  • Can they read credentials from the database?

Persistence (if in scope): Could an attacker maintain access after you remediate?

Document impact, not just technique. "We got a shell on the web server" is a technique. "From the web server, we accessed the customer database containing 50,000 records including names, emails, and hashed passwords" is business impact.

Phase 6: Reporting

The report is the product. All findings must be actionable.

Report Structure

Executive Summary
├── Engagement overview
├── Key findings (top 5 with severity)
├── Risk posture summary
└── Remediation priorities

Technical Findings
├── Finding 1: [Title]
│   ├── Severity: Critical/High/Medium/Low
│   ├── CVSS: 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H)
│   ├── Description: What the vulnerability is
│   ├── Evidence: Request/response, screenshot
│   ├── Impact: What an attacker could do
│   ├── Reproduction steps: Step-by-step to reproduce
│   └── Remediation: Specific fix guidance
│
├── Finding 2: ...
└── ...

Appendices
├── Scope and timeline
├── Tools used
├── Testing methodology reference
└── Remediation tracking template

Writing Good Finding Descriptions

Bad:

Vulnerability: SQL Injection found in search functionality.
Recommendation: Use parameterized queries.

Good:

Vulnerability: Unauthenticated SQL Injection in Product Search Endpoint

The /api/products/search endpoint is vulnerable to time-based blind SQL injection 
via the `q` parameter. An unauthenticated attacker can extract data from the 
underlying MySQL database by submitting crafted payloads.

Evidence:
Request:
  GET /api/products/search?q=test' AND SLEEP(5)-- HTTP/1.1
  Host: app.example.com
  
Response received after 5.12 seconds (confirming injection).

Using sqlmap with the confirmed injection point, we extracted:
  - Database version: MySQL 8.0.28
  - Database name: production_db
  - Table: users (50,847 rows with columns: id, email, password_hash, created_at)

Impact: Full database extraction, including all customer records and hashed passwords.

Remediation:
1. Immediate: Implement parameterized queries (prepared statements) for all database 
   queries that accept user input. Never concatenate user input into SQL strings.
2. Short-term: Deploy a WAF rule to block obvious SQLi patterns while code changes 
   are developed and tested.
3. Long-term: Implement an ORM with query parameterization enforced by default.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — Score: 9.1 Critical

Remediation and Retest

After findings are addressed, schedule a retest:

  1. Retest each finding individually
  2. Verify the specific vulnerability is closed (not just obscured)
  3. Test for common "fix byp"—partial patches that look fixed but aren't
  4. Document retest results in a closure report

Summary

A structured penetration testing methodology ensures:

  • Legal protection: Written authorization and scope documentation
  • Comprehensive coverage: Systematic phases don't miss attack paths
  • Confirmed findings: Only real exploits in the report, not theoretical vulnerabilities
  • Actionable output: Findings with specific remediation guidance and business impact
  • Verified remediation: Retest confirms fixes, not just scan output changes

The output of a pentest is organizational risk reduction. A technically impressive engagement that produces an unreadable report reduces risk by zero.

Read more

Start now free