1. The Pentest Lifecycle
A penetration test is an authorized, simulated attack against a system, meant to find real exploitable weaknesses before an actual attacker does. It follows a structured lifecycle, echoing the systematic approach Week 1 introduced for threat modeling.
1. Scoping & Authorization -- BEFORE any testing: what's in scope, what's
explicitly out of scope, written permission (Section 2)
2. Reconnaissance -- gather information about the target (Section 3)
3. Scanning -- Week 11's Nmap/vulnerability scanning, applied
with intent to find a way in
4. Exploitation -- actually attempt to exploit findings, proving
real impact rather than just theoretical risk
5. Post-Exploitation -- once in, how far could an attacker actually
go? (privilege escalation, lateral movement)
6. Reporting -- Section 5: findings, evidence, remediation --
the actual deliverable a pentest produces
Every earlier week in this course maps onto this lifecycle somewhere: Week 2's traffic analysis and Week 11's scanning feed reconnaissance and scanning; Weeks 6-7's web vulnerabilities and Week 9's container weaknesses are exactly the kind of findings exploitation targets; Week 13's evidence-handling discipline applies just as much to documenting a pentest's findings as an incident's timeline.
Week 11's vulnerability scanning identifies potential weaknesses. A pentest goes further, attempting to actually exploit them to prove real, demonstrated impact — the difference between "this might be exploitable" and "here's a screenshot of the data we actually accessed by exploiting it." That extra step is exactly why pentesting requires the stricter authorization boundary Section 2 covers.
2. Legal & Ethical Boundaries: Scope, Authorization & Responsible Disclosure
Every technique this course has taught — port scanning, exploiting SQL injection, cracking a password hash — is the exact same action whether it's a legitimate, authorized test or a crime. The only thing that separates them is explicit, written authorization, scoped precisely.
A written "Rules of Engagement" document, signed before ANY testing begins,
specifying:
- Exact scope: which IP ranges, domains, applications are IN scope
- Explicit exclusions: what's OUT of scope (a third-party vendor's
infrastructure, production data that shouldn't be modified/deleted)
- Time window: when testing is authorized to occur
- Rules: is denial-of-service testing allowed? Social engineering?
Physical access attempts?
- Emergency contact: who to call if something goes wrong mid-test
- Signed by someone with actual authority to grant this permission
-- not just any employee who says "sure, go ahead"
Scope matters precisely because a real target's infrastructure often includes third-party services, shared hosting, or systems outside the authorizing party's actual control — testing something out of scope, even accidentally, can mean attacking a system nobody actually gave you permission to touch.
# If you discover a vulnerability incidentally (not during an authorized
# test) -- e.g. you notice a public site's login form is SQL-injectable
# while just using it normally:
1. Do NOT exploit it further to "prove" the vulnerability beyond what's
needed to confirm it exists
2. Report it privately to the organization (many have a security.txt
file at /.well-known/security.txt, or a bug bounty program) --
never post it publicly first
3. Give the organization reasonable time to fix it before any public
disclosure (a common standard is 90 days)
4. Never demand payment as a condition of disclosure -- that's extortion,
not responsible disclosure, regardless of how it's framed
Unauthorized access to a computer system is a crime in essentially every jurisdiction, regardless of intent, whether anything was damaged, or whether the vulnerability was "obviously" present. Every single hands-on exercise in this course involving exploitation has deliberately targeted a system you built, own, or that's explicitly designed for this purpose (Juice Shop, Metasploitable, and similar) — that's not a formality, it's the actual legal line.
3. Reconnaissance
Reconnaissance gathers information about a target before any active testing begins — split into passive recon (gathering public information without touching the target directly) and active recon (Week 11's scanning, which the target can detect).
# DNS records (Week 2) reveal infrastructure without touching the target itself
$ dig example.com ANY
$ whois example.com # registration details, sometimes admin contacts
# Search engines and public records reveal exposed information
# ("Google dorking" -- targeted search operators):
site:example.com filetype:pdf # public documents that might leak info
site:example.com "index of" # accidentally exposed directory listings
# Job postings, public GitHub repos, and social media often reveal
# tech stack details a company didn't intend to disclose so precisely
Active recon (Week 11's Nmap scanning, applied here with pentest intent) is the next phase — actively probing the target, which means it's happening only within the authorized scope and time window from Section 2, and the target's own monitoring (Week 12) may legitimately detect and alert on it.
If a real attacker's reconnaissance and scanning would trigger the exact detection rules Week 12 built, that's a genuinely good sign — worth explicitly noting in the final report as evidence the monitoring works, not something to be embarrassed about as a tester. A pentest that goes completely undetected can mean either the testers were very stealthy, or the target's detection has real gaps — the report should distinguish between those two very different explanations.
4. Guided Exploitation Against a Lab Target
Putting the pieces together: a real, guided attack chain against OWASP Juice Shop (from Week 7) or Metasploitable (a deliberately vulnerable Linux VM), combining reconnaissance, a known vulnerability class, and post-exploitation thinking.
# 1. Recon/scan (Week 11)
$ nmap -sV 192.168.56.101
21/tcp open ftp vsftpd 2.3.4 # a KNOWN backdoored version
22/tcp open ssh
80/tcp open http
3306/tcp open mysql
# 2. That specific vsftpd version has a well-documented backdoor CVE --
# research it (this is the "does a known exploit exist" step from
# Week 11's prioritization framework, run in reverse -- as an attacker)
# 3. Exploit it (using Metasploit, or the documented manual technique) --
# confirm you have a shell on the target
# 4. Post-exploitation: what does this access actually let you reach?
$ whoami # what privilege level did this land at?
$ cat /etc/passwd # what other accounts exist on this box?
# Document exactly what was accessible -- this IS the "impact" a real
# report needs, not just "we got a shell"
This is deliberately the same shape as Week 6-7's exercises — find a specific, version-identified vulnerability, confirm it's genuinely exploitable, and document the actual impact — now framed explicitly as the pentest process rather than an isolated vulnerability-class lesson.
Metasploitable and Juice Shop exist specifically to be exploited — running these exact techniques against anything else, without the Section 2 authorization in hand, crosses directly into the illegal territory this week has been explicit about. The value of practicing on a designed-to-be-vulnerable target is that the legal question is already settled: it's yours, and it's meant for exactly this.
5. Reporting Findings
A pentest's actual deliverable is the report — without it, all the technical work of Sections 3-4 produces no organizational value at all. A good report is structured specifically to be actionable by people who weren't in the room.
Finding: Outdated vsftpd 2.3.4 with known backdoor vulnerability
Severity: Critical (CVSS 10.0 -- remote code execution, no auth required)
Location: 192.168.56.101:21
Description: The target's FTP service runs vsftpd 2.3.4, which contains
a publicly known backdoor (CVE-2011-2523) allowing unauthenticated remote
code execution.
Evidence: [screenshot/log of successful exploitation and resulting shell access]
Impact: Full remote code execution as [user], with access to [specifically
what was reached in post-exploitation -- Section 4's findings]
Remediation: Upgrade vsftpd to a current, patched version. This is
directly Week 11's patch-cadence problem -- an unpatched, known-vulnerable
service version that should have been caught by routine vulnerability
scanning before a pentest ever needed to find it.
Notice the remediation explicitly connects back to Week 11 — a good pentest report doesn't just list what was broken, it points toward the process gap that let it stay broken, the exact same blameless-and-systemic framing Week 13's post-incident reports use.
A real report's audience includes people who will never read the technical detail directly — a short summary (overall risk posture, the 2-3 most critical findings, the general theme of what needs attention) lets a non-technical decision-maker understand and prioritize the fix, while the detailed findings remain available for the engineering team that actually implements it.
6. Hands-on Exercise
Run a full, scoped pentest against Metasploitable, and write the real report
Complete every phase of Section 1's lifecycle against a lab target, ending with a genuine, professional-format report.
Part 1 — Scope and recon:
- Set up Metasploitable (or an equivalent intentionally-vulnerable VM) on an isolated local network — never bridge it to your real network, since it's deliberately full of unpatched vulnerabilities.
- Write a one-page "Rules of Engagement" document for this exercise, following Section 2's format — scope (this specific VM's IP), time window, and explicit exclusions, even though you're both the tester and the authorizer here.
- Perform passive recon on the VM's exposed services using only
whois/DNS-equivalent techniques where applicable, then active recon withnmap -sV.
Part 2 — Exploit and document post-exploitation:
- Identify at least one service version from your scan with a known, documented vulnerability (the vsftpd backdoor from Section 4 is a reliable, well-documented starting point).
- Exploit it, confirming actual shell or equivalent access — not just a theoretical "this looks vulnerable."
- Document post-exploitation findings: what user/privilege level you landed at, and what else was reachable from there (other files, other services, other accounts) — resist the urge to go further than confirming access; the point is documenting impact, not maximizing damage.
Metasploitable has multiple additional intentionally-vulnerable services beyond vsftpd (an outdated Samba version, a weak database configuration, and more) — if the FTP backdoor doesn't work as expected on your setup, your earlier Nmap scan almost certainly surfaced a viable alternative.
Part 3 — Write the report:
- Write a full pentest report for your findings, following Section 5's structure: executive summary, and at least one detailed finding with severity, location, description, evidence, impact, and remediation.
- In the remediation section, explicitly connect the finding back to which earlier week's process would have prevented it (patch management, secrets management, network segmentation, etc.) — the same systemic framing as a post-incident report.
This report is a genuinely useful portfolio artifact — written professionally, with a redacted/sanitized version if you'd like to show it to others, it demonstrates the exact skill (finding a vulnerability, confirming real impact, communicating it clearly) that a pentesting or security-analyst role actually requires day to day.
7. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
What's the key difference between a vulnerability scan (Week 11) and a penetration test?
What's the key difference between a vulnerability scan (Week 11) and a penetration test?
A vulnerability scan identifies potential weaknesses based on version detection and known-CVE databases. A pentest goes further, actually attempting to exploit those findings to prove genuine, demonstrated impact — the difference between "this might be exploitable" and confirmed, real-world access gained through the vulnerability.
Q2
Why does written, scoped authorization matter so much, given that the technical techniques are identical to those used in an actual attack?
Why does written, scoped authorization matter so much, given that the technical techniques are identical to those used in an actual attack?
Written authorization is the only thing that legally and ethically distinguishes an authorized security test from a crime — the actions themselves (scanning, exploiting) are identical either way. Scope specifically matters because real infrastructure often extends into third-party or shared systems the authorizing party doesn't actually control, and testing outside the defined scope can mean attacking something nobody gave permission to touch.
Q3
You discover a SQL injection vulnerability on a public website incidentally, outside any formal engagement. What does responsible disclosure require you to do?
You discover a SQL injection vulnerability on a public website incidentally, outside any formal engagement. What does responsible disclosure require you to do?
Report it privately to the organization (via a security contact or bug bounty program), avoid exploiting it further than needed to confirm it exists, and give the organization reasonable time to fix it before any public disclosure — never demand payment as a condition of reporting, and never disclose publicly first.
Q4
Why does a good pentest finding's remediation section point to a systemic process gap ("routine patching would have caught this") rather than just "upgrade this software"?
Why does a good pentest finding's remediation section point to a systemic process gap ("routine patching would have caught this") rather than just "upgrade this software"?
Fixing the one specific finding closes that one instance, but the underlying process gap (no regular vulnerability scanning, no patch cadence) will produce the same class of finding again with a different specific vulnerability next time. Pointing to the systemic gap — the same blameless, root-cause framing as Week 13's post-incident reports — helps prevent the next occurrence, not just this one.