What is a Man-in-the-Middle (MITM) Attack?

A Man-in-the-Middle (MITM) attack is a class of cyberattack where an adversary secretly positions themselves between two parties who believe they are communicating directly with each other. The attacker can eavesdrop on the conversation, alter messages in transit, or impersonate one side entirely — all without either party realizing the link has been compromised. MITM attacks operate at every layer of the network stack, from ARP on a local Ethernet segment to BGP at the scale of the global internet.

Understanding MITM attacks requires understanding the trust assumptions baked into internet protocols. Most foundational protocols — ARP, DNS, BGP — were designed in an era when every participant on the network was assumed to be cooperative. Attackers exploit this inherited trust to insert themselves into communication paths that were never designed to be adversarial.

The Anatomy of a MITM Attack

Every MITM attack follows a common pattern regardless of the specific technique: interception, then exploitation. First, the attacker redirects traffic so it flows through their system instead of going directly from sender to receiver. Second, they act on the intercepted traffic — reading credentials, injecting malware, modifying financial transactions, or simply collecting intelligence.

The power of a MITM attack lies in its invisibility. From the client's perspective, responses appear to come from the legitimate server. From the server's perspective, requests appear to come from the legitimate client. The attacker operates as an invisible relay, with full ability to read and modify traffic in both directions.

ARP Spoofing: MITM on the Local Network

The Address Resolution Protocol (ARP) maps IP addresses to MAC (hardware) addresses on a local network segment. When a device wants to send a packet to another device on the same LAN, it broadcasts an ARP request: "Who has IP 192.168.1.1? Tell me your MAC address." The device with that IP responds, and the sender caches the mapping in its ARP table.

ARP has zero authentication. Any device on the network can send an ARP reply claiming to own any IP address, and recipients will trust it unconditionally. This is ARP spoofing (also called ARP poisoning), and it is the most common MITM technique on local networks.

How ARP Spoofing Works

Consider a typical office or home network with a gateway router at 192.168.1.1 and a victim workstation at 192.168.1.50. The attacker's machine is also on the same LAN at 192.168.1.99:

1. The attacker sends a gratuitous ARP reply to the victim: "192.168.1.1 is at [attacker's MAC address]." The victim's ARP cache now maps the gateway's IP to the attacker's MAC.
2. The attacker simultaneously sends a gratuitous ARP reply to the gateway: "192.168.1.50 is at [attacker's MAC address]." The gateway's ARP cache now maps the victim's IP to the attacker's MAC.
3. All traffic between the victim and the gateway now flows through the attacker's machine. The attacker forwards packets in both directions to avoid detection while inspecting or modifying everything.

Tools like arpspoof (part of the dsniff suite) and ettercap automate this process. Once positioned, the attacker can use tools like mitmproxy or Wireshark to inspect all traffic, capture credentials sent over unencrypted protocols (HTTP, FTP, SMTP, Telnet), or inject malicious content into web pages.

Defenses: Dynamic ARP Inspection (DAI) on managed switches validates ARP packets against a trusted DHCP snooping table. Static ARP entries can be configured for critical gateways. At the host level, tools like arpwatch alert on unexpected ARP changes. Most importantly, encrypting traffic with TLS/HTTPS ensures that even if Layer 2 is compromised, the attacker sees only ciphertext.

DNS Spoofing and Cache Poisoning

DNS translates domain names to IP addresses, and corrupting this translation is one of the most effective ways to redirect traffic. DNS spoofing encompasses any technique that causes a DNS resolver to return a forged answer, sending the victim to an attacker-controlled server instead of the legitimate one.

On-Path DNS Spoofing

An attacker who has already achieved a MITM position (e.g., via ARP spoofing or a rogue Wi-Fi access point) can intercept DNS queries as they leave the victim's machine and respond with forged answers before the real DNS server can reply. Since traditional DNS uses unencrypted UDP on port 53, modifying queries and responses in transit is trivial.

DNS Cache Poisoning (Kaminsky Attack)

The more dangerous variant does not require a MITM position at all. In 2008, Dan Kaminsky disclosed a fundamental flaw in DNS that allowed remote attackers to poison the cache of recursive resolvers. The attack exploits the fact that DNS transaction IDs are only 16 bits wide (65,536 possible values). An attacker floods the resolver with forged responses, each guessing a different transaction ID, while simultaneously triggering legitimate queries for the target domain. If a forged response arrives with the correct transaction ID before the real answer, the resolver caches the attacker's IP address for that domain.

Once a resolver's cache is poisoned, every user relying on that resolver is silently redirected. The attacker could redirect bank.example.com to a pixel-perfect phishing site running on their own infrastructure, complete with a valid-looking URL in the browser's address bar.

Defenses: DNSSEC cryptographically signs DNS responses so resolvers can verify their authenticity. Source port randomization (introduced post-Kaminsky) increases the entropy an attacker must guess. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the entire DNS transaction, preventing on-path manipulation. Modern resolvers combine all three defenses.

BGP Hijacking: MITM at Internet Scale

While ARP and DNS attacks work on local networks or individual resolvers, BGP hijacking can reroute traffic across the entire internet. BGP is the protocol that autonomous systems use to exchange routing information, and like ARP, it was designed with implicit trust between participants. Any AS can announce any IP prefix, and neighboring routers will generally accept the announcement.

How BGP Becomes a MITM Vector

A standard BGP hijack (announcing someone else's prefix) creates a blackhole — traffic flows to the attacker but never reaches its destination, and the victim quickly notices. A BGP interception attack is more subtle: the attacker announces the victim's prefix to attract traffic, but carefully maintains a path back to the legitimate origin so they can forward the traffic after inspecting it. From the victim's perspective, their service continues to work normally, just with slightly higher latency.

The attacker accomplishes this by selectively announcing the hijacked prefix only to certain peers while ensuring their own path to the victim remains unaffected. This requires careful BGP engineering — the attacker must avoid poisoning their own route to the victim, typically by using AS path prepending and community-based filtering on specific peering sessions.

Real-World BGP MITM Incidents

In 2013, researchers at Renesys (now Dyn/Oracle) documented persistent BGP interceptions where traffic between cities in the same country was detoured through distant autonomous systems in other continents. Traffic from Guadalajara to Washington D.C. was routed through Belarus; traffic within the US was routed through Iceland. In each case, the traffic was forwarded to its final destination after passing through the intercepting AS — a textbook MITM pattern that went undetected for months.

In 2018, a BGP hijack targeting Amazon's Route 53 DNS service redirected DNS queries for MyEtherWallet.com to an attacker-controlled server, which served a phishing page and stole cryptocurrency. The attacker announced Amazon's DNS prefix from a small ISP in Ohio, attracting traffic that would normally flow to Amazon's infrastructure. This attack combined BGP hijacking with DNS interception — two MITM layers stacked together.

You can use the BGP looking glass to monitor for suspicious route changes. Try looking up critical prefixes and verify the origin AS:

• 8.8.8.8 — Google DNS (should originate from AS15169)
• 1.1.1.1 — Cloudflare DNS (should originate from AS13335)
• 9.9.9.9 — Quad9 DNS

SSL Stripping and TLS Interception

Even when an attacker has achieved a MITM position, TLS (HTTPS) should protect the confidentiality and integrity of web traffic. TLS encrypts the channel between client and server and uses certificates to authenticate the server's identity. An attacker who intercepts TLS-encrypted traffic sees only ciphertext. But several attack techniques aim to circumvent TLS protections.

SSL Stripping

Introduced by Moxie Marlinspike at Black Hat 2009, SSL stripping exploits the moment when a user first connects to a website over HTTP before being redirected to HTTPS. The MITM attacker intercepts the initial HTTP request, establishes their own HTTPS connection to the real server, and serves the content back to the victim over plain HTTP. The victim sees no padlock in the browser and communicates in cleartext with the attacker, while the attacker relays everything to the real server over an encrypted channel.

The attack works because most users do not manually type https:// — they rely on the server to redirect them. The attacker simply never passes along the redirect. To the victim, the page looks identical to the real site, just without the padlock icon (which most non-technical users never check).

TLS Interception with Forged Certificates

A more aggressive approach involves the attacker generating a forged TLS certificate for the target domain. When the victim connects, the attacker presents the fake certificate and establishes two separate TLS sessions: one with the victim (using the forged cert) and one with the real server (using the real cert). The attacker decrypts traffic from the victim, inspects or modifies it, re-encrypts it, and forwards it to the server.

This attack is thwarted by the certificate authority (CA) system: the browser will reject the forged certificate because it is not signed by a trusted CA. The victim would see a certificate warning — unless the attacker has compromised a CA or installed their root certificate on the victim's machine. This has happened in practice:

• DigiNotar (2011) — A Dutch CA was breached, and the attacker issued fraudulent certificates for google.com and hundreds of other domains. These certificates were used to intercept Gmail traffic of Iranian users. DigiNotar was subsequently revoked and went bankrupt.
• Superfish (2015) — Lenovo shipped laptops with pre-installed adware that injected its own root CA certificate, allowing it to MITM all HTTPS traffic for ad injection. This also meant any attacker who obtained Superfish's private key (which was trivially extractable) could MITM all affected laptops.
• Kazakhstan government (2019) — The government required citizens to install a state-issued root certificate, enabling TLS interception of all HTTPS traffic. Browser vendors (Mozilla, Google, Apple) responded by blocking the certificate.

HTTP Strict Transport Security (HSTS)

HSTS is the primary defense against SSL stripping. When a server sends the Strict-Transport-Security header, the browser remembers to always use HTTPS for that domain, even if the user types an HTTP URL. Browsers also ship with a preloaded HSTS list covering major websites, so the very first connection to those sites is always HTTPS — the attacker never gets a chance to strip it.

Wi-Fi MITM: Evil Twin and Rogue Access Points

Wireless networks are particularly vulnerable to MITM attacks because the attacker does not need physical access to network cabling — they just need to be within radio range.

Evil Twin Attack

An evil twin is a rogue Wi-Fi access point that mimics a legitimate network. The attacker creates an access point with the same SSID (network name) as a trusted network — "Starbucks_WiFi", "Airport_Free_WiFi", or even a corporate SSID. If the attacker's signal is stronger than the real access point, devices will automatically connect to the evil twin, routing all their traffic through the attacker.

Once connected, the attacker is the default gateway for all traffic. They can perform DNS spoofing to redirect specific domains, inject content into HTTP pages, capture credentials, or log all traffic for later analysis. With tools like hostapd-wpe, an attacker can also capture enterprise Wi-Fi credentials (WPA2-Enterprise with PEAP/MSCHAPv2) by presenting a fake RADIUS authentication server.

KARMA and Known Network Attacks

Devices constantly probe for previously connected networks by broadcasting "Are you NetworkX?" An attacker running a KARMA attack responds to every probe with "Yes, I am NetworkX," causing the device to connect automatically. This works because most devices do not verify the identity of an access point beyond matching the SSID name. The attacker's single access point can simultaneously impersonate dozens of different networks, capturing victims who have ever connected to any open network.

Defenses: WPA3-Enterprise with server certificate validation prevents credential capture. Enterprise environments should use 802.1X with proper certificate pinning. For individuals, using a VPN on untrusted networks encrypts all traffic regardless of the access point's trustworthiness. Cellular connections are generally safer than unknown Wi-Fi networks.

Protocol-Level MITM: DHCP and ICMP

Beyond ARP and Wi-Fi, other network protocols are also exploitable for MITM positioning:

DHCP Spoofing

When a device joins a network, it uses DHCP to obtain an IP address, default gateway, and DNS server. An attacker running a rogue DHCP server can respond to DHCP requests faster than the legitimate server, assigning themselves as the default gateway and DNS server. This achieves a MITM position without any ARP manipulation — the victim's operating system willingly routes all traffic through the attacker because it was told to do so during network configuration.

ICMP Redirect Attacks

ICMP redirect messages are used by routers to inform hosts of a better route. An attacker can send forged ICMP redirect messages to a victim, instructing it to route traffic for specific destinations through the attacker's machine. Most modern operating systems disable processing of ICMP redirects by default, but older or misconfigured systems remain vulnerable.

HTTPS and Certificate Pinning as Defenses

TLS/HTTPS is the single most important defense against MITM attacks at the application layer. When properly implemented, it provides three guarantees that together make interception detectable or impossible:

• Confidentiality — Traffic is encrypted with session keys negotiated through a Diffie-Hellman key exchange. Even a MITM observer cannot derive the session keys from the handshake traffic.
• Integrity — Every TLS record includes a message authentication code (MAC). Any modification to the ciphertext is detected and the connection is terminated.
• Authentication — The server presents a certificate signed by a trusted Certificate Authority (CA). The client verifies the certificate chain, confirming the server's identity.

Certificate Transparency (CT) adds another layer: all publicly trusted CAs must log every certificate they issue to public, append-only CT logs. Domain owners can monitor these logs for unauthorized certificates issued for their domains. If a CA is compromised and issues a fraudulent certificate, CT logs make the fraud publicly visible within hours.

Certificate pinning goes further by hard-coding the expected certificate or public key into the application. If the app receives a certificate that does not match the pin, it refuses to connect — even if the certificate is signed by a trusted CA. This prevents MITM attacks that rely on compromised or government-controlled CAs. While HTTP Public Key Pinning (HPKP) was deprecated for websites due to operational risks, certificate pinning remains widely used in mobile apps and critical infrastructure.

DNSSEC: Authenticating DNS Responses

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that a response genuinely came from the authoritative nameserver for a domain and was not modified in transit. Without DNSSEC, a resolver has no way to distinguish a legitimate DNS response from a forged one — it simply trusts the first valid-looking answer it receives.

DNSSEC works through a chain of trust anchored at the DNS root zone. The root zone is signed with a well-known key. Each TLD zone is signed and its key is vouched for by the root. Each domain's zone is signed and its key is vouched for by the TLD. A validating resolver walks this chain from root to leaf, verifying signatures at each level. If any signature is invalid or missing (and the zone should be signed), the response is rejected.

DNSSEC prevents cache poisoning attacks because forged responses lack valid signatures. However, DNSSEC does not encrypt DNS queries — it only authenticates responses. An observer can still see which domains you are looking up; they just cannot forge the answers. For full DNS privacy, DNSSEC should be combined with DNS over HTTPS or DNS over TLS.

DNS over HTTPS: Encrypting the Last Mile

DNS over HTTPS (DoH) solves the confidentiality problem that DNSSEC does not address. By encrypting DNS queries inside TLS connections, DoH prevents on-path attackers from seeing or modifying DNS traffic. An attacker performing ARP spoofing or running an evil twin AP can no longer intercept DNS queries to redirect victims to phishing sites — the DNS queries are encrypted and authenticated through the TLS connection to the DoH resolver.

The combination of DNSSEC and DoH provides comprehensive DNS security: DNSSEC ensures the DNS data itself is authentic (signed by the domain owner), while DoH ensures the query and response cannot be observed or tampered with in transit. Together, they close the DNS-based MITM attack surface.

RPKI: Securing BGP Against Route Hijacking

Resource Public Key Infrastructure (RPKI) is to BGP what DNSSEC is to DNS — a cryptographic system for authenticating route announcements. RPKI allows IP address holders to create Route Origin Authorizations (ROAs) that cryptographically declare which autonomous systems are authorized to announce their prefixes.

When a network performs Route Origin Validation (ROV), it checks incoming BGP announcements against the RPKI database. If an AS announces a prefix for which it has no valid ROA, the route is classified as "RPKI Invalid" and can be dropped. This prevents the most common form of BGP hijacking — an unauthorized AS announcing someone else's prefix.

RPKI adoption has grown steadily. Major networks including Cloudflare (AS13335), Google (AS15169), and Amazon (AS16509) both sign their own routes with ROAs and perform validation on routes they receive. As of 2025, approximately 50% of IPv4 routes and 60% of IPv6 routes have valid ROAs.

However, RPKI has limitations as a MITM defense. It validates the origin AS of a route, not the entire AS path. A sophisticated attacker who is a legitimate transit provider could still perform path manipulation without triggering RPKI validation failures. BGPsec, a proposed extension that cryptographically signs each hop in the AS path, would address this gap, but it has seen minimal deployment due to performance and scalability concerns.

You can check the RPKI status of any route using the looking glass:

• 8.8.8.0/24 — Google DNS prefix (RPKI-signed)
• 1.1.1.0/24 — Cloudflare DNS prefix (RPKI-signed)

Real-World MITM Attacks: A Timeline

MITM attacks are not theoretical exercises — they have been deployed by criminals, intelligence agencies, and governments at scale:

• 2008 — Kaminsky DNS vulnerability: Dan Kaminsky discovered that DNS cache poisoning was far easier than previously believed, threatening the integrity of virtually all DNS resolution on the internet. The coordinated disclosure and patch effort involved every major DNS vendor simultaneously.
• 2010 — China Telecom BGP incident: For 18 minutes, China Telecom (AS4134) attracted approximately 15% of the world's internet routes, including traffic destined for US military, government, and commercial networks. Whether this was intentional interception or accidental misconfiguration remains debated.
• 2011 — DigiNotar CA breach: Attackers compromised the Dutch certificate authority DigiNotar and issued over 500 fraudulent certificates. These were used to intercept the Gmail traffic of approximately 300,000 Iranian users. The certificates were valid and trusted by all browsers, making the MITM attack invisible until the breach was discovered.
• 2013 — NSA QUANTUM program: Edward Snowden's disclosures revealed that the NSA operated MITM infrastructure at internet backbone points, using a system called QUANTUM to inject responses faster than legitimate servers could respond. QUANTUMINSERT placed malware by racing legitimate responses to HTTP requests.
• 2014 — Renesys BGP interception study: Security researchers documented systematic BGP interceptions where traffic between multiple countries was silently rerouted through specific autonomous systems. The traffic was forwarded to its destination after interception, confirming a deliberate MITM pattern rather than accidental hijacking.
• 2015 — Lenovo Superfish: Lenovo pre-installed the Superfish Visual Discovery adware, which installed its own root CA certificate and performed TLS interception on all HTTPS connections to inject advertisements. The same private key was used across all affected machines and was trivially extractable, allowing any attacker to MITM those devices.
• 2017 — KRACK (Key Reinstallation Attack): Researchers demonstrated that the WPA2 Wi-Fi protocol had a fundamental flaw allowing an attacker within radio range to force reuse of encryption keys, enabling decryption and injection of frames. This affected essentially every Wi-Fi device in the world.
• 2018 — BGP hijack of Amazon DNS: Attackers hijacked BGP routes for Amazon's Route 53 DNS service from a small ISP, redirecting DNS queries for MyEtherWallet.com to a phishing server. Users who connected had their cryptocurrency stolen. This attack combined BGP hijacking and DNS interception — two MITM layers.
• 2022 — Lapsus$ MITM via SIM swapping: The Lapsus$ group used SIM-swapping attacks (a form of telecommunications MITM) to intercept SMS-based two-factor authentication codes, gaining access to major technology companies including Microsoft, Nvidia, and Samsung.

Defense in Depth: Layering MITM Protections

No single defense prevents all MITM attacks. Effective protection requires layering defenses across the network stack:

Detection: How to Spot a MITM Attack

While prevention is ideal, detection serves as a critical second line of defense:

• Certificate warnings — Never ignore browser certificate warnings. A certificate error on a site you regularly visit without issues is a strong indicator of TLS interception.
• Unexpected latency — MITM relays add measurable latency. If a service that normally responds in 20ms suddenly takes 200ms, traffic may be taking an unexpected detour. BGP-based interceptions are particularly detectable through latency analysis and traceroute path changes.
• ARP table monitoring — On local networks, watch for multiple IP addresses mapping to the same MAC address, or for the gateway's MAC address changing unexpectedly.
• BGP monitoring — Services like RIPE RIS, BGPStream, and BGP looking glasses can alert network operators when their prefixes are announced by unauthorized ASes.
• Certificate Transparency logs — Domain owners should monitor CT logs for certificates issued for their domains by unexpected CAs.

The Evolving Threat Landscape

The internet has made significant progress against MITM attacks. HTTPS adoption has gone from under 40% of web traffic in 2015 to over 95% in 2025. RPKI adoption continues to grow, with major networks dropping RPKI-invalid routes. DNSSEC and DoH are closing the DNS manipulation gap.

But new attack surfaces continue to emerge. The proliferation of IoT devices creates millions of endpoints with weak or no TLS implementation. 5G network slicing introduces new trust boundaries that could be exploited. Quantum computing threatens to eventually break the RSA and elliptic-curve cryptography that underpins TLS, DNSSEC, and RPKI — driving urgent work on post-quantum cryptographic algorithms.

The fundamental lesson of MITM attacks is that trust must be cryptographically verified, never assumed. Every protocol that operates on implicit trust — from ARP on a LAN to BGP across the global internet — is a potential MITM vector until authentication is added. The ongoing work to retrofit authentication into these protocols is one of the most important security efforts in internet infrastructure.

See It in Action

Use the BGP looking glass to verify routing integrity and check for signs of route hijacking:

• Look up 8.8.8.8 — verify Google DNS is routed through AS15169
• Look up 1.1.1.1 — verify Cloudflare DNS is routed through AS13335
• Look up AS4134 — China Telecom, involved in historical BGP incidents
• Look up AS16509 — Amazon, target of the 2018 Route 53 hijack