MITM and interception
Interception only works when the attacker sits on the traffic path. ARP spoofing and TLS stripping put them there; authenticated TLS plus integrity collapses that position into a useless, detected link.
Everything here is lab-and-authorization-only. Putting yourself between two parties on a network you don’t own — sniffing, redirecting, or stripping someone else’s traffic — is interception, and in most jurisdictions that’s a crime regardless of intent. This lesson teaches the mechanism so you can break it as a defender: stand it up in an isolated lab or a CTF range, against hosts you control and have written scope for, and never on production or a network you’re a guest on. The whole point is that once you understand why interception works, you understand exactly which property a defender adds to make it fail.
By the end of this lesson you’ll know what an attacker must achieve to intercept traffic, the two classic ways they get there, and the single cryptographic property that turns a perfect on-path position into a useless one.
What “man-in-the-middle” actually requires
A man-in-the-middle (MITM) attack is one where the attacker sits between two communicating parties, relaying — and potentially reading or altering — every message, while each side believes it is talking directly to the other. The MITRE ATT&CK framework files this under Lateral Movement and the broader “Adversary-in-the-Middle” technique, because it’s almost never the first foothold — it’s something you do after you already have a position on the network.
That framing is the key insight a defender needs: interception is not magic, it’s a position. To read or tamper with a conversation, the attacker’s machine must physically or logically be on the path the packets travel. They do not get to reach into a TCP stream from across the internet. They have to become a hop. Everything an attacker does — ARP spoofing, rogue DHCP, evil-twin Wi-Fi, DNS spoofing, BGP hijack — is just a different way to answer the same question: how do I get the victim’s packets to flow through me? And everything a defender does is the inverse: assume the path is hostile and make a hostile path not matter.
Once an attacker holds that position, two outcomes are possible, and they’re very different in severity:
- Passive interception (eavesdropping): the attacker copies traffic as it passes. Confidentiality is lost. With plaintext protocols (HTTP, plain SMTP, unencrypted database wire protocols) this hands them credentials and data outright.
- Active interception (tampering): the attacker modifies traffic in flight — injecting, dropping, or rewriting messages. Now integrity is lost too: they can alter a bank transfer, inject a payload into an HTTP response, or strip a security upgrade.
How the attacker gets on the path: ARP spoofing
On a typical switched LAN, the most common way onto the path is ARP spoofing (also called ARP poisoning). ARP — the Address Resolution Protocol — is how a host on a local network maps an IP address to a MAC address so it can actually frame the packet for delivery. The fatal design property: ARP has no authentication. When a host asks “who has 192.168.1.1?”, any machine can answer, and hosts cache whatever reply arrives — even unsolicited ones (gratuitous ARP).
So the attacker, already on the LAN, sends forged ARP replies: it tells the victim “the gateway’s MAC is mine,” and tells the gateway “the victim’s MAC is mine.” Both caches now point at the attacker. Traffic that should go victim → gateway now goes victim → attacker → gateway, and back. The attacker forwards packets so the connection still works (otherwise the victim notices the outage), but every byte now passes through them. They’ve become a hop without touching a single cable.
Why TLS breaks it — and how TLS stripping tries to dodge that
Here is the property that matters. Properly used TLS gives you three things at once: confidentiality (the attacker sees ciphertext, not plaintext), integrity (any tampered byte fails the record’s authentication tag and the connection aborts), and — most importantly for MITM — authentication of the server. The client validates the server’s certificate against a trusted CA chain and checks that the name matches. An on-path attacker can copy the ciphertext all day, but they cannot present a valid, trusted certificate for bank.example they don’t have the private key for. If they try to terminate TLS themselves and re-originate it, the client gets a certificate that doesn’t chain to a trusted root — and throws a warning. So a correct TLS deployment converts the attacker’s perfect on-path position into a useless one: they hold the wire but not the keys.
That is exactly why the interesting attack isn’t breaking TLS — it’s avoiding it. TLS stripping (the classic “sslstrip” technique) is an active MITM that keeps the victim on plaintext HTTP. The user types bank.example and the browser first makes an HTTP request; the real site would respond with a redirect to https://. The on-path attacker intercepts that redirect, talks HTTPS to the real server itself, and serves the victim plain HTTP — rewriting https:// links to http:// as they pass. The victim’s browser shows a working page with no certificate error, because there’s no TLS on the victim’s side to error on. No certificate was forged; the encryption was simply never allowed to start.
▸Why this works
Why does TLS stripping fail against a modern site? Because the defense moved the trust decision off the network path. HSTS (HTTP Strict Transport Security) tells a browser, via a header it remembers, “for this domain, never speak plain HTTP again — upgrade to HTTPS before sending anything.” Once HSTS is cached (or, better, the domain is on the browser’s preloaded HSTS list shipped in the binary), the very first request is HTTPS, so there is no plaintext redirect for the attacker to intercept. The attacker’s whole technique depended on that one cleartext hop existing. HSTS deletes it.
How a defender reasons about the whole class
The senior move is to stop thinking “can someone get on my path?” — on a shared LAN, hostile Wi-Fi, or a compromised router, assume yes — and start thinking “what does on-path actually buy them?” If every sensitive channel is authenticated TLS with integrity, the answer is: ciphertext they can’t read, and tampering that aborts the connection instead of succeeding silently. That’s defense that doesn’t depend on trusting the network, which is the only kind that survives a hostile path. The network-layer hardening (dynamic ARP inspection on switches, 802.1X, DHCP snooping) raises the cost of getting on the path, but it’s the second line — useful, yet you never want your confidentiality and integrity to rest on the LAN staying clean.
In an authorized internal pentest you've achieved an ARP-spoofing on-path position between a workstation and the gateway. The target app is served over HTTPS with HSTS preloaded. Which conclusion should your report lead with?
ARP spoofing works because of which property of ARP?
Why does an on-path attacker fail to read a correctly deployed TLS session, even with a perfect interception position?
Order the stages of an ARP-spoofing-then-strip interception attempt, from getting on the path to where a hardened defense breaks it:
- 1 Attacker is already on the same LAN segment as the victim
- 2 Forged ARP replies poison the victim's and gateway's caches
- 3 Victim's traffic is rerouted through the attacker (on-path)
- 4 Attacker tries TLS stripping to keep the victim on plaintext HTTP
- 5 HSTS preload forces HTTPS first — no cleartext hop to strip; attack fails
- 01Explain why a man-in-the-middle attack is described as 'a position, not a power,' and walk through how ARP spoofing achieves that position.
- 02Why does correctly deployed TLS defeat interception, and what is TLS stripping trying to dodge — and how does HSTS shut it down?
Interception is a position, not a power. A man-in-the-middle must become a hop on the path the packets actually travel — MITRE files it under Lateral Movement for that reason — and ARP spoofing is the classic way in: ARP has no authentication, so forged replies poison the victim’s and gateway’s caches and reroute traffic through the attacker. Once on-path they can eavesdrop (lose confidentiality) or tamper (lose integrity). The thing that defeats this isn’t keeping attackers off the LAN — assume you can’t — it’s authenticated TLS with integrity: the attacker gets ciphertext they can’t read and any tampering aborts the connection, because they can’t forge a certificate they don’t hold the key for. That’s why the live technique is TLS stripping — avoiding TLS by keeping the victim on a cleartext HTTP hop — and why HSTS preload kills it by forcing HTTPS first so no cleartext hop exists. The next time you reason about a hostile network, your first question is no longer “can someone get on the path?” but “if they do, do they get plaintext — or ciphertext and a torn-down connection?”
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.