Penetration
Testing

Penetration testing is the practice of attacking systems with permission — simulating what a real attacker would do in order to find vulnerabilities before they do. That single sentence contains the two things that matter most: attacking (this is genuinely adversarial work, not passive scanning) and with permission (without which it is simply crime). Everything else in this module builds on those two foundations.

Four Things That Are Not the Same

The industry uses overlapping terminology carelessly. Understanding the real distinctions matters for setting client expectations, scoping engagements correctly, and choosing the right assessment type for a given security objective.

The Attacker Mindset

The most valuable thing a penetration tester develops is not knowledge of specific tools or techniques — it is a way of thinking. Defenders ask "what have I protected?" Attackers ask "what can I reach from here?" The difference is orientation: defensive thinking maps controls to assets; offensive thinking maps access to possibilities.

The attacker mindset has three practical components:

• Assume there's a way in. Experienced testers start every engagement with the belief that they will find something — not arrogance, but the empirical observation that every system has weaknesses, and the job is finding them. This assumption prevents premature abandonment of promising attack paths.
• Think in chains, not individual findings. A single exposed SMB port is an informational finding. SMB + weak credentials + the same credentials reused on the domain controller is a critical finding. Real attacker value comes from combining individually low-severity issues into high-impact attack chains.
• Ask "what could this lead to?" at every step. Every piece of information revealed by the target — a version number, a username, an error message, a response timing difference — is a potential stepping stone. Defensive instinct filters information as noise; offensive instinct evaluates every detail for leverage.

Why Organisations Hire Pentesters

The honest answer is that organisations hire pentesters for several reasons — not all of them equally good:

• Regulatory compliance — PCI-DSS requires annual penetration testing. SOC 2 Type II auditors expect evidence of regular testing. ISO 27001 implementations include penetration testing as a control. Many organisations treat pentesting primarily as a compliance checkbox — this produces scoped, limited engagements optimised for report production rather than genuine risk discovery.
• Genuine risk reduction — the more mature motivation. Finding and fixing vulnerabilities before real attackers find them reduces the probability and impact of breaches. Organisations that use pentesting as a genuine risk management tool invest in realistic scoping, meaningful objectives, and remediation verification.
• M&A due diligence — acquiring companies assess the security posture of acquisition targets. A hidden active breach or a compromised infrastructure dramatically changes the deal value.
• Incident response context — post-breach testing to understand how an attacker moved and what else might have been missed during remediation.

What the Career Actually Looks Like

Penetration testing has several career paths with meaningfully different day-to-day realities:

• Consultancy / Agency — the most common entry point. You work for a security firm and are assigned to client engagements. Each engagement is different: different environments, different objectives, different clients. Heavy travel in some firms. Fast skill development because of the variety. Income is usually good; lifestyle depends heavily on the firm's culture.
• In-house red team — typically found only at large enterprises (banks, tech companies, defence contractors). Deep knowledge of one environment; longer campaign timelines; better lifestyle. Harder to get into without prior consultancy experience.
• Bug bounty hunter — independent, self-directed, fully remote. Income is highly variable — exceptional researchers earn six figures; most earn far less. Works best as a supplement to other income while building skills, or for those who have already reached senior consultancy level.
• Government / military — national security agencies, law enforcement, and military branches all employ offensive security practitioners. More stable than consultancy; work may be classified; requires security clearance and citizenship eligibility.

Computer Crime Law — The Legal Landscape

Most countries have statutes that criminalise unauthorised access to computer systems. The intent is almost entirely irrelevant — it is the authorisation, or lack of it, that determines legality.

• US — Computer Fraud and Abuse Act (CFAA, 18 USC §1030) — the primary US federal statute. Prohibits accessing a computer "without authorisation" or "in excess of authorisation." The scope of "access" is intentionally broad and has been interpreted to include port scanning, sending unexpected network packets, and accessing resources the owner hasn't explicitly prohibited. Multiple security researchers have faced CFAA prosecution for activities that were technically legal under any common-sense reading of the statute. The law was written in 1986 and has not kept pace with the modern internet.
• UK — Computer Misuse Act 1990 (CMA) — the UK equivalent. Three tiers: unauthorised access (section 1, up to 2 years); unauthorised access with intent to commit further offences (section 2, up to 5 years); unauthorised modification of computer material (section 3, up to 10 years). The 2015 amendment added serious crime provisions that affect tool possession — owning hacking tools with intent to use them for unauthorised access can itself be an offence.
• EU — Directive on Attacks Against Information Systems (2013/40/EU) — harmonises criminal law across EU member states for computer crimes. Member states implement it with varying severity.

What Constitutes Authorisation

Authorisation for a penetration test requires three things: the right person, the right scope, and the right form.

• The right person — only someone with legal authority over the target system can authorise testing. For a company's own systems: the CISO, CTO, or CEO. For cloud environments: the account owner, not just a system administrator. For systems hosted by a third party: both the client and the hosting provider may need to authorise (AWS requires notification for certain types of testing; Azure and GCP have similar policies). A developer who "gives permission" to test their employer's production environment without executive sign-off has not given authorisation.
• The right scope — authorisation must specify what is in scope: IP ranges, domains, applications, physical locations, social engineering targets. "Test whatever you want" is not adequate scope — it creates ambiguity that can expose the tester to liability when they access something they shouldn't have. Explicit exclusions (production databases, third-party systems, specific business-critical servers during certain hours) are as important as inclusions.
• The right form — written, signed, and retained. A Statement of Work (SoW) or contract that explicitly authorises the testing activities is the minimum. Some engagements also use a separate Rules of Engagement document for operational details. Verbal permission is worthless if you're later prosecuted.

Rules of Engagement in Depth

The Rules of Engagement (RoE) document is the operational specification of the penetration test. It answers the questions that the legal contract doesn't:

• Time windows — when can testing occur? Business hours only? 24/7? Certain systems only during maintenance windows?
• Excluded systems — what is explicitly out of scope? Production payment systems? Specific IP ranges? Third-party systems?
• Emergency contact — who to call if you accidentally cause an outage, find an active breach by a real attacker, or discover evidence of serious criminal activity?
• Safe word / pause protocol — a predetermined signal that either party can use to pause all testing immediately. Essential when the client's incident response team detects testing activity and needs to confirm it's authorised before escalating.
• Evidence handling — what happens to captured credentials, sensitive data found on systems, and screenshots of confidential information? These must be handled and disposed of appropriately.
• Deconfliction — how does the client's SOC know when activity is from the pentest versus a real attacker? Some engagements are fully announced (the SOC knows a test is happening); some are partially announced (executives know, SOC does not); some are black box (no one at the client knows). Each has different operational implications.

Responsible Disclosure

When vulnerability research is conducted outside of a formal engagement — independent security research, bug bounty programmes, or accidental discovery — the question of disclosure arises. The spectrum:

• Coordinated disclosure (preferred) — notify the vendor privately, give them a reasonable time to develop and release a patch (typically 90 days, per Google Project Zero's standard), then publish. The vendor gets time to fix the issue; users eventually get the information they need to protect themselves.
• Full immediate disclosure — publish everything immediately without vendor notification. Sometimes justified when the vendor is unresponsive, the vulnerability is already being exploited, or the vendor has a history of ignoring reports. High impact on affected users; high pressure on the vendor; high reputational risk for the researcher.
• Non-disclosure — report to the vendor and agree to never publish. Common in coordinated disclosure arrangements with large enterprise vendors who require NDAs. Protects no one except the vendor's reputation.

When Pentesters Get It Wrong — Real Cases

Understanding how legal situations go wrong is as important as understanding the law itself:

• Going out of scope — a tester hired to assess a web application who compromises a server not in scope, even in pursuit of a legitimate attack chain, may have committed a computer crime against that server. Scope discipline is not bureaucracy — it is legal protection.
• Retaining client data — a tester who captures credentials or sensitive documents during an engagement and retains them after the engagement closes has mishandled client data and potentially violated data protection law.
• The wrong client contact — in 2019, two contractors hired to conduct a physical penetration test of an Iowa courthouse were arrested and charged with third-degree burglary after being discovered by police. The authorisation letter they carried was from the state judicial agency — but county officials who owned the facility had not been notified. The case was eventually resolved, but they spent weeks fighting criminal charges despite having genuine authorisation from the entity they believed was responsible.

A methodology is what separates a professional penetration test from a disorganised attack. Without a framework, testers miss things — not because they lack skill, but because they lack a systematic approach that ensures complete coverage. A methodology also makes the engagement defensible: when a client asks "how did you test for X?", the answer is rooted in a recognised framework rather than personal preference.

Major Frameworks

• PTES (Penetration Testing Execution Standard) — the most comprehensive open standard for penetration testing. Covers seven phases: pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting. Detailed technical guidelines for each phase. The de facto reference for methodology.
• OWASP Testing Guide — specifically for web application testing. Extremely detailed per-vulnerability testing procedures with test cases, tools, and expected results for each OWASP Top 10 category and many others. Essential reference for web application testers.
• NIST SP 800-115 — the US federal government's technical guide to information security testing. More conservative and process-oriented than PTES. Required reference for engagements serving US federal clients.
• OSSTMM (Open Source Security Testing Methodology Manual) — focuses on measuring security through operational metrics. Less used in commercial pentesting but influential in security research contexts.

Black Box vs Grey Box vs White Box

Grey box is the most common commercial engagement type. It is more efficient than black box (less time wasted on reconnaissance that could be done internally) without sacrificing the realistic adversarial perspective. White box is appropriate when the objective is thoroughness — catching everything — rather than simulating a realistic attacker.

The Engagement Lifecycle

1. Pre-engagement — scoping call, Statement of Work, Rules of Engagement, authorisation letters, NDA, kickoff meeting. Nothing technical happens yet. The success of the engagement is significantly determined by the quality of this phase.
2. Reconnaissance — passive and active information gathering about the target. Attack surface mapping. The attacker learns everything possible about the environment before touching it.
3. Scanning and enumeration — active probing of in-scope systems. Port scanning, service version detection, vulnerability scanning, web application fingerprinting. Building the target inventory.
4. Exploitation — attempting to leverage identified vulnerabilities to achieve defined objectives. The "breaking in" phase — but only after thorough preparation.
5. Post-exploitation — after initial access is established: privilege escalation, lateral movement, persistence, data access, achieving the defined objective. This is where the actual impact is demonstrated.
6. Reporting — documenting everything: methodology, findings, evidence, business impact, remediation guidance. The deliverable the client pays for.
7. Remediation verification — retesting to confirm that fixes work. Not always included in the engagement scope, but should be.

Defining Objectives in Business Terms

The most common scoping mistake is defining a pentest in purely technical terms — "test all systems in the 10.0.0.0/8 range." Better scoping defines objectives in business terms: "determine whether an external attacker could access the customer database," or "assess whether a compromised employee workstation could be used to reach the payment processing environment."

Business-oriented objectives produce better tests because they guide the tester's choices when multiple attack paths are available. Faced with a choice between spending time on a finding that would only affect an internal development server versus one that could lead to the payment database, the business-oriented objective makes the prioritisation obvious.

Reconnaissance is the phase where patience pays off disproportionately. A tester who spends three hours on thorough reconnaissance before touching the target will be more effective than one who immediately launches nmap scans. Reconnaissance reduces wasted effort, reveals attack paths that direct scanning would never surface, and — in the case of passive reconnaissance — generates zero logs on the target's systems.

Shodan — The Search Engine for Exposed Infrastructure

Shodan continuously scans the internet and indexes the banners and metadata returned by devices on open ports. It is, in effect, a searchable database of everything exposed to the internet — servers, routers, cameras, industrial control systems, printers, and anything else with an internet-reachable port.

Shodan reveals: what services an organisation exposes, what software versions are running, what certificates are in use, and — critically — whether those versions have known critical vulnerabilities. The Pulse Secure VPN in the example above is an immediate high-priority lead: CVE-2019-11510 allows unauthenticated file read including VPN session files containing plaintext credentials. Finding this in Shodan before active scanning is pure intelligence value with zero network contact with the target.

Useful Shodan Filters

org:"Company Name"           # by organisation name registered with IP allocator
hostname:domain.com          # by hostname pattern
net:203.0.113.0/24           # by IP range (requires paid account)
ssl.cert.subject.cn:domain   # by certificate subject
product:"Apache httpd"       # by software product
vuln:CVE-2021-44228          # by CVE (shows hosts with known-vulnerable versions)
port:3389 country:GB         # RDP exposed in UK
"default password" port:80   # look for default credentials pages

Google Dorking — Advanced Search for Exposed Data

Google's search operators allow targeted queries that surface information organisations have inadvertently exposed publicly. These are sometimes called "Google dorks" — search strings that find specific types of sensitive content indexed by Google's crawler.

LinkedIn — Organisational Intelligence

LinkedIn provides two types of intelligence: organisational structure (who reports to whom, who are the decision-makers, who works in IT security) and technology stack (what tools does the company use, inferred from employees' skills sections and job history). This intelligence drives social engineering pretexts and helps build realistic phishing emails.

Certificate Transparency — Subdomain Enumeration

Every TLS certificate issued by a publicly trusted CA is logged in Certificate Transparency logs — and those logs are publicly searchable. Every subdomain a certificate has been issued for is visible. This is one of the most reliable subdomain enumeration techniques because it captures subdomains that don't appear in DNS searches or web crawls.

The findings above tell a story immediately: jenkins.acme-corp.com is a CI/CD server (high value — often contains credentials, deployment pipelines, and production access). staging.acme-corp.com is a staging environment (often less secured than production but connected to the same infrastructure). old-hr.acme-corp.com is a legacy system (potentially unpatched, forgotten, but still resolving to a live IP).

GitHub and Source Code Intelligence

Developers routinely commit secrets to public GitHub repositories — API keys, database connection strings, AWS access keys, and private keys. GitHub's secret scanning notifies maintainers, but detection is not instant and not all secrets are caught. Historical commits can contain secrets even after they've been removed from the current version (git history persists).

Scanning is the transition from passive intelligence gathering to active probing. You are now sending packets to the target and generating logs on their systems. Every scan generates evidence — in firewall logs, in IDS alerts, in web server access logs. Skilled testers balance thoroughness against detectability, choosing techniques that gather the required information with the minimum noise.

nmap — The Foundation Tool

nmap (Network Mapper) is the standard tool for host discovery, port scanning, service version detection, and OS fingerprinting. Its NSE (Nmap Scripting Engine) extends it to vulnerability detection, brute-force attacks, and protocol-specific enumeration.

Reading this output: OpenSSH 7.6p1 is an older version and worth checking against CVE databases. The SMTP server exposes VRFY — which allows username enumeration (send VRFY username and the server confirms if the account exists). Tomcat 8.5.23 is significantly out of date and has known critical vulnerabilities including CVE-2017-12617 (remote code execution via PUT request). These are the leads that drive the next phase.

Essential nmap Flags

Directory and File Enumeration

Web applications expose endpoints that aren't linked from the visible interface — admin panels, backup files, API endpoints, configuration pages. Directory enumeration uses wordlists to brute-force paths and discover these hidden resources.

SMB Enumeration

SMB is the Windows file sharing protocol and one of the richest sources of information during an internal pentest. From an unauthenticated or low-privilege position, SMB can reveal: system information, share names and permissions, domain information, user lists, and password policies.

This output contains several critical findings: the Finance share has anonymous read/write access, the domain has no account lockout policy (password spraying is possible without locking accounts), and we now have a list of valid usernames including service accounts. All of this was obtained without credentials.

Exploitation is the phase that most people imagine when they think of "hacking" — the moment of actual compromise. In reality, by the time a skilled tester reaches this phase, they already know with reasonable confidence that something is exploitable. The reconnaissance and enumeration phases have identified the target; exploitation is the confirmation and the mechanism for establishing access.

Why Vulnerabilities Exist — Classes of Errors

Understanding vulnerability classes — the categories of programming and design errors that create exploitable conditions — is more durable than memorising specific CVEs. New vulnerabilities will be discovered; the underlying error classes remain consistent.

• Memory safety errors — buffer overflows, use-after-free, format string bugs. When a program writes more data to a memory buffer than the buffer was allocated to hold, the excess overwrites adjacent memory — potentially including function return addresses, allowing an attacker to redirect execution to their own code. These errors are most common in C and C++ code.
• Injection flaws — when user-supplied input is interpreted as code rather than data. SQL injection, OS command injection, LDAP injection, XPath injection. The pattern is always the same: user input reaches an interpreter without adequate sanitisation or parameterisation.
• Authentication and authorisation failures — missing authentication checks, weak credential policies, broken session management, insecure tokens. The application fails to verify that the user is who they claim to be, or fails to verify that they're permitted to perform the requested action.
• Logic errors — the application works as programmed but the programming is wrong. A price calculation that can be manipulated to produce negative totals, a password reset flow that can be bypassed, a workflow that can be reversed in an unintended order. No automated scanner finds logic errors — only a tester who understands the intended behaviour can identify deviations from it.
• Configuration errors — software correctly installed but incorrectly configured. Default credentials, unnecessary services enabled, overly permissive file permissions, debug interfaces left enabled in production. Often the easiest vulnerabilities to exploit.

Metasploit Framework

Metasploit is the industry-standard exploitation framework — a platform that organises and automates many aspects of the exploitation workflow. Understanding its architecture helps you use it efficiently and understand what it's doing at each step.

Payload Types

Understanding payload types determines how you catch connections and what you can do once you have a session.

msfvenom — Payload Generation

msfvenom generates standalone payloads in various formats for scenarios where Metasploit's built-in payload handling isn't used.

Shell Stabilisation

Raw netcat shells are fragile — they have no tab completion, CTRL+C kills the connection, interactive programs like vim don't work, and they don't have terminal width settings. Shell stabilisation converts a dumb shell into an interactive, fully functional terminal.

Web application testing is the most common engagement type in commercial penetration testing. Nearly every organisation has web-facing applications, and those applications collectively represent an enormous attack surface. The OWASP Top 10 provides the canonical framework for web application vulnerability testing — not as an exhaustive list but as a prioritised coverage guide for the most impactful and prevalent vulnerability classes.

Burp Suite — The Central Web Testing Tool

Burp Suite is the standard platform for manual web application testing. It acts as an intercepting proxy between your browser and the target application, allowing you to view, modify, and replay every HTTP/HTTPS request. Understanding Burp's core tools is a prerequisite for web application testing.

SQL Injection in Depth

SQL injection remains one of the most impactful web vulnerabilities — it can lead to authentication bypass, data theft, and in some configurations, remote code execution. Understanding the different types helps you recognise them during testing and explain them clearly in reports.

Insecure Direct Object Reference (IDOR)

IDOR is the most commonly found high-impact vulnerability in bug bounty programmes — and it is entirely invisible to automated scanners. It occurs when an application uses a predictable identifier to reference a resource without verifying that the requesting user is authorised to access that specific resource.

Authentication Testing

Server-Side Request Forgery (SSRF)

SSRF tricks the server into making HTTP requests on behalf of the attacker — to internal services that are not directly accessible from the internet. In cloud environments, SSRF is particularly dangerous because the EC2/Azure/GCP metadata service is reachable from any process on the instance.

Internal network penetration testing starts the moment you're placed on the target network — whether through a physical port, a VPN, or a compromised edge device. The internal network has a different character from the external perimeter: there is more implicit trust, more legacy protocols, more misconfiguration, and usually far less monitoring of east-west traffic. Some of the most impactful findings in enterprise pentests come from the internal network.

LLMNR/NBT-NS Poisoning with Responder

LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) are Windows fallback name resolution protocols. When DNS fails to resolve a hostname, Windows broadcasts an LLMNR/NBT-NS query to the local network asking "does anyone know where is?" Responder listens for these broadcasts and responds — sending the querying machine to connect to the attacker's fake service. The querying machine sends its NTLMv2 credentials as part of the connection attempt.

NTLM Relay Attack

Rather than cracking captured NTLMv2 hashes (which requires the password to be in a wordlist), relay attacks use the captured authentication in real time — forwarding it to another system that accepts NTLM authentication. The attacker authenticates to a target as the victim without ever knowing the password.

Pivoting and Tunnelling

Pivoting uses a compromised host as a jump point to reach network segments that are otherwise inaccessible from the attacker's position — the compromised host has access that the attacker's machine doesn't.

Active Directory is the identity and access backbone of the vast majority of enterprise Windows environments. Compromising AD — or specific privileged accounts within it — means compromising everything it governs. This makes AD the primary objective in most internal penetration tests, and AD attacks are the techniques that matter most for demonstrating realistic enterprise impact.

BloodHound — Attack Path Discovery

BloodHound collects AD relationship data (group memberships, ACLs, trusts, session information) using SharpHound, then visualises attack paths — chains of AD relationships that a low-privilege attacker could follow to reach Domain Admin. It turns what would be hours of manual enumeration into an interactive graph that immediately reveals the shortest path to compromise.

Kerberoasting

Service accounts in Active Directory that have a Service Principal Name (SPN) registered can have their Kerberos service tickets requested by any authenticated domain user. These tickets are encrypted with the service account's password hash. An attacker requests the ticket and takes it offline for cracking — if the service account has a weak password, it yields domain credentials.

Pass-the-Hash

Windows NTLM authentication allows authentication using a password hash rather than the plaintext password — by design, for pass-through authentication scenarios. An attacker who obtains an NTLM hash (via Mimikatz, Responder, or SAM database extraction) can authenticate as that user to any system that accepts NTLM authentication, without ever cracking the hash.

DCSync — Extracting All Domain Hashes

DCSync abuses the Directory Replication Service (DRS) protocol — which domain controllers use to replicate with each other — to pull all account hashes from Active Directory without needing to log into a domain controller. An account with the DS-Replication-Get-Changes-All right (held by Domain Admins and any account explicitly granted it) can perform this.

Every technical control in a security programme can be circumvented if an attacker can convince a person with legitimate access to take an action on their behalf. Social engineering is the discipline of that manipulation — exploiting human psychology rather than software vulnerabilities. It is consistently one of the most effective attack vectors in real-world compromises and the hardest to defend against through purely technical means.

Why Social Engineering Works — Cognitive Biases

Effective social engineering exploits cognitive shortcuts that are rational under normal conditions but become vulnerabilities when deliberately triggered. Understanding these is what separates a social engineer from someone who just lies:

• Authority — people comply with requests from perceived authorities (executives, IT support, auditors, law enforcement) without verifying identity. "This is James from IT security, I need your credentials to update your account" works because the authority framing bypasses the verification instinct.
• Urgency — time pressure degrades careful decision-making. "Your account will be locked in 15 minutes unless you verify now" creates urgency that prevents the target from pausing to question the request.
• Social proof — people follow what others are doing. "The rest of your team has already completed this security verification" implies that compliance is the norm and non-compliance is unusual.
• Reciprocity — people feel obligated to return favours. An attacker who provides something helpful first (resolves a minor issue, shares useful information) creates a felt obligation that is then exploited.
• Liking — people comply more readily with requests from people they like or find similar to themselves. Building rapport through shared interests, mutual acquaintances, or simply being friendly significantly increases compliance rates.
• Scarcity — perceived scarcity increases value and urgency. "This security update is only available today" triggers action that "update your software when you have time" doesn't.

Phishing Campaign Management with GoPhish

GoPhish is the standard open-source phishing simulation framework. It manages the operational elements of a phishing campaign: sending phishing emails to a target list, hosting credential-capturing landing pages, and tracking who clicked, who submitted credentials, and who reported the email.

A 21% credential submission rate is sobering but realistic for a well-constructed pretext against an untrained population. The CFO and IT administrator credentials captured represent immediate critical-severity findings — those accounts, if compromised in a real attack, would provide either financial fraud capability or full technical access to the environment.

Vishing — Voice Phishing

Vishing uses phone calls as the attack vector. The attacker impersonates a trusted entity — IT support, the CEO's assistant, a vendor, an auditor — and manipulates the target into taking an action (revealing credentials, installing software, transferring funds, granting access).

Physical Security Testing — Tailgating and USB Drops

Physical penetration testing assesses whether an attacker could gain physical access to secure areas — server rooms, executive offices, network closets — through social engineering at physical entry points.

Tailgating — following an authorised person through a secure door without using your own credentials. Effective pretexts: carrying heavy boxes (people hold doors without thinking), wearing high-visibility vests or uniforms associated with maintenance or delivery, timing entry during busy periods when badge checking is lax.

USB drop attacks — placing USB drives in locations where target employees will find and plug them in. The drives contain payloads that execute automatically when connected. A well-documented experiment found that 48% of drives dropped in a university car park were plugged into computers within 24 hours.

Wireless penetration testing assesses whether an attacker positioned in physical proximity to the target — in the car park, a neighbouring office, or public space — can gain access to the wireless network and from there to internal systems. The realistic attacker model matters here: a nation-state may use directional antennas from hundreds of metres; a casual attacker needs to be within typical Wi-Fi range (30–100 metres).

WPA2-PSK — 4-Way Handshake Capture and Cracking

The most common wireless attack against WPA2-Personal networks captures the 4-way handshake exchanged during client authentication and cracks it offline against a wordlist. The network password is never transmitted — but the handshake contains enough information to verify password guesses without further network interaction.

PMKID Attack — No Client Required

The PMKID attack (discovered 2018) extracts a PMKID value from a single EAPOL frame sent by the access point, without needing to capture a client handshake. This makes it viable even when no clients are currently connected to the network.

WPA2-Enterprise — EAP Credential Capture with hostapd-wpe

WPA2-Enterprise uses 802.1X authentication — each user authenticates with their own credentials rather than a shared key. This is more secure than PSK but creates a different attack surface: the EAP exchange between client and RADIUS server can be targeted with an evil twin access point that captures credential material.

Post-exploitation is what happens after the initial shell. Having a shell on a system is not the objective — it is the beginning. The objective is to demonstrate the real-world impact an attacker could achieve: access to sensitive data, privilege escalation to administrator or domain admin, lateral movement to additional systems, or persistent access that survives reboots and password changes.

Situational Awareness — First Steps After a Shell

The first minutes after gaining access are critical. Before doing anything else, understand where you are, who you are, and what you can reach.

Linux Privilege Escalation — SUID and Sudo

Windows Privilege Escalation — Token Impersonation

Mimikatz — Credential Harvesting

Persistence Mechanisms

The penetration test report is the deliverable that clients actually pay for. Every finding you discovered, every shell you caught, every hash you cracked — none of it has value to the client unless it is communicated in a way that drives remediation. A technically brilliant engagement with a poorly written report is a waste. A thorough, clearly written report that accurately conveys risk and provides actionable remediation guidance has lasting value. Reporting is a craft, not an afterthought.

Report Structure

A professional penetration test report has four major sections, each serving a different audience:

1. Executive Summary — written for non-technical decision-makers (CISO, CEO, board). No jargon. Business impact language. Three to five paragraphs covering: overall security posture, most critical findings in plain English, risk to the business, and the three to five remediation priorities that matter most. A CFO should be able to read this and understand whether the business has a serious problem.
2. Scope and Methodology — what was tested, when, from what perspective (black/grey/white box), using what frameworks. Establishes the context for interpreting the findings.
3. Findings — the technical core. Each finding documented with consistent structure. Ordered by severity (critical first).
4. Appendices — tool output, full nmap scans, raw evidence that supports findings but is too detailed for the main body.

The Anatomy of a Good Finding

CVSS Scoring — How to Use It Correctly

CVSS (Common Vulnerability Scoring System) provides a standardised numerical score for vulnerability severity. The v3.1 base score considers: Attack Vector (network/adjacent/local/physical), Attack Complexity (low/high), Privileges Required (none/low/high), User Interaction (none/required), Scope (unchanged/changed), Confidentiality/Integrity/Availability Impact (none/low/high).

Writing the Executive Summary

The core penetration testing methodology applies across all domains, but certain environments require specialised tools, techniques, and knowledge. Cloud infrastructure has a fundamentally different attack surface from on-premises. APIs have vulnerabilities unique to their architecture. Mobile applications require different tooling than desktop software. This chapter provides substantive coverage of each specialisation — enough to begin work in each area and to understand where specialised training is needed.

Cloud Penetration Testing

Cloud pentesting targets the customer's security configuration — not the cloud provider's infrastructure. The cloud provider's infrastructure is out of scope by definition (and by provider policy). What is in scope: IAM configurations, storage bucket permissions, network security groups, Lambda functions, Kubernetes cluster security, and the inter-service trust relationships that create privilege escalation paths.

API Penetration Testing

Modern applications expose functionality through APIs — REST, GraphQL, gRPC. API vulnerabilities follow the same classes as web vulnerabilities but have distinct manifestations. The OWASP API Security Top 10 provides the framework: BOLA (Broken Object Level Authorisation — the API equivalent of IDOR), Broken Authentication, Broken Object Property Level Authorisation, Unrestricted Resource Consumption, Broken Function Level Authorisation, Unrestricted Access to Sensitive Business Flows, SSRF, Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs.

Mobile Application Testing

Mobile application testing combines static analysis (examining the application package without running it), dynamic analysis (testing the running application), and network traffic analysis (intercepting API calls between the app and its backend).

Reading about penetration testing builds vocabulary and mental models. Actual penetration testing skill comes from hours of practice — breaking intentionally vulnerable machines, building and breaking lab environments, working through real CVEs, and eventually taking on real engagements. This chapter maps the most efficient path from knowledge to employable skill, including the certifications that signal competence to employers and the resources that build it most efficiently.

Certifications — The Honest Assessment

Preparing for OSCP — The Realistic Path

OSCP requires rooting a set of machines in 24 hours and writing a professional report within the following 24 hours. The exam is genuinely difficult and has a meaningful failure rate. The preparation path that produces the highest success rate:

1. TryHackMe — "Jr Penetration Tester" path — 6–8 weeks. Builds foundational knowledge across every domain covered in this module.
2. HackTheBox — complete 30+ machines including retired machines with official writeups. Focus on Linux and Windows privilege escalation, Active Directory, and web applications.
3. OffSec PEN-200 course materials — the official OSCP preparation material. Read everything, complete all exercises.
4. OffSec Proving Grounds — 70+ practice machines provided with OSCP enrollment. Do all of them.
5. TJ_Null's OSCP-like machine list — a curated list of HackTheBox/VulnHub machines that closely resemble OSCP exam machines. Work through as many as possible.

CTF Platforms — Building Real Skill

Bug Bounty — Real-World Experience and Income

Bug bounty programmes pay independent researchers for discovering and reporting vulnerabilities within defined scope. The major platforms are HackerOne, Bugcrowd, and Intigriti. The realistic picture:

• Top researchers earn six figures annually from bug bounty — this is exceptional, not typical
• Most researchers earn sporadically and unpredictably — it is not a reliable income replacement until you have a track record of significant findings
• Bug bounty is excellent as a supplement to other income and as a mechanism for building skills on real systems with real scope
• Start with large programmes with broad scope and a history of paying reasonable amounts (Google VRP, Apple Security Bounty, Microsoft MSRC) rather than small programmes that may dispute or not pay
• IDOR and information disclosure bugs are the highest-probability findings for new researchers — practise web application testing before beginning bounty work

Staying Current

The penetration testing landscape changes continuously — new techniques, new tools, new CVEs, new defensive controls to bypass. The practitioners who stay sharp:

• Blogs and write-ups — 0xdf.gitlab.io (HackTheBox write-ups), ired.team (red team notes), harmj0y.net (AD attacks), s3cur3th1s.github.io, posts on Medium's InfoSec community
• Twitter/X security community — follow practitioners who share techniques: @harmj0y, @_dirkjan, @gentilkiwi (Mimikatz author), @orange_8361, @TomNomNom
• Conferences — DEF CON (Las Vegas, August) and its CFP villages; Black Hat USA/Europe; BSides events (local, affordable, community-focused)
• Podcasts — Darknet Diaries (attack stories); Smashing Security; Risky Business (security news)
• Practice continually — the most important factor is simply spending time breaking things; reading about techniques without practising them produces knowledge, not skill