NetSec Man-in-the-Middle Attacks

A Man-in-the-Middle (MITM) attack occurs when an attacker secretly positions themselves between two communicating parties and intercepts, reads, or alters the communication without either party knowing. Both sides believe they are talking directly to each other. In reality, every message passes through the attacker first.

The Core Concept

NORMAL COMMUNICATION:
[Alice] ←─────────────────────────────→ [Bank Website]
         "I trust everything here"

MITM ATTACK:
[Alice] ←──→ [ATTACKER] ←──→ [Bank Website]
              reads all        real site
              alters if needed

Alice thinks she is talking to the bank.
Bank thinks it is talking directly to Alice.
Attacker sees and controls everything in between.

How MITM Attacks Are Executed

ARP Poisoning (Local Network)

ARP (Address Resolution Protocol) maps IP addresses to MAC addresses on a local network. ARP has no authentication — any device can send an ARP reply claiming any IP address belongs to it. An attacker sends fake ARP replies that tell other devices "the gateway's IP is at MY MAC address." All traffic intended for the gateway flows through the attacker instead.

ARP POISONING:

Legitimate ARP table on Alice's PC:
  Gateway 192.168.1.1 = MAC aa:bb:cc:dd:ee:ff (real router)

After ARP poisoning:
  Gateway 192.168.1.1 = MAC 11:22:33:44:55:66 (attacker's MAC!)

Alice sends all traffic to "gateway" → actually goes to attacker
Attacker forwards to real gateway → Alice never notices
Attacker reads every packet in both directions

DNS Spoofing

The attacker sends fake DNS responses that point a legitimate domain name to the attacker's IP address. When the victim types the bank's URL, DNS returns the attacker's server IP instead of the real bank. The victim connects to a fake site that looks identical to the real one.

DNS SPOOFING:

Victim asks: "What is the IP of mybank.com?"
Real DNS server would say: "203.0.113.50"
Attacker's fake DNS reply says: "192.168.1.100" ← attacker's server

Victim connects to 192.168.1.100 (fake bank site)
Victim logs in → attacker captures credentials
Attacker logs into real bank with stolen credentials

HTTPS Downgrade (SSL Stripping)

The attacker intercepts the victim's initial HTTP request before it redirects to HTTPS. The attacker maintains an HTTPS connection to the real server but presents a plain HTTP connection to the victim. The victim communicates in plain text while the attacker relays the requests to the real HTTPS server.

MITM via Rogue Wi-Fi

An attacker creates a fake Wi-Fi access point. Devices connect to it. The attacker's hotspot routes all traffic to the internet through the attacker's device, placing the attacker naturally in the middle of every connection.

What MITM Attackers Steal or Do

Goal                        | Method
----------------------------|---------------------------------------------
Steal login credentials     | Capture HTTP form submissions
Steal session cookies       | Read Set-Cookie headers in responses
Read private emails         | Intercept unencrypted IMAP/SMTP
Alter financial transactions | Modify POST data (change account numbers)
Inject malware              | Modify HTTP responses to include malicious JS
Harvest credit card numbers | Capture checkout form data
Eavesdrop on VoIP calls     | Intercept unencrypted RTP audio streams

Real-World MITM Example: Transaction Modification

Alice wants to send $100 to Bob (account 11111):

Alice sends:  "Transfer $100 to account 11111"
                          ↓
              [ATTACKER intercepts]
              Modifies:  "Transfer $100 to account 99999"
                          ↓
Bank receives: "Transfer $100 to account 99999" (attacker's account)
Bank confirms:  Transaction complete
Alice sees:     "Transfer confirmed to Bob" (attacker shows fake confirmation)

Alice loses $100. Bank processed a legitimate-looking instruction.

Defenses Against MITM Attacks

TLS/HTTPS

Properly implemented HTTPS prevents passive reading because the data is encrypted. Certificate validation prevents a MITM attacker from presenting a fake certificate — the browser rejects certificates not signed by a trusted CA.

HSTS (HTTP Strict Transport Security)

HSTS tells the browser to always use HTTPS for a domain and never fall back to HTTP. It defeats SSL stripping by preventing the initial HTTP connection the attacker needs to intercept.

Certificate Pinning

An application hard-codes the expected certificate or public key for specific servers. If an attacker intercepts the connection and presents a different certificate (even one signed by a trusted CA), the application rejects it immediately.

DNSSEC

DNSSEC adds cryptographic signatures to DNS records. A DNS resolver that supports DNSSEC verifies the signature on each response. Fake DNS responses from an attacker fail the signature check and are discarded.

Dynamic ARP Inspection (DAI)

DAI is a switch-level feature that validates ARP packets against a trusted database. ARP replies claiming a gateway's IP belongs to an unexpected MAC address are dropped immediately, blocking ARP poisoning attacks.

Defense Coverage Summary:
Attack Vector          | Defense
-----------------------|------------------------------------------
ARP Poisoning          | Dynamic ARP Inspection (DAI)
DNS Spoofing           | DNSSEC, trusted DNS servers
SSL Stripping          | HSTS, always use HTTPS
Rogue Wi-Fi MITM       | VPN, certificate validation, WPA3
Fake Certificate       | Certificate Pinning, CA monitoring
Session Cookie Theft   | Secure and HttpOnly cookie flags, HTTPS

MITM attacks are powerful because they exploit the fundamental trust models that networks rely on. The defenses — encryption, certificate validation, and protocol hardening — all work by ensuring that even if an attacker sits in the middle, they see only encrypted data they cannot read and cannot replace with a fake certificate the client will accept.