Attacker Positions on the Network

TL;DR: Ask where the attacker sits. On the local link they can spoof ARP or DHCP or run an evil twin. In name resolution they can forge answers, run the resolver or hijack the domain. In routing they can announce your prefixes. As a trusted intermediary they hold a root your client trusts. Each position gives the ability to read and change unprotected traffic. TLS with certificate validation neutralises all of them, unless the attacker can make the client trust their certificate. So defend twice: keep attackers out of position, and make position useless through authentication.

Before you read

Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.

1. 1An attacker on café Wi-Fi successfully poisons a victim's ARP cache and sits between the victim and the router. The victim visits their bank, which uses HTTPS with HSTS. What can the attacker do?

   Commit to a guess, then reveal

Why position is the right first question

Most network attack names (ARP spoofing, DNS cache poisoning, BGP hijacking, evil twin, SSL stripping) describe a technique for getting into position. Once there, every one of them gives the attacker the same small set of powers: observe, modify, inject, drop, delay. So a strong answer to any "man in the middle" question has two halves:

1. How did the attacker get into position, and what control would have kept them out? That is where switch features, Wi-Fi configuration, DNSSEC and RPKI live.
2. Once in position, what could they actually do to this traffic? That is where authentication lives: TLS, SSH host keys, signed DNS, mutually authenticated tunnels.

Candidates who only answer the first half sound like they are reciting a list of attacks. Candidates who only answer the second sound like "just use TLS" and miss everything TLS does not cover: metadata, availability, plaintext legacy protocols and the moment before authentication starts.

On-path and off-path

An on-path attacker sees packets and can modify them: someone on the same Wi-Fi after ARP spoofing, a malicious access point, an ISP, a compromised router, a cloud provider's network. An off-path attacker cannot see traffic and must guess: forging DNS responses by racing the real one, injecting into a TCP connection by guessing sequence numbers. The distinction decides which defences matter.

Most protocol hardening from the 1990s and 2000s is about off-path attackers: random TCP initial sequence numbers, random DNS transaction IDs and source ports, and RFC 5961's tighter rules for accepting TCP resets. It raises the cost of guessing. None of it does anything against an attacker who can read the packet. On-path attackers are handled by cryptography, and only by cryptography.

Worked example: how much does randomisation buy?

A DNS resolver sends a query and accepts the first reply whose 16-bit transaction ID and UDP port match. Suppose an off-path attacker can land 100 forged replies inside the window before the real answer arrives.

The first row is why the 2008 Kaminsky disclosure was an emergency. His technique let an attacker start a fresh race every time by querying random, non-existent subdomains, so the cached-answer TTL no longer limited the number of attempts, and a 78% success rate after 1,000 races is a matter of minutes. Source-port randomisation, deployed across resolvers that summer, moved the problem to the second row. The lesson for interviews: randomisation turns a practical attack into an impractical one only against an attacker who cannot see the traffic, and researchers keep finding side channels that leak the randomised value back (the 2020 "SAD DNS" work inferred the source port through ICMP rate-limit behaviour). Authentication of the answer, through DNSSEC or an encrypted channel to a trusted resolver, does not depend on the attacker staying blind.

The four positions at a glance

Position 1: the local link

Protocols on a LAN were designed for a building full of colleagues. They answer questions from anyone and believe answers from anyone.

ARP. IPv4 hosts find the MAC address for an IP by broadcasting "who has 10.0.0.1?" and caching whatever reply arrives. ARP (RFC 826, 1982) has no authentication, and most stacks also accept unsolicited ("gratuitous") replies, which exist so a host can announce a changed address. An attacker on the segment tells the victim "10.0.0.1 is at my MAC" and tells the gateway "the victim is at my MAC". Both now send frames through the attacker, who forwards them so nothing appears broken.

DHCP. A rogue DHCP server that answers faster than the real one hands the victim an attacker-chosen gateway and DNS resolver, which is a cleaner position than ARP spoofing because it survives for the whole lease. A related trick exhausts the real server's pool with forged requests so only the rogue server has addresses left.

IPv6 router advertisements. This is the one candidates forget. Modern operating systems enable IPv6 by default and prefer it, even on networks the operators think of as IPv4-only. A host that hears a router advertisement will configure an IPv6 address and route, and often a resolver, from whoever sent it. An attacker on an "IPv4-only" segment can therefore become the IPv6 gateway and DNS server for every host on it. RA Guard (RFC 6105) on switch ports, or disabling IPv6 deliberately rather than by assumption, closes it.

Wi-Fi. An evil twin broadcasts a familiar network name. Clients that auto-join by name connect to it, and the attacker now runs DHCP, DNS and the gateway at once. Two details decide how bad this is:

• Deauthentication. Management frames in older Wi-Fi were unauthenticated, so an attacker could forge "disconnect" frames to push clients off the real access point and onto the twin. Protected Management Frames (802.11w) authenticate those frames, and WPA3 makes them mandatory.
• Enterprise authentication. WPA2/WPA3-Enterprise uses 802.1X with an EAP method. Methods such as PEAP and EAP-TTLS run a TLS tunnel to the authentication server and then send the user's credential inside it. If the client profile does not pin the server's CA and name, the evil twin presents any certificate, the client accepts it, and the attacker receives credential material (for MSCHAPv2, a challenge-response that can be attacked offline). EAP-TLS uses client certificates, so there is no password to steal.

Defences that remove the position. Dynamic ARP inspection checks ARP replies against the IP-to-MAC bindings that DHCP snooping recorded, and drops mismatches; DHCP snooping only lets DHCP server messages in through ports marked trusted (the uplinks). Static hosts need explicit ARP ACLs, because they never appear in the DHCP binding table. 802.1X on wired ports stops an unknown device getting a port at all. Client isolation on guest Wi-Fi stops one client talking to another, which removes ARP spoofing between guests.

Position 2: name resolution

Change what a name resolves to and every client that looks it up walks to the attacker. The routes in:

• Forge answers to a resolver (the off-path race above), or sit on-path and answer first.
• Run the resolver: the rogue DHCP server, the evil twin and the malicious router all hand out their own.
• Take the domain: phish the registrar account, social-engineer a transfer, or compromise the DNS hosting provider. This is the highest-impact version, because the attacker now controls the authoritative answer, which DNSSEC will sign for them if they hold the provider account.
• Dangling records: a CNAME still points at a deprovisioned cloud resource that an attacker can claim, and they serve content under your name.

Taking the domain also lets the attacker pass the domain-validation checks that certificate authorities use, so they can get a valid certificate. That is why registrar lock, MFA on the registrar and DNS provider, CAA records and Certificate Transparency monitoring belong in the same answer. The DNS security lesson covers resolution in depth.

Position 3: routing

The internet's routing system, BGP, works on trust between networks (autonomous systems, ASes). Each AS announces the address blocks (prefixes) it can reach, and routers forward packets along the longest matching prefix. Two consequences follow:

• Origin hijack. An AS announces a prefix it does not hold. Networks that prefer the attacker's path, usually those topologically closer to it, send traffic there.
• More-specific hijack. The attacker announces a narrower prefix, such as two /24s inside your /23. Longest-prefix match prefers the narrower route everywhere, regardless of path length, so this is far more effective. Many networks filter IPv4 announcements longer than /24, which is why defenders announce their critical services as /24s: there is no more-specific left to steal.
• Route leak. A network re-announces routes it learned from one provider to another, in violation of routing policy. No malice is needed; traffic detours through a network that cannot carry it, or that can read it.

Two public incidents are worth knowing. In February 2008, Pakistan Telecom announced a more-specific route for a YouTube prefix to block the site domestically; the announcement leaked to its upstream and took YouTube offline for much of the internet for around two hours. In April 2018, attackers hijacked IP space belonging to Amazon's Route 53 DNS service and answered queries for a cryptocurrency wallet site with their own server. The decisive detail for an interview: the fake site presented a certificate browsers did not trust, and the theft worked because users clicked through the warning. In February 2022 the KLAYswap attack went one step further: attackers hijacked a BGP prefix used by Kakao's developer infrastructure for about two hours, answered a certificate authority's domain-validation checks from the hijacked addresses, obtained a valid certificate for the domain that served a JavaScript SDK, and served modified code to the exchange's users without any browser warning. Losses were reported at around $2 million.

That case is why certificate issuance now has its own routing defence. Since 2025 the CA/Browser Forum's Baseline Requirements oblige CAs to perform multi-perspective issuance corroboration: domain validation and CAA checks must succeed from several network vantage points, spread across regions, so a hijack visible from one part of the internet cannot pass on its own. The floor is four remote perspectives today and five from 15 December 2026.

Defences. RPKI lets the holder of a prefix publish a signed Route Origin Authorisation (ROA) saying which AS may originate it and how specific an announcement may be (the maxLength). Networks that perform Route Origin Validation drop announcements that contradict a ROA. ROV (RFC 6811, with ROAs profiled in RFC 9582) stops origin and more-specific hijacks, provided the ROA's maxLength is set tightly; a loose maxLength re-opens the more-specific attack under a "valid" origin. ROV does not stop an attacker who forges the path while keeping the correct origin AS at the end; path validation (ASPA) is still being standardised and deployed. Monitoring services that alert when your prefixes are announced from an unexpected origin cover the gap, and they tell you about leaks too.

Position 4: the trusted intermediary

The first three positions let an attacker relay bytes. This one lets them terminate TLS, because the client trusts a certificate the attacker controls.

• Inspection proxies. Many enterprises install their own root on managed devices so a proxy can decrypt outbound TLS. That is a legitimate position with a real cost: the proxy becomes the most valuable credential store in the company, its TLS validation of the real server must be at least as strict as the browser's, and pinned or mutually authenticated clients break.
• Rogue roots. Software that installs its own root CA turns every machine it runs on into an interception target. The 2015 Superfish case was the worst form: adware preinstalled on consumer laptops added a root whose private key was the same on every machine, so anyone who extracted it could intercept TLS on all of them.
• Mis-issuance. A CA that is compromised or deceived issues a certificate for your name. DigiNotar (2011) issued fraudulent certificates, including one for Google domains that was used against users in Iran, and was removed from browser trust stores and went bankrupt. Certificate Transparency exists because of cases like this: publicly trusted certificates must be logged, so a domain owner can see every certificate issued for their names. CAA records tell CAs which of them may issue for the domain.

Why authentication beats position

TLS's confidentiality and integrity depend on authentication: the server must prove possession of a private key for a certificate the client trusts for that hostname. An attacker in any position can relay bytes but cannot produce that proof. Attacks succeed only when authentication is skipped or fooled:

• Users click through warnings (HSTS makes warnings final).
• The first request goes over plain HTTP (SSL stripping; HSTS and preloading).
• Software disables verification.
• The client trusts the attacker's certificate (rogue root, mis-issuance).

The same reasoning applies outside the web. SSH is safe against every position here after the first connection, because the client remembers the host key; the first connection is trust-on-first-use, and a user who accepts a changed-key warning has handed the attacker the session. WireGuard and IPsec with certificate or pinned-key authentication are safe from the start, because the peer's key is configured, not discovered.

The gap before authentication: downgrade and stripping

Authentication only helps once it starts. An on-path attacker's best move is to stop it starting:

• SSL stripping. A user types bank.example, the browser tries HTTP first, and the attacker answers the HTTP request themselves while talking HTTPS to the bank. The user never sees a certificate error because there was never a TLS connection to fail. HSTS (RFC 6797) tells the browser to use HTTPS only for the domain for max-age seconds; the HSTS preload list, built into browsers, closes the very first visit too.
• STARTTLS stripping. Mail servers upgrade a plaintext SMTP connection to TLS with a STARTTLS command, advertised in the server's plaintext greeting. An on-path attacker deletes the advertisement, and the sending server, which by default does not require TLS, delivers in plaintext. MTA-STS (RFC 8461) and DANE let a domain publish "always use TLS with a valid certificate" so that senders refuse to downgrade.
• Protocol downgrade. Older TLS versions let an attacker interfere with version negotiation. TLS 1.3 signs the whole handshake transcript and includes a downgrade sentinel in the server random, so a client that supports 1.3 detects an attempt to push it to 1.2.

The general rule: any security property that is negotiated in the clear can be negotiated away by an on-path attacker, unless the result of the negotiation is later authenticated or the requirement is pinned in advance.

What position still gives the attacker

Even against perfect TLS: metadata (addresses, timing, sizes, often the server name and DNS queries), the ability to block or degrade service, and full access to anything not using authenticated encryption, such as legacy internal protocols, plaintext email between servers without TLS, and unauthenticated management interfaces.

Two of those deserve more than a bullet:

• Metadata is information. Which hosts a laptop contacts, when and how much, reveals software in use, update cadence, VPN endpoints and often which page of a site was loaded, because sizes are distinctive. Encrypted DNS hides queries from the local network, and Encrypted Client Hello hides the server name in TLS, but neither hides the destination IP address or traffic volume.
• Availability is never protected by TLS. A BGP hijack against well-validated clients is still a full outage for its duration. Detection and the ability to respond (announcing more-specifics, working with upstreams) is the defence.

Detecting an attacker in position

Prevention is the goal, but each position leaves traces a defender can watch:

Worked example: an airport lounge

An employee's laptop joins "Lounge-WiFi", which is an evil twin. The attacker runs DHCP, DNS and the gateway.

• Corporate apps through an identity-aware proxy over TLS: protected.
• The employee's personal webmail with HSTS preloaded: protected.
• An internal tool reached by IP over HTTP through split-tunnel VPN misconfiguration: exposed.
• A PEAP Wi-Fi profile that accepts any server certificate, used when the laptop also probes for the corporate SSID: credential material exposed to the evil twin.

Walk it one layer further and the answer becomes a design review:

• What the attacker learns without breaking anything: every hostname the laptop resolves through the attacker's DNS (unless the OS uses encrypted DNS to a fixed resolver), the VPN endpoint, and the timing of every sync.
• What they can change: the plaintext internal tool's responses, so a download from it could be replaced. Anything fetched over HTTP, including old update channels, is now attacker-controlled code.
• What breaks loudly: a pinned mobile app or a client that uses mTLS simply fails to connect. Loud failure is the success case.

The fixes are authentication everywhere, strict server validation in Wi-Fi profiles, and no plaintext paths. In order of value: an always-on VPN or identity-aware proxy so no corporate traffic depends on the local network, Wi-Fi profiles that pin the RADIUS server's CA and name (or EAP-TLS), and retiring the HTTP-only internal tool.

Misconceptions interviewers listen for

• "HTTPS means a man in the middle can't do anything." They still get metadata, can block, and own every plaintext path and every first HTTP request without HSTS.
• "We're IPv4-only, so IPv6 attacks don't apply." Hosts speak IPv6 by default; an attacker can introduce it.
• "WPA2 with a strong password stops evil twins." A pre-shared key shared by every guest lets any guest impersonate the network. The key protects against outsiders, not other key holders.
• "RPKI stops BGP hijacks." It stops origin hijacks for prefixes with ROAs, at networks that enforce ROV, with tight maxLength. Path forgery and leaks remain.
• "Randomisation fixed DNS poisoning." It fixed off-path guessing. On-path forgery, resolver compromise and domain takeover were never in its scope.

What if · interview follow-ups

Hold your answer as the constraints change

You are reviewing a remote-work setup. Employees use laptops on home and public Wi-Fi to reach SaaS apps over HTTPS and a few internal web tools over a VPN. The interviewer asks what an attacker on the same Wi-Fi can do, then changes one thing at a time.

1. 1

   Start here

   What if the attacker has successfully ARP-spoofed the laptop and sees all its traffic?

   Nudge meAnswer it out loud, then reveal

Revising, not practising? Show every answer

How this shows up in interviews

MITM, DNS, BGP, Wi-Fi and "what happens when you type a URL" questions all reduce to: where can the attacker sit, what can they do there, and which authentication step defeats them. Expect the interviewer to move the attacker between positions, as in the ladder above, and to probe the edges where authentication has not started yet: the first request, the first SSH connection, STARTTLS, Wi-Fi enrolment.

Say it in 30 seconds: "I think about where the attacker sits: the local link, DNS, routing, or a trusted intermediary. Each lets them read and change unprotected traffic. TLS with proper certificate validation makes all of those positions useless, because they can't prove they're the server, so most real MITM is about skipped validation: click-through warnings, HTTP first requests, disabled verification or a rogue trusted root. I defend both ways: keep them out of position and make position worthless."

Check yourself

Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.

1. 1Why are random DNS query IDs and source ports a defence against off-path attackers but not on-path ones?

   Answer it, then reveal

2. 2A BGP hijack sends traffic for your API's IP range to an attacker for an hour. What determines whether user data was exposed?

   Answer it, then reveal

3. 3Your network team says the guest VLAN is IPv4-only, so IPv6 attacks are out of scope. What do you say?

   Answer it, then reveal

4. 4Why does announcing your critical prefix as a /24 help against BGP hijacks?

   Answer it, then reveal

5. 5Name one security property that an on-path attacker can remove simply because it is negotiated in plaintext, and its fix.

   Answer it, then reveal