Lesson Notes
Threat Landscape Overview : MITM
Module 1: Foundations. Deep dive into Man-in-the-Middle (MITM) theory: what MITM is, why unencrypted traffic is vulnerable, attack types (ARP, DNS, SSL stripping, WiFi), how encryption and TLS defeat MITM, and detection. Beginner-friendly, no labs. Best after social engineering, MFA, and encryption.
Module 1: Foundations — Threat Landscape Overview : MITM
This lesson is a theory-only, beginner-friendly deep dive into Man-in-the-Middle (MITM) attacks. You will learn what MITM is, why unencrypted traffic is so vulnerable, the main types of MITM attacks, and how encryption and authentication defeat them. No labs here—place it after social engineering, MFA, and encryption so those ideas reinforce what you see here. Clear concepts before you pentest ethically.
1. Core Concept: What Is MITM?
Man-in-the-Middle (MITM) means an attacker secretly sits between two parties that think they are talking only to each other—for example, between your laptop and the website you are visiting, or between your device and the Wi-Fi router. The attacker can read, change, or inject data without either side knowing. Think of it like someone opening and reading your mail, then resealing it and sending it on: the sender and receiver believe the letter went straight from A to B, but a third party saw or altered it.
Key Characteristics of MITM
Transparency: The victim usually has no idea. The attacker relays traffic so everything looks normal. Targets: MITM works best on unencrypted or weakly protected channels—plaintext protocols like HTTP, Telnet, or FTP. If traffic is encrypted and the crypto is done right, the attacker sees only gibberish. Positioning: The attacker must be on the network path. That could mean the same Wi-Fi as you, control of a router, or even an ISP. So: public Wi-Fi, shared networks, and unencrypted web traffic are where MITM is a real risk.
Who Is Involved? (Threat Model)
Victim: You or your device, sending something sensitive (login, credit card, session cookie). Legitimate endpoint: The real bank, email server, or app server. Attacker goal: Steal credentials, inject malware, redirect you to a fake site, or downgrade security (e.g. force HTTP instead of HTTPS). Understanding this triangle—victim, real server, attacker in the middle—helps you see why "encryption + server identity" is the fix.
2. Why Unencrypted Traffic Is Vulnerable (The Mechanics)
When you send data over HTTP (or other plaintext protocols), every byte travels in the clear. Anyone who can see the traffic—on the same Wi-Fi, on a compromised router, or along the path—can read it. Example: You submit a login form with username=alice and password=secret123. That exact string goes over the wire. A tool like Wireshark can capture it and show the full POST body. So: no confidentiality. Worse, the attacker can change the data (e.g. replace the password with their own) and then forward it to the server—so no integrity either. And there is no built-in way to prove the server is really the bank and not a fake—no authenticity.
Contrast: What Encryption Does (In Theory)
Symmetric encryption (e.g. AES): Both sides share a secret key. Data is scrambled with that key; without the key, an attacker sees only ciphertext (gibberish). Asymmetric encryption (e.g. RSA, ECDH): The server has a public key and a private key. The client uses the public key to establish a shared secret; the private key never travels. That way, even if someone intercepts the handshake, they cannot derive the session key. TLS handshake (simplified): (1) Client says "Hello" and lists supported ciphers. (2) Server says "Hello" and sends its certificate (proof of identity). (3) They agree on a session key. (4) All application data (your login, cookies, etc.) is encrypted with that key. So once TLS is in place, a MITM who only captures packets sees encrypted blobs, not passwords.
Unencrypted Protocols at Risk (Quick Reference)
HTTP (port 80): Logins, cookies, form data—all visible. FTP (port 21): Username and password sent in clear text. Telnet (port 23): Every keystroke visible. SNMPv1/v2 (port 161): Network device configs and community strings. Any protocol that does not use encryption or strong authentication is vulnerable to eavesdropping and tampering on the path.
3. MITM Attack Types (Broken Down for Beginners)
ARP poisoning (Layer 2): Devices use ARP to map IP addresses to physical (MAC) addresses. ARP has no authentication—anyone can send a reply saying "The router at 192.168.1.1 has MAC address X." If the attacker sends "The router is at my MAC," your device will send traffic to the attacker instead. They can then relay it to the real router and see everything. Gratuitous ARP: Sending these fake replies repeatedly keeps the victim's traffic flowing through the attacker.
DNS Spoofing
DNS turns domain names (e.g. bank.com) into IP addresses. DNS queries and responses are often sent in the clear and are not cryptographically signed (unless you use DNSSEC). An attacker can poison the DNS cache or intercept queries and reply with a fake IP—e.g. "bank.com goes to 1.2.3.4" where 1.2.3.4 is the attacker's server. You think you are visiting the bank; you are actually sending your password to the attacker. Variants include cache poisoning (Kaminsky-style) and forged responses on the wire.
SSL/TLS Stripping (Downgrade)
You type https://bank.com, but the attacker intercepts the first request and serves you an HTTP version of the site instead—no lock icon, no encryption. Your browser might not complain if the site does not use HSTS (HTTP Strict Transport Security) or if it is your first visit. Tools like SSLStrip (or Bettercap) do this transparently: they sit in the middle, talk HTTPS to the real server and HTTP to you, and see all your data. Defense: Use only HTTPS, and prefer sites that use HSTS so the browser refuses to downgrade.
WiFi-Specific Attacks (Evil Twin, KRACK)
Evil Twin: The attacker sets up a Wi-Fi access point with the same name (SSID) as a real one—e.g. "CoffeeShop_WiFi." Your device may auto-connect to the stronger signal. All your traffic then goes through the attacker's AP. KRACK (Key Reinstallation Attack): A weakness in the WPA2 handshake allowed an attacker to force reuse of an already-used key, breaking encryption. Patches exist; keeping devices updated is critical.
Session Hijacking
After you log in, the server often gives your browser a session cookie. If that cookie is sent over HTTP (or a cookie without Secure and HttpOnly flags), anyone on the path can steal it. With the cookie, the attacker can pretend to be you—no password needed. Defense: Use HTTPS for the whole site and set cookies with Secure and HttpOnly so they are not sent over plain HTTP and are not readable by JavaScript.
4. Attack Lifecycle (What an Attacker Might Do)
Recon: Scan the network (e.g. nmap) or enumerate Wi-Fi (e.g. airodump-ng) to find targets and understand the environment. Positioning: Use ARP poisoning or DNS spoofing to get in the path of the victim's traffic. Interception: Capture traffic with tcpdump or Wireshark (or similar). Exploitation: Extract credentials, inject malicious content (e.g. JavaScript), or replace responses. Exfiltration: Send stolen data to the attacker's server. Persistence: Keep DNS or ARP poisoned so the victim keeps sending traffic through the attacker. As a defender or ethical pentester, you think in reverse: break this chain (encrypt, authenticate, detect) to stop MITM.
5. Why Encryption + Authentication Defeats MITM
TLS provides encryption (confidentiality) and certificate-based authentication (you are talking to the real server). Modern TLS 1.3 also uses Perfect Forward Secrecy (PFS): even if the server's long-term key is later stolen, past sessions cannot be decrypted because each session used a temporary key. The certificate chain (Root CA → Intermediate → Server cert) lets your browser verify that the server really owns the domain. If the attacker cannot get a valid cert for "bank.com," the browser will warn you. VPNs (e.g. IPsec, WireGuard) encrypt your entire IP traffic to a trusted endpoint, so even on hostile Wi-Fi, your data is inside an encrypted tunnel. Bottom line: ciphertext is indistinguishable to an attacker; replay and tampering are detected; padding and downgrade attacks are mitigated in TLS 1.3.
6. Detection (What Might Look Wrong)
Timing: Extra hop can add latency—unusual delays might indicate a MITM. ARP table: Duplicate IP addresses (e.g. two MACs for the same IP) can mean ARP poisoning—check with arp -a. Certificate warnings: If the browser says the certificate does not match the domain or is untrusted, stop—you might be talking to an impostor. Traffic volume: Unexpected relay traffic or odd patterns can be a sign. In practice, the best "detection" is prevention: use HTTPS everywhere and VPN on untrusted networks so there is nothing useful for a MITM to see.
7. Real-World Stats and Where Things Are Headed
Industry reports (e.g. Verizon DBIR) show a large share of credential theft and breaches involve unencrypted or weakly protected channels. A significant portion of attacks on public Wi-Fi have been linked to MITM-style interception. The trend is toward encryption by default: HTTP/3 (QUIC) mandates encryption, and HTTPS is the norm for the web. As a pentester: learn this theory, then in authorized labs test for unencrypted services, weak TLS, and missing HSTS—and report them so organizations can fix gaps.
Key Takeaway for Lesson 8
MITM is when an attacker sits between you and the service you use, reading or changing data. Unencrypted traffic (HTTP, FTP, Telnet, etc.) is vulnerable to eavesdropping and tampering. Attack types include ARP poisoning, DNS spoofing, SSL stripping, evil-twin Wi-Fi, and session hijacking. Encryption (TLS) plus server authentication (certificates) defeats MITM by hiding data and proving identity. Use HTTPS everywhere and a VPN on untrusted networks; in authorized pentests, find and report unencrypted or misconfigured services. Next: Threat Landscape — Malware and Ransomware.