Network interception is how a bad actor secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other.
Let’s watch this happen. Imagine Alice wants to send a secret message to Bob.
@startuml
actor Alice
actor Bob
participant "Man-in-the-Middle" as MITM
Alice -> Bob : "Hello Bob, this is Alice."
note over Alice, Bob : Alice and Bob think this is direct.
MITM -> Alice : "Hello Bob, this is Alice."
MITM -> Bob : "Hello Bob, this is Alice."
@enduml
In this scenario, a Man-in-the-Middle (MITM) attacker intercepts Alice’s message. The attacker’s machine sits between Alice and Bob, receiving Alice’s message and then forwarding it to Bob. Crucially, Bob thinks the message came directly from Alice, and Alice thinks she’s talking directly to Bob. The MITM can read, modify, or drop messages at will.
The core problem MITM attacks solve for the attacker is gaining unauthorized access to sensitive data or the ability to manipulate communications without the legitimate parties knowing. This could be anything from stealing login credentials, intercepting financial transactions, or injecting malicious code into legitimate data streams.
Internally, MITM attacks exploit trust. They often rely on network-level vulnerabilities or misconfigurations. Common techniques include:
-
ARP Spoofing: On a local network (like Wi-Fi), an attacker sends forged ARP (Address Resolution Protocol) messages. ARP maps IP addresses to MAC addresses. By sending an ARP reply that says "the router’s IP address belongs to my MAC address," the attacker tricks devices into sending traffic destined for the router to the attacker’s machine instead.
- Diagnosis: On Linux, use
arp -ato view the ARP cache. Look for your gateway’s IP address associated with an unexpected MAC address. On Windows,arp -aserves the same purpose. - Fix: Implement ARP spoofing detection tools (e.g.,
arpwatchon Linux) or static ARP entries on critical machines.sudo arp -s <router_ip> <router_mac>on Linux. This forces the machine to always associate the router’s IP with its known MAC address, ignoring spoofed replies. - Why it works: Static ARP entries bypass the dynamic, trust-based nature of ARP, ensuring traffic always goes to the legitimate gateway.
- Diagnosis: On Linux, use
-
DNS Spoofing: The attacker poisons the DNS cache of a victim or compromises a DNS server. When the victim tries to visit
www.example.com, the attacker’s DNS server (or a spoofed response) returns the IP address of the attacker’s malicious server instead of the legitimate one.- Diagnosis: Use
nslookup www.example.comordig www.example.comfrom the victim machine. Compare the returned IP address against a known good IP for that domain. Check the DNS server configured on the victim’s machine (ipconfig /allon Windows,/etc/resolv.confon Linux). - Fix: Configure clients to use trusted DNS servers (e.g., Google DNS 8.8.8.8, Cloudflare 1.1.1.1). On the server side, ensure DNS servers are secured against cache poisoning and consider DNSSEC.
- Why it works: By controlling the DNS resolution, the attacker redirects traffic to their own server, which then acts as the intermediary.
- Diagnosis: Use
-
SSL/TLS Stripping: An attacker intercepts an HTTPS connection request. Instead of establishing a secure connection with the server, the attacker establishes an insecure HTTP connection with the victim and a separate HTTPS connection with the server. The victim sees an HTTP site and doesn’t realize their traffic is unencrypted.
- Diagnosis: Check the URL in the browser’s address bar. If you expect HTTPS (e.g., a banking site) but see
http://, be suspicious. Also, look for the padlock icon; its absence or a warning indicates an insecure connection. - Fix: Use browser extensions like "HTTPS Everywhere" which automatically tries to upgrade HTTP connections to HTTPS. Ensure your clients are configured to reject insecure HTTP connections for sensitive sites.
- Why it works: The attacker acts as a proxy, decrypting traffic from the victim and re-encrypting it for the server, and vice-versa, allowing them to see everything in plain text.
- Diagnosis: Check the URL in the browser’s address bar. If you expect HTTPS (e.g., a banking site) but see
-
Wi-Fi Eavesdropping/Evil Twin: The attacker sets up a rogue Wi-Fi access point (AP) with a convincing name (e.g., "Free Airport WiFi"). When users connect, their traffic is routed through the attacker’s AP.
- Diagnosis: Examine the SSID (network name) and signal strength. If a public Wi-Fi network suddenly shows a very strong signal or has a slightly different, but plausible, name, it could be an evil twin. Check the IP address range and gateway your device receives.
- Fix: Always verify the authenticity of public Wi-Fi networks. Connect only to trusted, named networks. Avoid connecting to open or unknown Wi-Fi. Use a VPN to encrypt all traffic, regardless of the network.
- Why it works: Users connect to the attacker’s AP, mistaking it for a legitimate network, thereby routing all their internet traffic through the attacker’s controlled device.
-
Packet Sniffing: While not strictly an MITM attack in itself, it’s the tool used by an MITM. On an unencrypted network segment (like a shared hub or poorly configured switch), an attacker can capture all packets passing through that segment.
- Diagnosis: If you can capture traffic on a network segment where you shouldn’t be able to see traffic not destined for your machine, packet sniffing is active. Tools like Wireshark are used for this.
- Fix: Use switched networks instead of hubs. Implement network segmentation and VLANs. Ensure all sensitive traffic is encrypted (HTTPS, SSH, VPNs).
- Why it works: On older or misconfigured networks, packets are broadcast to all ports. Sniffing tools allow the attacker’s machine to see all these broadcasts.
When you’re dealing with MITM, you’re essentially fighting against a system that has been tricked into trusting the wrong entity. The core levers you control are the integrity of your network’s identity systems (ARP, DNS) and the encryption of your communications (TLS/SSL, VPNs).
A common misconception is that simply using HTTPS is a foolproof defense against all MITM attacks. While HTTPS encrypts the content of your communication, it doesn’t inherently prevent an attacker from performing TLS stripping or impersonating the server if certificate validation is weak or bypassed. The browser’s certificate warnings are the last line of defense against a compromised connection, and they are often ignored.
The next challenge you’ll encounter is defending against more sophisticated attacks that target the endpoints themselves, bypassing network-level interception.