This site already has deep, dedicated courses on specific vulnerability classes — xss1, csrf1, sqli1, bc1, dbsec1, and the owasp1 survey course tying several of them together. This course is different: it's not about any one vulnerability. It's about the process a professional actually follows to find and prove real security weaknesses in a target system — and before a single technique gets named, there's one precondition that has to be true first.

Penetration Testing vs. Related Disciplines

"Security testing" covers several genuinely different activities, often confused with each other:

This course focuses specifically on penetration testing — but the precondition covered next applies, in one form or another, to every discipline in that table.

The Single Non-Negotiable Precondition — Written Authorization

Before any reconnaissance, any scanning, any attempt at exploitation — before anything this course covers from Chapter 4 onward — one thing has to already be true: explicit, written authorization from someone with actual legal authority over the target system. Not a verbal "sure, go ahead." Not an assumption that testing is welcome because a company has a bug bounty page somewhere. A real, specific, written agreement, in place before testing starts.

What Authorization Actually Looks Like

In practice, authorization takes the form of a written scope agreement or Rules of Engagement (RoE) document — sometimes informally called a "get out of jail free" letter — signed by someone who genuinely has the authority to grant it for the specific systems being tested. It defines, in writing, exactly what's in scope, what testing windows are permitted, what techniques are and aren't allowed, and who to contact if something unexpected happens during testing. pentest1-2 covers the full structure of this document in depth.

Bug bounty programs work slightly differently: authorization comes from the program's own published policy rather than an individually signed document — but the same underlying principle holds. Testing anything outside that policy's own stated scope is exactly as unauthorized as testing a company with no bug bounty program at all.

What This Course Covers

Hands-On Exercises

pentest1-1 established that written authorization has to exist before anything else happens. This chapter covers what that authorization actually has to specify: what kind of test is being run, and — with real, sobering stakes — exactly what is and isn't in bounds.

Black Box, White Box, and Gray Box Testing

How much internal knowledge the tester starts with is itself a deliberate, negotiated choice:

Gray Box is often the practical default for real engagements — it balances realism against making efficient use of a genuinely limited testing budget and timeframe.

Internal vs. External Engagements

External engagements test from outside the organization's own network, simulating an internet-based attacker — this is the threat model most of this site's own web-application-focused courses (xss1, csrf1, sqli1) already assume. Internal engagements test from inside the network instead, simulating a compromised internal machine, a phishing victim's own foothold, or a malicious insider — a genuinely different threat model, and a direct real-world instance of dbsec1-1's own insider-threat material: someone who already has legitimate network access, tested from that exact starting position.

Scope Categories — What's Actually Being Tested

• Network — infrastructure-level testing: servers, firewalls, network segmentation.
• Web Application — the specific vulnerability classes this site already teaches in depth (xss1, csrf1, sqli1, bc1) — the direct technical grounding pentest1-6 formally names as this course's own "toolkit."
• Wireless — Wi-Fi security testing, a genuinely distinct technical domain this course names but doesn't cover in depth.
• Social Engineering — phishing simulations, pretexting: testing people, not systems — a fundamentally different attack surface than anything else in this list.
• Physical — testing whether someone can physically walk into a facility or server room — easy to overlook, and a real, named category in almost every professional methodology.

Why Scope Must Be Precise, in Writing

Vague scope isn't just an inefficiency — it's a real legal risk, directly extending pentest1-1's own authorization material.

Hands-On Exercises

pentest1-1 and pentest1-2 covered authorization and scope — the preconditions a real engagement needs before it starts. This chapter covers what "methodology" actually means once testing does start: a documented, standardized structure, not an individual tester's own improvised approach.

Why Standardized Frameworks Exist

Three concrete reasons a real engagement follows a published framework rather than one tester's own personal process:

• Consistency — the same engagement produces comparable results whoever runs it, and results from different engagements over time can be meaningfully compared.
• Completeness — a published framework was built and refined by many practitioners over years specifically to avoid skipped steps; an individual's own improvised checklist has no such guarantee.
• Legal defensibility — if an engagement is ever scrutinized after the fact (a dispute, an incident, an audit), "we followed a recognized, published standard" is a genuinely different, stronger position than "we did what seemed reasonable at the time."

PTES — The Penetration Testing Execution Standard

PTES defines seven phases, in order: Pre-engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post Exploitation, and Reporting. It's broad and technique-agnostic — it applies to network, web application, wireless, and social engineering engagements alike, rather than being scoped to any one category from pentest1-2's own list.

The OWASP Testing Guide

Where PTES is broad, the OWASP Testing Guide is deliberately narrow and deep: it's the field manual specifically for the Web Application scope category named in pentest1-2. It's maintained by the same organization behind owasp1's own Top 10 survey, and its testing categories map closely onto vulnerability classes this site already teaches in real depth — xss1, csrf1, and sqli1 each correspond to entire testing categories inside the Guide.

NIST SP 800-115

NIST's Technical Guide to Information Security Testing and Assessment is a US government publication, organized around four higher-level phases: Planning, Discovery, Attack, and Reporting. It's the framework most likely to be explicitly, contractually required — government contractors and organizations in regulated industries are often required to demonstrate compliance with a named NIST standard specifically, not just "a reasonable methodology."

Hands-On Exercises

pentest1-3 named this phase Intelligence Gathering in PTES's own terms. This chapter covers what that actually means in practice: building a real picture of a target before touching it, using techniques that range from completely invisible to directly observable by the target.

Passive vs. Active Reconnaissance

Passive recon gathers information without directly interacting with the target's own systems — nothing sent reaches the target, so nothing can appear in their logs. Public records, search engines, social media, cached pages, and WHOIS lookups against a third-party registry all count as passive. Active recon means direct interaction with the target's own infrastructure — even something as simple as a DNS query sent to the target's own authoritative nameserver, or a single ping, counts as active, since it touches systems the target actually controls and could show up in their own logs.

The distinction matters because it maps directly onto risk: passive recon carries essentially zero risk of detection or disruption, while active recon — however innocuous it seems — can be logged, can trigger alerts, and some scope agreements explicitly restrict it to specific time windows or exclude particular techniques entirely.

WHOIS & DNS Enumeration

WHOIS lookups reveal registrant information, registrar, and creation/expiration dates — though privacy services now redact much of what used to be public. DNS enumeration goes further, extending net1-9's own DNS resolution hierarchy material directly into an information-gathering technique: subdomain enumeration, MX records (revealing mail infrastructure and often which third-party provider handles it), TXT records (SPF/DKIM entries and verification tokens that leak which third-party services — analytics, marketing tools, cloud providers — an organization actually uses), and NS records.

A classic (often already-fixed) misconfiguration worth checking is an open zone transfer (AXFR) — a nameserver that will hand over its entire zone file to anyone who asks, rather than only to its own designated secondary servers.

OSINT — Public Records & Social Media

• Job postings — a listing for "a Senior React Developer with AWS and PostgreSQL experience" reveals real technology-stack details for free.
• Employee enumeration via LinkedIn — relevant specifically to the Social Engineering scope category from pentest1-2.
• Public code repositories — accidentally committed credentials, internal hostnames, or revealing comments.
• Public device search engines (Shodan/Censys-style) — searching pre-existing, already-collected scan data rather than scanning the target directly, keeping this technique passive.
• Breach databases — checking whether an organization's own email addresses have appeared in known public breaches, directly relevant to bc1's own password-security material and previewing pentest1-7's credential-based exploitation.

Why Recon Quality Determines Everything Downstream

pentest1-5's scanning depends on already knowing what to scan — the IP ranges and subdomains this phase discovers. pentest1-6's vulnerability analysis depends on knowing what's actually running, using the technology-stack clues this phase surfaces. pentest1-7's exploitation sometimes depends directly on valid targets or credentials this phase turns up. A shallow recon phase doesn't just produce a smaller result on its own — it produces a shallow, incomplete attack surface map that every later phase inherits without ever knowing what was missed.

Hands-On Exercises

pentest1-4 produced a candidate list of assets — IP ranges, subdomains, hints about technology in use. This phase confirms which of those candidates are actually alive, what ports are actually open on them, and what's actually running behind each one — turning a speculative list into hard, verified evidence.

Host Discovery

Before scanning individual ports, a real engagement first confirms which hosts in a range are actually reachable — most simply, via a ping sweep, extending net1-10's own diagnostic-tooling chapter directly. But this needs an important caveat: many firewalls block ICMP by default, so a host that doesn't respond to a ping isn't necessarily down — it may simply be filtering the exact protocol being used to check.

Port Scanning

A port scan sends probes across a range of ports and observes the response to classify each one as open, closed, or filtered — filtered meaning no response was returned at all, which is itself ambiguous (it could mean a firewall is silently dropping the probe, or that nothing is listening and the host simply doesn't reply).

Service & Version Detection, Banner Grabbing

Confirming a port is open only answers "is something listening here" — the next question is what. Many services announce their own software name and version on connection — an SSH server, for instance, commonly announces a banner like OpenSSH_8.9 before any authentication happens at all. Tools like nmap automate this with dedicated version-detection modes (-sV), sending protocol-specific probes and comparing the responses against a database of known service signatures.

A specific, identified version is directly useful — it immediately narrows down which known vulnerabilities are even worth considering in pentest1-6, rather than starting from a generic "this port is open" with no further information.

Building a Real Attack Surface Map

Combining every piece from this phase — pentest1-4's discovered candidate assets, confirmed-alive hosts, confirmed-open ports, and identified service versions — produces a genuine, evidence-based map of the target's actual attack surface, replacing pentest1-4's own broader, more speculative candidate list. This map is the direct, concrete input pentest1-6's vulnerability analysis phase works from.

Hands-On Exercises

pentest1-1 opened this course with a claim worth restating in full now that it's time to prove it: a pentest is a repeatable, disciplined process, and every vulnerability class this site already teaches in depth is a tool this process calls on during one specific phase — not the process itself. This is that phase.

From Attack Surface Map to Candidate Vulnerabilities

pentest1-5 produced a real, evidence-based map: which hosts are alive, which ports are open, what service versions are running. This phase's job is to take that concrete map and match it against already-documented categories of weakness — not to invent new attack techniques, but to recognize which known vulnerability classes plausibly apply to what was actually found.

The Toolkit This Site Already Built

This site already teaches the vulnerability-class knowledge this phase draws on, in real depth, across six existing Security courses:

Each of those courses taught how a specific vulnerability class works, how to recognize it, and how to defend against it. This phase of a real engagement is the moment that same knowledge gets applied in the other direction — using it to recognize a discovered piece of attack surface as a plausible candidate worth investigating further, rather than devising something novel from scratch.

CVE Databases & Known-Vulnerability Matching

pentest1-5's own banner-grabbing and version-detection output enables a genuinely different kind of matching: once a specific service and version is known, it can be checked against public vulnerability databases (CVE/NVD) for already-documented, publicly disclosed flaws affecting that exact version.

This is a meaningfully different tool than the vulnerability-class matching above. Vulnerability-class knowledge (from xss1/csrf1/sqli1/bc1) is the right tool for an organization's own custom application code — there's no CVE for someone's own bespoke bug, since it was never publicly disclosed anywhere. CVE matching is the right tool for known third-party software — an outdated web server, a specific library version — where the exact flaw has already been found and documented by someone else.

Matching, Not Inventing

It's worth restating the chapter's own core discipline directly: this phase's job is to recognize known patterns in what was actually discovered, not to devise brand-new attack techniques. Discovering genuinely novel vulnerabilities is a distinct, much rarer skill. The overwhelming majority of real, professional penetration tests find real, exploitable issues through exactly this kind of methodical, thorough matching against an already-documented body of knowledge — not by stumbling onto something never seen before.

Hands-On Exercises

pentest1-6 closed with an open question: a candidate produced by pattern matching isn't a confirmed finding. This chapter closes that gap — but draws a real, professional line around exactly how far confirming it should go.

From Candidate to Confirmed — What Exploitation Actually Proves

pentest1-6's candidates are attempted here, hands-on, to determine whether they're actually real, actually exploitable, and what genuine impact they enable in this specific target's own context — resolving the exact gap pentest1-6's own warn-box left open, where an existing mitigation (rate limiting, output encoding) could mean a superficial pattern match isn't actually exploitable at all.

Proof-of-Concept vs. Full Exploitation

A proof-of-concept (PoC) is the minimum action needed to demonstrate a vulnerability is real, without going further than necessary. Full exploitation continues past that point — and is very often not necessary to prove anything additional.

Why "I Could Have" Is Often the Correct Stopping Point

Once a vulnerability is confirmed exploitable in principle — the UNION query worked, the script executed — extracting every row or every session isn't "being more thorough." It adds no additional evidentiary value: the PoC already proved everything the client needs to know. "I could have extracted the entire customers table, but stopped after confirming access to a single non-sensitive record" is both scientifically sufficient and the professionally correct choice — not a missed opportunity.

When the Target Is a Live Production System

Most real engagements test systems actual customers are actively using, not an isolated lab — so the risk of "going further than necessary" isn't hypothetical, it's a real, current risk to real people and real data. This is exactly why scope, per pentest1-2, sometimes explicitly restricts testing to low-traffic windows, or arranges for a cloned staging environment specifically to remove this tension entirely rather than relying on tester discipline alone.

Hands-On Exercises

pentest1-7 proved a candidate was real, stopping deliberately at proof-of-concept. But a single confirmed foothold rarely answers the full question a client actually cares about: if a real attacker got exactly this same foothold, what could they genuinely reach from there? This chapter asks that question directly — with pentest1-7's own discipline still fully in force.

Privilege Escalation

Privilege escalation means gaining a higher level of access than the initial foothold provided — moving from a low-privilege web application user to administrative access on the underlying server, or from a standard database account to a database administrator. This is usually called vertical escalation, since it moves upward within the same general context. A related but distinct concept, horizontal movement, means reaching a different account at roughly the same privilege level (another user's own data, rather than a genuinely higher-privileged role) — worth distinguishing by name even though both matter to a real assessment.

Lateral Movement

Lateral movement means using an established foothold on one system to reach other systems on the same network that weren't directly reachable or vulnerable from outside — directly relevant to the Internal engagement category from pentest1-2. A single compromised low-value system can become a stepping stone deeper into a network that was otherwise well-defended at its own perimeter. Credential reuse is a common enabler here: a credential surfaced during pentest1-4's own breach-database OSINT, or captured live on one system, can turn out to work on entirely different systems — a real, practical extension of bc1's own password-security material.

The "Assumed Breach" Mentality

Assumed breach engagements deliberately start from a different position: rather than asking "can an attacker get in at all," the tester is given an already-compromised low-privilege account or workstation access from the start, and the engagement asks "given that a foothold already exists, how much access can genuinely be reached from here." This connects directly to pentest1-2's own Gray Box (partial starting access) and Internal engagement categories.

This mentality matters because real breaches rarely start with a sophisticated zero-day — they usually start with something mundane, like a phishing email or a single leaked credential. Understanding what happens after that ordinary, unglamorous initial foothold is very often more operationally valuable to a real organization than one more confirmation that a perimeter can theoretically be breached at all.

Hands-On Exercises

pentest1-4 through pentest1-8 produced real, confirmed findings. None of that has any value to the client until it's written down clearly, prioritized honestly, and communicated to the right audience. This chapter is about that final, essential step.

The Report Is the Product

The exploitation itself leaves no lasting artifact — once testing ends, everything that happened during pentest1-4 through pentest1-8 only continues to exist for the client in one form: the written report. A pentest that finds real, serious vulnerabilities but produces a poor report has, in a real and practical sense, failed to deliver the thing the client actually paid for.

This closes a loop opened all the way back in pentest1-2: the engagement began with a written document — the scope agreement and Rules of Engagement — and it ends with a written document, the report. Both are the tangible, contractual artifacts of the entire engagement; the actual testing happens in between them, but the client's lasting deliverable is written on both ends.

Two Audiences, Two Sections

Both sections are necessary, for symmetric reasons: a report with only technical detail rarely secures the budget or priority needed from people who don't have time to parse it; a report with only an executive summary gives the engineers who need to fix each issue nothing concrete to act on. A good report serves both audiences without forcing either one to wade through content meant for the other.

CVSS — Common Vulnerability Scoring System

Not every finding deserves equal urgency, and CVSS is the standardized way to communicate that consistently. It scores a vulnerability across several metrics — attack vector, attack complexity, privileges required, user interaction needed, and impact on confidentiality/integrity/availability — combining them into a 0–10 score and a Low/Medium/High/Critical rating. Standardization matters here for the same reason pentest1-3's own frameworks mattered: a "Critical" finding should mean roughly the same thing regardless of which tester or firm wrote the report.

Remediation Guidance

A finding without a fix isn't actionable — the report needs concrete remediation guidance, not just a description of the weakness. This is where this course's own "toolkit" chapters (pentest1-6) pay off a second time, now applied to the defensive side rather than the offensive matching side: a SQL injection finding's remediation should point specifically at sqli1's own parameterized-query material; an XSS finding at xss1's own output-encoding material; a weak-authentication finding at bc1's own material on password hashing and MFA. Remediation guidance should generally be ordered by CVSS severity — though a realistic, useful report is honest that both severity and ease of fix genuinely matter to a client's actual remediation roadmap, not severity alone.

Hands-On Exercises

Nine chapters built one continuous process: authorization, scope, framework, recon, scanning, matching, exploitation, post-exploitation, reporting. This capstone walks that entire process end to end for a single fictional target — Meridian Retail Co., a fictional online retailer — combining every prior chapter into one coherent engagement.

The Scenario

Meridian Retail Co. is preparing for a major holiday sales push and wants its online store and supporting infrastructure tested before traffic peaks. They've requested a Gray Box engagement (per pentest1-2) — testers will be given a standard customer account, but no source code or administrative access — scoped to their Web Application and Network categories.

Sample Rules of Engagement Document

MERIDIAN RETAIL CO. — RULES OF ENGAGEMENT (SAMPLE, FICTIONAL)
================================================================
Client:                Meridian Retail Co.
Authorized signatory:  [Name], VP of Engineering
Testing firm:          [Firm Name]
Engagement type:       Gray Box (pentest1-2) — one standard
                        customer account provided, no source
                        code or admin access
Scope — IN:
  - shop.meridianretail.example (production web application)
  - api.meridianretail.example
  - IP range 203.0.113.0/24 (Meridian's own hosted infrastructure)
Scope — OUT:
  - payments.meridianretail.example (third-party payment
    processor infrastructure, NOT owned by Meridian — see
    pentest1-2's own shared-infrastructure warning)
  - Any Meridian employee's personal social media (OSINT on
    named individuals excluded per pentest1-4's own scope note)
Testing window:        Weekdays, 22:00-06:00 local time only
                        (low-traffic hours, per pentest1-5's own
                        scan-intensity guidance)
Methodology:            PTES (pentest1-3)
Escalation contact:     [Name], available 24/7 during the window
Emergency stop:         Testing halts immediately on request from
                        either party; no penalty for invoking it
Explicitly authorized:  Testing up to proof-of-concept level
                        (pentest1-7) — NOT data destruction,
                        NOT denial-of-service, NOT extraction
                        beyond a single non-sensitive record
Signatures:             ______________________  ______________________
                        Client                   Testing Firm
================================================================

Walking Through the Methodology

1. Pre-engagement (pentest1-1 / pentest1-2): the RoE above is signed by someone with real authority over Meridian's own systems, before any technical activity begins.
2. Framework (pentest1-3): the engagement follows PTES's seven phases, matching this course's own structure directly.
3. Reconnaissance (pentest1-4): passive WHOIS/DNS enumeration reveals Meridian's own hosting provider and mail infrastructure; a public job posting reveals a React/Node.js stack; employee LinkedIn presence is noted but not investigated further, per the RoE's own exclusion.
4. Scanning & Enumeration (pentest1-5): confirms shop.meridianretail.example and api.meridianretail.example are alive, with ports 443 and — unexpectedly — 3306 (MySQL) directly reachable; a SYN scan run only during the authorized window identifies service versions.
5. Vulnerability Analysis (pentest1-6): the reachable 3306 port is flagged as a dbsec1-style candidate (a database that should never be directly internet-facing); the checkout page's search field is flagged as a sqli1 candidate; the login form is flagged as a bc1 candidate.
6. Exploitation (pentest1-7): a single non-sensitive proof-of-concept row (the database version string) is extracted via the checkout search field, confirming the SQLi candidate; the login form's session cookie is confirmed to be missing the Secure flag. Testing stops at proof-of-concept for both — no customer data is touched.
7. Post-Exploitation (pentest1-8): using the Gray Box starting account, the tester confirms the compromised checkout server can also reach an internal admin panel not exposed externally — a real lateral-movement path — and stops there, without logging into the panel itself.
8. Reporting (pentest1-9): the final report includes an executive summary (three findings, one Critical, two High, business impact framed around the upcoming sales push) and technical findings with CVSS scores and reproduction steps, with remediation pointing directly at dbsec1 (network isolation for the database), sqli1 (parameterized queries), and bc1 (proper cookie flags).

Chapter Attribution

Hands-On Exercises