CYBER-03-003-P · Primer — Sniffing, Spoofing, and Man-in-the-Middle

The idea in one sentence

A network was built to move packets, not to prove who sent them — so an attacker who can get onto the wire between two machines can quietly read the traffic (sniffing), forge their way into the middle of it (spoofing), and once there, take over a logged-in session as if they were you (hijacking), all without ever guessing a password.

Why it exists

The early Internet was designed by people who trusted each other. The core protocols — Ethernet, ARP, IP, TCP — were built to answer one question well: how do we get this packet to the right machine? They were never built to answer the other question: how do we know this packet is really from who it claims? Authentication and encryption weren't in the original job description; they got bolted on later, protocol by protocol, and huge amounts of traffic still travel without them.

That original trust leaves three gaps an attacker walks straight through.

First, a shared or accessible network medium means packets are visible. On old hubbed Ethernet or on open Wi-Fi, every frame reaches every listener; the network interface is simply polite enough to ignore frames not addressed to it. Flip it into promiscuous mode and it stops ignoring them — now it hands your operating system everything it hears. That's sniffing: not breaking in, just listening to conversations that were broadcast in the clear.

Second, the protocols that steer traffic take claims at face value. ARP (RFC 826) maps an IP address to a hardware MAC address by asking the room and believing the answer, with no verification at all. IP packets carry a source address that anyone can write to anything. So an attacker can lie about who they are and the network dutifully re-routes traffic to them.

Third, once traffic flows through an attacker, the session riding on top is exposed. A logged-in web session is held together by a cookie or a TCP connection — a token that says "this is still the same authenticated user." Steal or ride that token and you are that user, no login required.

These aren't exotic zero-days. They're the predictable consequence of a network that moves bytes faithfully and questions nothing.

How it works

Think of it as three escalating capabilities. Each one builds on the last.

1. Sniffing — reading what's already on the wire. A packet capture tool (Wireshark and its command-line sibling tshark, both built on the libpcap/WinPcap capture library) puts the network card into promiscuous mode and copies every frame it sees up to the analyst. On a hub or open Wi-Fi, that's everyone's traffic. The attacker filters for the interesting parts: an HTTP login posted over plain http://, a telnet or FTP password, a DNS query revealing which bank you use. Sniffing is completely passive — it sends nothing, so it's nearly invisible. Its limit is also its nature: on a modern switched network, the switch only sends each machine the frames actually addressed to it, so a sniffer sees its own traffic and broadcasts, not the victim's. To see more, the attacker has to stop being passive.

2. Spoofing — forging identity to redirect traffic. This is how the attacker beats the switch. The classic move is ARP spoofing (also called ARP cache poisoning). The attacker broadcasts forged ARP replies: one telling the victim "the gateway's IP belongs to my MAC," and one telling the gateway "the victim's IP belongs to my MAC." Because ARP has no authentication, both believe it and update their caches. Now every packet between victim and gateway is delivered to the attacker's machine first. IP spoofing is the same trick one layer up — writing a false source IP into packets — used to impersonate a trusted host or hide the origin of an attack. Spoofing turns a passive listener into an active participant who has inserted themselves into the path.

3. On-path interception (Man-in-the-Middle) — sitting in the conversation. Once ARP spoofing has redirected traffic, the attacker enables IP forwarding so packets still reach their real destination — the victim's connection keeps working, which is what keeps the attack quiet. But now everything passes through the attacker, who can read it, log it, or modify it in flight: strip HTTPS down to HTTP, inject a script into a web page, swap a bank account number in a form. This is the "man-in-the-middle" (also called on-path) position. The victim thinks they're talking to the server; the server thinks it's talking to the victim; both are actually talking to the attacker.

4. Session hijacking — becoming the authenticated user. From the middle, the attacker doesn't need the password — they need the proof of login. For web apps, that's the session cookie; capture it and replay it, and the server treats the attacker's browser as the already-authenticated user. For raw TCP, the equivalent is knowing the connection's sequence numbers: an attacker who can see or predict them can inject their own packets into the stream, so their commands land as if typed by the legitimate user. This is exactly the threat RFC 6528 addresses by making TCP initial sequence numbers hard to guess from off the path — which is why an on-path attacker who can simply read the numbers is so much more dangerous than one who has to predict them.

The through-line: read → forge → intercept → impersonate. Each stage removes one more thing the attacker needed to know.

The one gotcha

Encryption is what actually stops this — but only end-to-end, and only if you don't click through the warning. None of the network-level defenses fully close these gaps: switches don't stop ARP spoofing, and ARP itself can't be authenticated. The real fix is that the content be encrypted end-to-end (HTTPS/TLS), so even an attacker sitting perfectly on-path sees only ciphertext and can't forge messages. But here's the trap: a man-in-the-middle can present their own TLS certificate and try to decrypt-and-re-encrypt. TLS defends against this by having the browser verify the certificate against a trusted authority — so the attack surfaces as a certificate warning. The entire security of that channel now rests on the human not clicking "proceed anyway." The gotcha is that people are trained by years of expired-cert nags to click through, handing the attacker exactly the plaintext TLS was designed to deny them. Encryption doesn't fail here — the warning gets ignored. (Defenses like HSTS, which forbids the browser from downgrading to HTTP, and certificate pinning exist precisely to take that fatal click away from the user.)

See it — an on-path attacker reads, then rides, a session

sequenceDiagram
    autonumber
    participant V as Victim
    participant A as Attacker (on-path)
    participant G as Gateway / Server
    Note over A: Sniffing sees only<br/>own traffic on a switch
    A->>V: Forged ARP - "gateway IP<br/>= my MAC"
    A->>G: Forged ARP - "victim IP<br/>= my MAC"
    Note over V,G: Both caches poisoned -<br/>traffic now routes via A
    V->>A: Login request (thinks<br/>it is talking to G)
    A->>G: Forwards it on -<br/>connection still works
    G-->>A: Response + session cookie
    A-->>V: Forwards response,<br/>A keeps a copy of cookie
    Note over A: Replays cookie -<br/>A is now the logged-in<br/>user

The one-line takeaway

A network moves packets faithfully but trusts every claim blindly — so an attacker on the wire can read the clear traffic, forge their way into the middle, and ride a live session, which is why end-to-end encryption you never click past is the defense that matters.

Where you'll meet it

You'll meet sniffing the first time you open Wireshark on your own laptop and watch your traffic scroll by — a quietly alarming demonstration of how much used to travel in the clear. You'll meet spoofing and MITM in any hands-on security course or CTF, usually via a tool like Ettercap or arpspoof on a lab network, and you'll feel why coffee-shop Wi-Fi makes security people nervous. On the defensive side, you'll meet the countermeasures as real product features: Dynamic ARP Inspection and DHCP snooping on managed switches, ingress filtering per RFC 2827 (BCP 38) to blunt IP spoofing at the network edge, and the browser padlock, HSTS, and certificate pinning that make on-path interception visible. Interviewers love this cluster because it forces you to connect layers: "Why doesn't a switch protect you from a sniffer?", "How does ARP spoofing actually redirect traffic?", "If everything's on HTTPS, what's left for a man-in-the-middle to do?" The strong answer walks the chain — read, forge, intercept, impersonate — and lands on the one defense that holds: encryption the user is never tempted to bypass.

Named concepts: packet capture and eavesdropping, ARP/IP spoofing, on-path interception, session hijacking