Penetration Testing Methodology and Reporting: From Scoping to Executive Summary

Tools & Defense
2025.11.25
Time it takes to read this article 6 minutes.

Disclaimer: This article is for education and authorized testing only. Run these techniques exclusively against systems you own or have explicit, written permission to test (a signed Rules of Engagement / Statement of Work). Unauthorized access to computer systems is illegal in most jurisdictions (e.g. the US CFAA, UK Computer Misuse Act). Stay in scope.

Introduction / Overview

A penetration test is only as valuable as the report it produces. You can chain three CVEs into a domain-admin compromise, but if the finding isn't reproducible, severity-scored, and written so a manager can act on it, the engagement failed. This article walks through a repeatable methodology based on PTES (Penetration Testing Execution Standard), then focuses on the deliverable: scoping, evidence collection, CVSS scoring, and the executive summary.

By the end you'll have a workflow you can apply to any external, internal, or web engagement, plus concrete command examples for capturing artifacts that survive a client dispute.

How It Works / Background: The PTES Phases

PTES defines seven phases. They map cleanly onto how a real engagement runs:

  1. Pre-engagement Interactions — scoping, ROE, authorization, emergency contacts.
  2. Intelligence Gathering — OSINT, passive and active recon.
  3. Threat Modeling — what an attacker actually wants (data, business processes).
  4. Vulnerability Analysis — finding flaws (manual + scanners).
  5. Exploitation — gaining access.
  6. Post-Exploitation — pivoting, persistence, looting, measuring impact.
  7. Reporting — the deliverable.

Most novices over-invest in phases 5 and 6 and neglect 1 and 7. The first phase protects you legally; the last phase is the only thing the client keeps.

Scoping: getting the boundaries right

Scoping is contractual, not technical. Before any packet leaves your interface, the Rules of Engagement must nail down:

  • In-scope targets — exact CIDR ranges, FQDNs, URLs, API endpoints, cloud account IDs.
  • Excluded systems — production DBs, third-party SaaS you're not allowed to touch.
  • Allowed techniques — is social engineering permitted? DoS testing? Password spraying (and lockout thresholds)?
  • Time windows — business hours vs. off-hours, blackout dates.
  • Authorization — a signed document naming who can authorize the test, plus a "get out of jail" letter.

A common scoping bug: a /24 is provided but the client only owns 12 of the 256 hosts (cloud tenant neighbors). Confirm ownership before scanning.

Prerequisites / Lab Setup

To follow along, build a small lab. Use Kali Linux as the attacker and a deliberately vulnerable target.

# Spin up an intentionally vulnerable web app for safe practice
docker run --rm -d -p 8080:80 vulnerables/web-dvwa

# Core tooling on Kali
sudo apt update && sudo apt install -y nmap nuclei feroxbuster

# Confirm versions so they go in your report's methodology appendix
nmap --version
nuclei -version
Bash

Attack Walkthrough / PoC

A walkthrough is worthless to a reader unless every step is reproducible. The discipline here is timestamp + command + output, captured automatically.

Step 0: Start an evidence log

Wrap your whole session so nothing is lost. script with --timing records keystrokes and a replayable timeline.

# Record terminal session + timing for evidence
script --timing=ENGAGEMENT-2025-11-25.time ENGAGEMENT-2025-11-25.log
# ... do all your work inside this shell ...
# Replay later for the report:
scriptreplay --timing=ENGAGEMENT-2025-11-25.time ENGAGEMENT-2025-11-25.log
Bash

Step 1: Discovery and service enumeration

# Host discovery, then full TCP scan with service/version detection
nmap -sn 10.10.10.0/24 -oA scope-sweep
sudo nmap -sS -sV -sC -p- --min-rate 2000 10.10.10.50 -oA target50
Bash

Always use -oA (outputs .nmap, .gnmap, .xml). The XML feeds your reporting tooling; the timestamped files are evidence.

Step 2: Web content and vulnerability analysis

# Directory/content discovery
feroxbuster -u http://10.10.10.50 -w /usr/share/seclists/Discovery/Web-Content/raac.txt

# Template-based vuln scan (note the templates version for repeatability)
nuclei -u http://10.10.10.50 -severity medium,high,critical -o nuclei-target50.txt
Bash

Scanner output is a lead, never a finding. Manually validate every reported vuln before it enters the report — false positives destroy credibility faster than missed findings.

Step 3: Exploitation and impact

Say you confirm SQL injection. Capture the proof: the request, the response, and the data category exposed (never exfiltrate real PII — screenshot a row count or a redacted sample). For something like a domain attack, demonstrate impact without burning the client's environment. Related deep-dives:

Step 4: Score it with CVSS

Use CVSS v3.1 (or v4.0 if the client mandates it) and always publish the vector string, not just the number — the vector is auditable, the number alone is not.

Example for an unauthenticated, network-reachable RCE:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H  →  Base Score 9.8 (Critical)
Plaintext

Break down the metrics so the reader trusts the score:

  • AV:N (Attack Vector: Network) — exploitable across the network.
  • AC:L (Attack Complexity: Low) — no special conditions.
  • PR:N (Privileges Required: None) — pre-auth.
  • UI:N (User Interaction: None) — no victim action needed.
  • C:H/I:H/A:H — full confidentiality, integrity, availability impact.

Crucially, adjust Environmental metrics to the client's context. An RCE on an internet-facing host and the same RCE on an isolated lab segment should not carry the same risk in their report. Tools: FIRST's official CVSS calculator.

Mermaid Diagram: Engagement and Reporting Flow

Penetration Testing Methodology and Reporting: From Scoping to Executive Summary diagram 1

The diagram shows scoping flowing into recon, a validation loop that gates exploitation, and every confirmed finding feeding evidence and CVSS scoring into the final report and retest.

Structuring the report

A solid report has two halves serving two audiences:

  • Executive Summary (1-2 pages, no jargon): business risk, an overall posture rating, a count of findings by severity, and 3-5 prioritized recommendations. A CISO should grasp the risk in 90 seconds. Avoid tool names and CVEs here — talk in terms of "an unauthenticated attacker could access customer records."
  • Technical Findings (the bulk): one entry per finding with Title, Severity + CVSS vector, Affected Assets, Description, Reproduction Steps, Evidence (screenshots/logs), Impact, and Remediation. Make remediation specific and testable.

Detection & Defense (Blue Team)

A pentest report is a blue-team gift. The defensive value lives in remediation quality and the client's ability to detect the activity you performed.

1. Detect the recon and scanning you ran. Aggressive nmap -p- and feroxbuster runs are noisy. Defenders should alert on:

# Example Suricata/Snort-style logic: many distinct ports from one source quickly
alert tcp any any -> $HOME_NET any (msg:"Possible TCP port scan"; \
  flow:stateless; flags:S; threshold:type both, track by_src, count 30, seconds 10; \
  sid:1000001; rev:1;)
Plaintext

Web fuzzing shows up as a flood of 404s from one IP — a trivial WAF/SIEM correlation rule (e.g. >50 404s in 60s per source) catches it.

2. Map findings to MITRE ATT&CK. Tagging each finding with a technique ID (e.g. T1110 for the brute-force/spraying, T1190 for exploiting public-facing apps) lets the blue team check their detection coverage against a known framework rather than ad-hoc fixes.

3. Remediation guidance that actually closes gaps:

  • Patch and reduce attack surface — the CVSS-Critical pre-auth RCE gets fixed first; everything else is prioritized by environmental score.
  • Harden authentication — enforce MFA, set sane account-lockout thresholds, and monitor for spraying (Windows Event ID 4625 failed logons across many accounts).
# Detect spraying: many distinct target accounts failing from few sources
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5000 |
  Group-Object { $_.Properties[5].Value } |
  Where-Object Count -gt 10 |
  Sort-Object Count -Descending
PowerShell
  • Egress filtering and logging — many post-exploitation steps (C2, exfil) are stopped or surfaced by strict outbound rules and full DNS/proxy logging.

4. Validate the fix. A finding isn't closed until a retest proves it. Build retesting into the SOW so "Remediated" in the report is evidence-backed, not a checkbox.

Conclusion

Methodology is what separates a penetration test from random exploitation. PTES gives you a defensible structure; rigorous scoping keeps you legal; disciplined evidence capture makes findings reproducible; CVSS vectors make severity auditable; and a sharp executive summary is what turns your work into funded remediation. The technical chops get you the shell — the reporting gets the vulnerability fixed.

References

Comments

Copied title and URL