Pentest Methodology

Hacking isn’t throwing tools at random: it’s an orderly process that turns “I know nothing about this target” into “I understand how to compromise it and I’ve proven it.” A methodology gives you a map so you leave no surface uncovered, don’t repeat work, and can explain every finding. Whether it’s a web pentest, an AD audit, or a CTF: the phases are the same, only the tools change.

flowchart LR
    A[Recon] --> B[Enumeration]
    B --> C[Exploitation]
    C --> D[Post-exploitation]
    D --> E[Reporting]
    D -.->|iterate| B

The phases

The classic cycle, from the outside in:

1. Scoping and rules — what you may touch, what you may not, when, and with what authorization. Without this in writing, you don’t start.
2. Reconnaissance — gather target information. Passive (without touching it: OSINT, DNS, certificates) and active (interacting: port scanning, fingerprinting).
3. Enumeration — dig into each found service: versions, users, directories, configurations. This is where the vector is decided.
4. Exploitation — gain access by leveraging a vulnerability or misconfiguration.
5. Post-exploitation — once inside: escalate privileges, move laterally, persist, harvest data. Demonstrates the real impact.
6. Reporting — document findings, impact, reproduction steps, and remediation. It’s the deliverable that truly matters to the client.

The process is iterative: each new access restarts recon/enum from the new position (an internal host, a domain account).

Reference frameworks

Don’t reinvent the wheel; lean on established methodologies:

• PTES (Penetration Testing Execution Standard) — the 7 phases of a professional pentest end to end.
• OWASP WSTG — web testing guide, case by case (the reference for the Web area).
• OSSTMM — security testing methodology manual, highly measurable.
• MITRE ATT&CK — matrix of real adversary tactics and techniques; ideal to map post-exploitation and for red team.
• Cyber Kill Chain (Lockheed Martin) — the cycle of an attack from the attacker’s perspective.

Scoping and rules of engagement (the legal part)

Before touching anything:

• Written authorization with explicit scope (domains, IPs, ranges), time window, and emergency contacts.
• What is out of scope (critical production, DoS, social engineering if not agreed).
• Rules on sensitive data: what you may exfiltrate to prove impact and what you may not.

Hacking without authorization is a crime. Everything in this wiki is for your own environments or with explicit written permission.

Document as you work

• Take notes in the moment, not at the end: command, relevant output, timestamp, screenshot.
• Tools: a notes vault (Obsidian/CherryTree), organized screenshots, and a command log.
• Keep reproducible evidence: the client’s remediation depends on being able to reproduce the flaw.

Pentest types (box)

The prior knowledge the client gives you defines the test type and, with it, how much time you spend on recon:

Black-box   zero information -> you start from OSINT and recon like an external attacker
Grey-box    partial credentials/access (the most common and cost-effective)
White-box   full access: code, architecture, credentials -> maximum coverage

And by the engagement’s goal:

Pentest     find and demonstrate the MOST vulnerabilities within a given scope and time
Red team    emulate a real adversary against specific OBJECTIVES (stealth, no "noise")
Purple team red + blue together: run TTPs and validate detection live (see def-hunting)

An example flow (from outside to root)

scoping      -> written authorization: *.corp.local + 10.0.0.0/8, nightly window
recon        -> subdomains (subfinder), ASN/ranges (recon-asn), employee OSINT
enum         -> nmap -p-; a web portal with a login and an open SMB
exploitation -> SQLi in the portal -> a domain user's credentials
post         -> those creds work on the network (NetExec) -> BloodHound -> path to Domain Admin
             -> kerberoasting + an abusable ACL -> DA -> secretsdump of the DC
report       -> findings prioritized by impact, reproduction steps, and remediation

Each arrow restarts the recon/enum cycle from the new position: that’s what it means for the methodology to be iterative.

Prioritize and communicate risk

A pentest’s value isn’t the list of bugs but prioritizing them by real impact and communicating them:

• CVSS as a common severity language, but explaining the vector and context (a 9.8 internal, unexposed matters less than an exposed 7.5).
• Translate each finding to business risk (“access to all customers’ data”), not just the technicality.
• Actionable remediation: what to change, not “improve security”. Links to grc-riesgos and def-vulnmgmt.

Mastery checklist

• I can list the 6 phases and what each does
• I understand passive vs active recon and why order matters
• I can explain why the methodology is iterative
• I know PTES, OWASP WSTG, OSSTMM, and MITRE ATT&CK and what each is for
• I know what an authorization/scope must include before starting
• I document commands and evidence as I work, not at the end
• I understand the reporting phase is the key deliverable

References

• PTES — Penetration Testing Execution Standard
• OWASP WSTG — web security testing guide
• MITRE ATT&CK — adversary tactics and techniques matrix
• OSSTMM — security testing methodology