Pentest methodology — Security Operations & Defense

Plan a scoped, authorised penetration test in your own lab, from rules of engagement to a defender-focused report.

Why it matters

A penetration test (pentest) is an authorised, simulated attack that shows how far a real attacker could get. Defenders who understand pentest methodology write better detections, read pentest reports critically and plan useful tests for their own organisation. And the single most important part of the methodology is not a tool: it is authorisation and scope.

Legal first, always

Testing a system without the owner's explicit, written permission is illegal in most countries, under laws such as the US Computer Fraud and Abuse Act and the UK Computer Misuse Act, even if you mean well and even if you find nothing. Permission from someone who does not own the system (a friend who works there, a user of the service) does not count.

For practice, you have three safe options:

Your own lab: virtual machines you own on an isolated network (deliberately vulnerable targets such as Metasploitable, DVWA or OWASP Juice Shop).
Platforms that authorise you: TryHackMe, Hack The Box, PortSwigger Web Security Academy and similar, within their rules.
Bug bounty programmes: only the assets listed in the programme's published scope, following its rules exactly.

The phases

Several published methodologies describe a pentest, including the Penetration Testing Execution Standard (PTES), NIST SP 800-115 and the OWASP Web Security Testing Guide. They share the same core phases:

Phase	What happens	Output
1. Pre-engagement	Agree scope, goals, rules of engagement, timing, contacts and written authorisation	Signed authorisation and scope document
2. Reconnaissance	Gather information: public sources (passive), then scanning in scope (active)	List of hosts, services, users, technologies
3. Threat modelling and vulnerability analysis	Decide which weaknesses are realistic and valuable to test	Prioritised list of candidate vulnerabilities
4. Exploitation	Safely attempt to use the vulnerabilities to gain access	Proof of access, with evidence
5. Post-exploitation	Within scope, see what access allows: privilege escalation, lateral movement, reaching sensitive data	Impact demonstrated
6. Reporting	Explain findings, risk, evidence and fixes for both executives and engineers	Report and debrief
7. Cleanup and retest	Remove test accounts, tools and files; retest fixes later	Clean environment, verified fixes

Rules of engagement

The rules of engagement (RoE) turn "test our stuff" into something safe and legal. A useful RoE answers:

In scope: exact IP ranges, domains, applications and accounts. Anything not listed is out of scope.
Out of scope: for example production databases, third-party services you do not own (the cloud provider's own infrastructure, a payment processor), and physical or social engineering tests unless explicitly included.
Allowed and forbidden techniques: no denial of service, no destructive actions, no accessing real customer data beyond proof.
Timing: testing windows and blackout periods.
Contacts and stop conditions: who to call if something breaks or you find evidence of a real attacker, and a phrase that stops testing immediately.
Data handling: how evidence and any captured credentials are stored and destroyed.

Cloud providers publish their own pentest policies for customers; read them before testing anything you host there.

Worked example: a scoped home-lab test plan

Engagement: Home lab practice test
Owner/authoriser: Me (I own the host machine and all VMs)
Date/time window: 2026-10-24, 10:00-14:00 local

In scope:
  - 192.168.56.101 (Metasploitable 2 VM, host-only network)
  - 192.168.56.102 (Ubuntu VM running OWASP Juice Shop on port 3000)
Out of scope:
  - 192.168.56.1 (my host machine)
  - my home network, router, other devices, and the internet
Rules:
  - Host-only network; no bridged adapters during testing
  - No denial-of-service tests
  - Snapshot both VMs before starting; restore afterwards
Goals:
  1. Enumerate services on both VMs
  2. Gain a shell on .101 via one known vulnerability and document it
  3. Find one OWASP Top 10 issue in Juice Shop
Defender view: run the Suricata sensor from lesson 1.3 and note which steps alerted
Report: findings, evidence, ATT&CK technique, fix, and which steps were NOT detected

The last two lines are what makes this a defender's exercise. For each step you take as the attacker, check what the logs and IDS saw. Steps that left no trace are detection gaps, the same lesson as the previous ATT&CK mapping.

Common reconnaissance tools (in scope only)

nmap for host and service discovery: nmap -sV 192.168.56.101 lists open ports and service versions.
Web proxies such as OWASP ZAP or Burp Suite Community for web testing.
Metasploit Framework for exploiting known vulnerabilities in lab targets.

Learning these tools on TryHackMe's free beginner rooms is a good path, because the targets are provided and authorised.

A good report

Executive summary in plain language: what was tested, what an attacker could achieve, the top risks.
Findings, each with severity (often CVSS), affected asset, evidence (screenshots, requests), business impact, and a specific fix.
Attack narrative: how findings chained together.
What went well: controls that stopped or detected the tester.

Common mistakes

Starting without written authorisation. No document, no test.
Drifting out of scope. Finding a new IP during recon does not make it in scope; ask the owner.
Running exploits you do not understand against anything that matters. Some crash services or corrupt data.
A report full of scanner output. Value comes from validated, prioritised findings and clear fixes.

Quick recap

Pentests need explicit written authorisation and a defined scope; practise only in your own lab or on platforms that authorise you.
Phases: pre-engagement, reconnaissance, vulnerability analysis, exploitation, post-exploitation, reporting, cleanup and retest.
Rules of engagement define scope, techniques, timing, contacts and stop conditions.
For defenders, the key output is which attack steps were not detected.

Try it

Open the Do tab to write and run a scoped test plan in your own lab.