Man-in-the-Middle Attacks

The Core Problem: Two Parties Who Think They Are Talking to Each Other

A man-in-the-middle attack occurs when an attacker secretly positions themselves between two communicating parties, relaying and potentially modifying the messages without either party knowing. The attacker does not break the encryption or crack the authentication — they simply become an invisible proxy in the communication path.

The attack has two phases: interception (getting the traffic to flow through the attacker) and manipulation (reading or altering the relayed data). Interception without manipulation is passive eavesdropping. Manipulation without interception is impossible — you cannot modify what you cannot see.

Interception Techniques

ARP Spoofing (Local Network)

The most common LAN-based MITM technique. The attacker poisons the ARP caches of both the victim and the gateway so that traffic between them flows through the attacker's machine. This was covered in detail in the sniffing and spoofing topic — ARP spoofing is the enabler, MITM is the objective.

DNS Hijacking

Instead of intercepting traffic directly, the attacker corrupts the domain name resolution process. When the victim queries bank.com, the attacker's DNS server responds with the IP address of a server they control. The victim connects to the attacker's server believing it is the real bank. The attacker proxies the connection to the real bank, capturing credentials and session tokens in transit.

DNS hijacking can occur at multiple levels:

• Compromising the victim's local DNS settings (malware)
• Poisoning a DNS resolver's cache (Kaminsky-style attacks)
• Compromising the domain's authoritative nameserver
• Rogue DHCP servers that hand out attacker-controlled DNS server addresses

Rogue Access Points (Evil Twin)

An attacker sets up a wireless access point with the same SSID as a legitimate network. If the rogue AP has a stronger signal, clients may connect to it automatically. The attacker now sees all traffic from connected clients. This is particularly effective against devices that auto-connect to known networks.

BGP Hijacking (Internet Scale)

At the internet routing level, an attacker announces IP prefixes they do not own via BGP. If the announcement is more specific (longer prefix) or has a shorter AS path, other routers may route traffic for those prefixes through the attacker's network. This is how nation-state actors and misconfigured ISPs have redirected traffic across continents.

The Attacker's Position

Once traffic flows through the attacker, they can:

• Passively capture credentials, session cookies, and personal data
• Actively modify transaction amounts, recipient account numbers, or download links
• Inject content into web pages (ads, malware, defacement)
• Downgrade connections from HTTPS to HTTP (SSL stripping)

The attacker must forward traffic to the real destination to avoid detection — a pure black-hole attack (dropping all traffic) is immediately obvious. The goal is to be invisible.

Downgrading the Connection: SSL Stripping

When a user types bank.com into their browser (without https://), the browser first makes an HTTP request. The legitimate server responds with a 301 redirect to https://bank.com. SSL stripping exploits this initial HTTP request.

The attacker, positioned as MITM, intercepts the HTTP request and prevents the redirect from reaching the victim. The attacker maintains an HTTPS connection with the real bank server but communicates with the victim over plain HTTP. The victim sees a web page that looks like their bank, but the traffic is unencrypted. The attacker reads and modifies everything.

Victim  <--HTTP-->  Attacker  <--HTTPS-->  Bank Server
         (attacker reads everything)    (legitimate encrypted channel)

The victim's browser shows http://bank.com in the address bar, but many users do not notice the missing https or padlock icon. Even security-conscious users may not catch the downgrade if they typed the domain manually.

HSTS: Preventing the Downgrade

HTTP Strict Transport Security (HSTS) is a web server header that tells the browser: "Never connect to this domain over HTTP. Always use HTTPS." Once a browser has seen the HSTS header for a domain, it will automatically upgrade all future HTTP requests to HTTPS before they leave the machine — the initial plaintext request never happens.

# HSTS header sent by the server
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The preload directive is critical. A user's first visit to a site is still vulnerable to SSL stripping because the browser has not yet seen the HSTS header. Browser vendors maintain an HSTS preload list — domains hardcoded into the browser that always use HTTPS from the very first connection. Major sites (Google, Facebook, banks) are on this list.

Certificate Warnings: The Client-Side Signal

When an attacker performs MITM on an HTTPS connection, they must present a certificate to the victim. They cannot forge a valid certificate signed by a trusted CA for the target domain (unless they compromise a CA or trick the victim into installing a rogue root certificate). The browser detects the mismatch and displays a warning:

"Your connection is not private. Attackers might be trying to steal your information."

This warning is the primary client-side signal that a MITM attack is occurring. However, users have been trained to click through warnings. SSL stripping avoids this entirely by keeping the connection at the HTTP level — no certificate is needed, no warning is shown.

Certificate Pinning

Certificate pinning goes beyond the standard CA trust model. The application hardcodes (pins) the expected certificate or public key for a specific server. Even if an attacker obtains a valid certificate from a trusted CA (e.g., by compromising the domain's registration), the pinned application will reject it because it does not match the expected key.

# Certificate pinning in Python (requests library)
import requests
import ssl

# Pin the expected certificate fingerprint
PINNED_FINGERPRINT = "SHA256:abc123..."

class PinnedAdapter(requests.adapters.HTTPAdapter):
    def init_poolmanager(self, *args, **kwargs):
        ctx = ssl.create_default_context()
        ctx.load_verify_locations(cafile="pinned_cert.pem")
        kwargs["ssl_context"] = ctx
        return super().init_poolmanager(*args, **kwargs)

session = requests.Session()
session.mount("https://", PinnedAdapter())

Pinning is powerful but operationally risky — if the server's legitimate certificate rotates and the pin is not updated, the application breaks. It is most commonly used in mobile apps and high-security client applications.

Mutual TLS (mTLS)

Standard TLS authenticates the server to the client. Mutual TLS requires the client to also present a certificate. An attacker performing MITM would need not only a valid server certificate but also a valid client certificate. In enterprise environments with internal CAs, mTLS makes silent interception practically impossible.

Making MITM Detectable or Infeasible

MITM attacks are dangerous precisely because they are silent. The defender's goal is to either prevent the attacker from getting into the middle position, or to make the interception detectable when it occurs.

Network-Level Detection

ARP Monitoring

Since ARP spoofing is the most common LAN-based MITM enabler, monitoring ARP traffic is the first line of defense. Tools like arpwatch, XArp, and enterprise NDR platforms detect when a MAC address claims to be multiple IP addresses or when ARP mappings change unexpectedly.

# Monitor ARP traffic for anomalies
sudo arpwatch -i eth0 -f /var/log/arpwatch.log

# Check for IP conflicts (same IP, multiple MACs)
arp-scan --localnet | sort | uniq -d

Network Segmentation

VLANs and microsegmentation limit the broadcast domain. An attacker on the corporate VLAN cannot ARP-spoof a server in the data center VLAN because ARP does not cross VLAN boundaries. Proper segmentation forces the attacker to find a different interception point (e.g., DNS or BGP), which is significantly harder.

802.1X Network Access Control

802.1X requires devices to authenticate before receiving network access. An attacker cannot simply plug into a wall jack and start ARP spoofing — they must first authenticate with valid credentials or a certificate. This raises the bar for local network MITM attacks.

Application-Level Defenses

HSTS with Preload

As discussed, HSTS prevents SSL stripping by ensuring the browser never makes an initial HTTP request. The preload list extends this protection to first-time visitors. Any web application that handles credentials or sensitive data should implement HSTS with preload.

Certificate Transparency (CT)

Certificate Transparency requires all TLS certificates to be logged in public, append-only logs. Domain owners can monitor these logs for certificates issued for their domains without authorization. If an attacker compromises a CA or tricks one into issuing a certificate for bank.com, the domain owner will see the unauthorized certificate in the CT log and can revoke it.

DNSSEC

DNSSEC adds cryptographic signatures to DNS records, preventing DNS cache poisoning and ensuring that DNS responses are authentic. Without DNSSEC, an attacker can redirect victims to malicious servers by corrupting DNS resolution.

Endpoint Detection

Certificate Warning Monitoring

Security teams can monitor for certificate warnings reported by endpoints. A spike in certificate warnings for a specific domain may indicate an active MITM attack. Browser telemetry and EDR agents can surface these events.

Rogue AP Detection

Wireless intrusion detection systems (WIDS) monitor the radio spectrum for access points with SSIDs matching the corporate network but with unfamiliar MAC addresses. An evil twin AP is detected when two APs with the same SSID have different BSSIDs (MAC addresses) and the rogue one is not in the authorized inventory.

VPN for Untrusted Networks

When users connect from untrusted networks (coffee shops, hotels), a VPN encrypts all traffic from the device to the corporate network. Even if an attacker is positioned on the local network, they only see VPN ciphertext. This is the most practical defense for remote workers.

The Layered Model

No single control stops all MITM attacks. The effective defense combines:

1. Network hardening — 802.1X, DAI, segmentation, port security
2. Encryption — TLS 1.3, HSTS, VPN, mTLS
3. DNS integrity — DNSSEC, DNS-over-HTTPS
4. Monitoring — ARP monitoring, CT log monitoring, rogue AP detection
5. User education — certificate warning awareness, phishing recognition

The attacker must defeat all layers to succeed silently. Each layer raises the cost and risk of the attack.