Security · Topic 11 of 23 · Part II — Catalog of testing methodologies

Penetration testing (as methodology)

A tester actively attempts to compromise a defined target — demonstrating exploitability and building attack chains that a scanner cannot see.

Syllabus: § Testing Methodologies and Tools of the Trade (2, 4) → Penetration testing

Topic 11 · Pentest methodology

More than scanning — more than "hacking with permission"

By the end of this topic you can:

Define penetration testing precisely and distinguish it from vulnerability scanning, red teaming, and manual review.
Describe the standard phases of a pentest engagement and what each phase produces.
Choose between pentest types given a client context.
Explain what a pentest can and cannot reliably tell the client.
Place the Part III lab practicum within the broader methodology.

What pentesting is

A time-bounded, scope-bounded, authorized attempt to exercise the security of a defined target by performing the actions an attacker would perform — identifying vulnerabilities, demonstrating their exploitability, and producing actionable findings.

Exploitation Beyond identifying — the tester demonstrates. The scanner says "vulnerable"; the pentester proves it.

Chaining Finding A is medium; chained with B the impact is critical. Scanners report in isolation; pentests build paths.

Demonstrable impact Not "they could read this file" — "they read it; here is the screenshot."

What pentesting is not

It is not …	Because …
Vulnerability scanning	Scanning identifies; pentesting exploits and chains. A scan is one input, not the engagement.
Red teaming	Red team simulates a goal-driven adversary against the whole org, including detection & response, often covertly. Pentest is more bounded.
A complete security assessment	Scope is always bounded. A pentest of the web app says nothing about the internal Active Directory.
Proof of security	"We found nothing exploitable within scope, in the time we had, with the skills we brought." That is all.
"Hacking with permission"	The discipline is phases, evidence standards, and reporting expectations — most of which have nothing to do with the attack itself.

The seven PTES phases

1Pre-engagement — scope, contract, authorization, rules of engagement, schedule, deliverable definition

2Intelligence gathering — OSINT, passive discovery, attack-surface mapping

3Threat modeling — what does an attacker want? what paths exist? what controls would they bypass?

4Vulnerability analysis — active/passive identification: scanning, manual review, service probing

5Exploitation — confirming and using identified weaknesses

6Post-exploitation — privilege escalation, lateral movement, data access; the impact-demonstration phase

7Reporting — the deliverable; everything before this exists to produce it

Most under-invested Phase 7 — Reporting. It is judged on whether the client can act on it.

Phases overlap in practice: post-exploitation reveals new targets; reporting starts in parallel with exploitation.

Types of pentest by scope and access

By information level

Black box — no prior knowledge
Grey box — partial knowledge (BSI axes, Topic 04)
White box — full access to code and config

By network position

External — from the public internet
Internal — from inside the organization's network
Assumed breach — starts from a low-privileged foothold

By target type

Network / infrastructure
Web application (Topic 17)
API (REST / GraphQL / gRPC)
Mobile (iOS / Android)
Wireless (Wi-Fi)
Cloud & cloud configuration
Active Directory / identity
Physical access controls

A typical commercial engagement combines two or three, e.g. "external web app + external infrastructure."

Methodology references for pentesting

Reference	Best used for
PTES	Engagement lifecycle and high-level technique guidance
OSSTMM 3	Measurement-oriented; repeatability and comparability
NIST SP 800-115	Accessible US-federal reference; widely cited in compliance contexts
OWASP WSTG	Web applications — the dominant test-case reference
BSI Studie	Classification axes; German-speaking client context

In a real report introduction "In accordance with PTES, with web-app portions following OWASP WSTG, classified per BSI axes as …" — that sentence is the methodology's professional footprint.

What a pentest can — and cannot — tell the client

Pentest CAN tell the client

That a specific vulnerability is exploitable in their environment, not just present
That a chain of weaknesses produces a specific impact
That a particular control (WAF, MFA, monitoring) is or is not holding
That a specific attacker capability reaches a particular asset

Pentest CANNOT reliably tell the client

That they are "secure" — absence of findings is not proof
What an attacker with 0-days or insider access would do
Anything about systems outside scope
How detection and response would perform against a real sustained attack
What the same systems look like in a month

Calibrating these expectations belongs in the pre-engagement conversation — and in the report's framing section.

How pentesting relates to the other methodologies

Scanning feeds pentest. Most pentests start with scanner output as one input; pentest confirms and exploits what scanning identifies.
Manual review complements pentest. Findings the tester cannot exploit may still be visible in code; combined assessments are common.
OSINT precedes pentest. Especially for external scope — attack surface is mapped before active testing begins.
Social engineering is a parallel methodology. Some engagements combine pentest + SE; many do not, because SE carries its own authorization and ethical requirements.
Red team subsumes pentest. Red team adds adversary simulation, opsec, and full kill-chain — pentest techniques are a subset.
Blue team is the counterparty. Open (blue knows testing is in progress) vs. closed (only management knows) changes what the engagement can measure.

The reporting deliverable

Executive summary — what was tested, what was found, business impact
Scope & methodology — targets, time, exclusions, methodology citation
Findings — each with title, severity, description, evidence, impact, remediation, references

Attack narrative — how an attacker would chain findings end-to-end; often more useful to non-technical readers than the isolated finding list
Recommendations — prioritized, with effort estimates where possible
Appendices — tools used, raw data, screenshots, scan output

Professional standard Beautiful technical writeups that do not produce remediation are professional failures. Reports are evaluated on whether the client can act on them.

How long is a pentest?

Duration	Typical scope	What it produces
1–3 days	Very small or single target	Mostly scanning + validation; rarely finds chained impact
1–2 weeks	Single application or moderate infra	Common commercial size; can produce real exploitation chains
3–6 weeks	Larger scope, multiple apps, internal AD work	Deep coverage; identifies systemic weaknesses
Several months	Very large scopes or red team / TIBER-EU	Full adversary simulation with detection in scope

Common misrepresentation A "cheap two-day pentest" is usually a scan with a cover sheet. Duration, tester seniority, methodology depth, and report quality are all inputs to engagement cost.

Where Part III fits

Part III (Topics 14–18) takes penetration testing and goes deep on its technical phases:

Topic	PTES phase deepened
Topic 14 — Reconnaissance & enumeration in practice	Intelligence gathering
Topic 15 — Exploitation in practice	Exploitation
Topic 16 — Privilege escalation (Linux and Windows)	Post-exploitation
Topic 17 — Web application testing	Vulnerability analysis + exploitation (web)
Topic 18 — Post-exploitation & kill-chain synthesis	Post-exploitation + reporting narrative

Key framing Each Part III topic exists inside this methodology. The labs are a deep dive into one slice of the catalog — not the whole picture.

Check — scoping a client request

Reflection

A client says "we want a pentest" but has not specified scope. What pentest types could they mean, and how would you guide them to choose?

Reveal answer

Walk them through the BSI axes: external or internal? black/grey/white box? what target — web, infrastructure, AD, cloud? what aggressivity? what must the report contain? "We want a pentest" is a starting point, not a scope. Without these answers, no valid authorization exists, no rules of engagement can be written, and no meaningful deliverable can be defined.

What you take home

Pentesting is defined by exploitation, chaining, and demonstrable impact — not by the tools.
The seven PTES phases structure every engagement; reporting is the most under-invested phase in practice.
A pentest is always bounded by scope, time, and tester skills — a clean result is not proof of security.
Pentest type is multi-dimensional: external/internal, box color, and target type must all be specified before authorization is meaningful.
The attack narrative in the report is often more useful to decision-makers than the isolated finding list.
Pentesting is one methodology among several; the Part III labs go deep on one slice — they do not replace the broader catalog.

Next: Topic 12 — Red teaming. How pentesting evolves when the adversary is persistent, covert, and goal-driven.

END · TOPIC 11

Scope. Exploit. Report. Repeat.

Review the PTES phases — identify which phase each Part III lab topic deepens before the next session.