Man-in-the-middle attacks are less about "tricking" users and more about attackers subtly hijacking the communication channel itself.
Let’s watch one unfold. Imagine Alice wants to log into her bank’s website, bank.com. She types bank.com into her browser.
Normally, her computer would send a DNS request to a DNS server asking for the IP address of bank.com. The DNS server would respond with the correct IP. Then, Alice’s browser would establish a direct TCP connection to that IP address, followed by a TLS handshake to secure the connection.
Now, introduce our attacker, Mallory. Mallory has managed to compromise Alice’s local network or, more commonly, has convinced Alice’s router to point to a malicious DNS server.
When Alice’s computer asks for bank.com’s IP, Mallory’s DNS server responds with Mallory’s IP address. Alice’s computer, none the wiser, initiates a connection to Mallory.
Mallory, now in the middle, receives Alice’s connection request. Mallory then initiates a connection to the real bank.com on Alice’s behalf. The bank sees a legitimate connection from Mallory’s IP address.
Crucially, Mallory establishes two separate TLS connections: one with Alice and one with bank.com. To Alice, Mallory presents a TLS certificate that appears to be from bank.com. If Alice doesn’t notice the certificate warning (or if Mallory’s fake certificate is particularly convincing), she proceeds. To bank.com, Mallory presents a TLS certificate for bank.com (which Mallory might have obtained or generated).
Alice sends her username and password to Mallory, thinking it’s the bank. Mallory receives this plaintext data. Mallory then forwards this username and password to the real bank.com. The bank processes the login.
When bank.com sends back Alice’s account information, it goes to Mallory first. Mallory then forwards it to Alice. Alice sees her bank account, believes everything is normal, but Mallory has a perfect copy of all the traffic.
This allows Mallory to capture credentials, session cookies, and any other sensitive data transmitted over the seemingly secure connection.
The core problem MITM attacks solve for attackers is bypassing end-to-end encryption where the endpoints themselves are compromised or tricked into talking to the attacker instead of each other. It’s a replay of the classic "telephone game" but with digital packets and cryptographic keys.
Here’s a simplified look at the network flow:
Alice's Browser <--- TCP/TLS ---> Mallory <--- TCP/TLS ---> bank.com
Notice the two distinct TLS sessions. The "trust" is broken at Mallory’s machine.
The most common vectors for this involve:
- DNS Spoofing/Poisoning: As described, tricking the DNS resolution process.
- ARP Spoofing (Local Networks): On a local network (like public Wi-Fi), an attacker can send out ARP (Address Resolution Protocol) messages that tell Alice’s computer that Mallory’s MAC address is the gateway’s MAC address, and tell the gateway that Mallory’s MAC address is Alice’s MAC address. This effectively redirects all traffic between Alice and the gateway through Mallory.
- SSL Stripping: An attacker intercepts an HTTP request and downgrades it to HTTPS. If the user doesn’t notice, they might proceed over an unencrypted channel.
- Malicious Wi-Fi Hotspots: Setting up a fake Wi-Fi network with a convincing name (e.g., "Free Airport Wi-Fi") that users connect to, routing all their traffic through the attacker’s device.
- Compromised Routers/Proxies: If a network device in the communication path is compromised, it can act as a MITM.
- Browser Extensions/Malware: Malicious browser extensions or installed malware on a user’s machine can intercept traffic before it even leaves the browser process.
The critical point is that the attacker is not breaking the TLS encryption itself. They are preventing the legitimate endpoints from establishing a secure channel with each other and instead establishing separate, trusted channels with each endpoint.
Consider the TLS handshake. When Alice connects to bank.com (via Mallory), her browser receives a certificate. If Mallory has signed this fake certificate with his own Certificate Authority (CA) that Alice’s browser trusts, the connection proceeds without a warning. Many corporate environments or even malicious actors will try to install their own root CA certificates onto user machines, making this a very effective attack.
The primary defense is vigilance with certificate warnings. If your browser flags a site’s certificate as untrusted, invalid, or issued by an unknown authority, stop. Don’t click through. It’s your browser telling you that the person you think you’re talking to might not be who they say they are. Using VPNs, especially on public networks, also helps by encrypting your traffic from your device all the way to the VPN server, making it harder for local network attackers to intercept.
The next step after successfully performing a MITM attack is often to inject malicious JavaScript into the intercepted traffic to perform actions like phishing, credential harvesting, or even modifying displayed content in real-time.