Man-in-the-Middle (MITM) Attack: Definition, How It Works, and Where You’ll See It
A man-in-the-middle (MITM) attack is a technique where an attacker secretly positions themselves between two communicating parties to eavesdrop, steal data, or modify messages in transit. The goal is usually credential theft, session hijacking, data manipulation, or covert surveillance.
A man-in-the-middle attack (MITM) happens when an attacker gets between two parties (like your browser and a website) to intercept, read, or change traffic without either side realizing. MITM is most common on rogue Wi‑Fi, via ARP spoofing or DNS spoofing, and in environments with TLS interception (legitimate or malicious).
How MITM attacks work
At a high level, a MITM has two phases: intercept (get in the path) and exploit (read/alter traffic). The exact mechanics depend on where the attacker operates: local network (Layer 2/3), name resolution (DNS), routing (BGP), or application/TLS.
1) Getting in the middle (interception)
Common interception methods include:
- Rogue Wi‑Fi / Evil Twin access point
- The attacker sets up a Wi‑Fi network that looks legitimate (same SSID as a café or corporate guest network).
-
Victims connect, and the attacker becomes the default gateway for their traffic.
-
ARP spoofing/poisoning (local LAN)
- On many IPv4 LANs, devices use ARP to map IPs to MAC addresses.
- An attacker can forge ARP replies so the victim associates the gateway IP with the attacker’s MAC.
-
Result: victim traffic flows through the attacker.
-
DNS spoofing / DNS cache poisoning
- The attacker manipulates DNS answers so the victim resolves
bank.exampleto an attacker-controlled IP. -
The victim connects to the wrong server, enabling credential harvesting or malware delivery.
-
Compromised router / upstream equipment
-
If a home router, office firewall, or ISP equipment is compromised, the attacker can passively observe or actively redirect traffic at scale.
-
Routing hijacks (e.g., BGP)
- Less common for SMBs day-to-day, but impactful: traffic to/from a target network is misrouted through an attacker-controlled AS.
2) Seeing or changing the data (exploitation)
Once traffic flows through the attacker, what they can do depends largely on encryption:
- If traffic is unencrypted (HTTP, some legacy protocols):
- The attacker can read and modify content directly (credentials, cookies, forms, downloads).
-
They can inject scripts, ads, or malware (classic “content injection” on open Wi‑Fi).
-
If traffic is encrypted (HTTPS/TLS):
- The attacker should not be able to decrypt or alter content without detection—unless they can defeat or bypass TLS. Common paths:
- TLS downgrade: forcing a client to use HTTP or weak/legacy settings (often prevented by modern browsers + HSTS).
- Certificate tricks:
- Installing a malicious root certificate on the device (via malware, MDM abuse, or local admin compromise).
- Leveraging a corporate TLS inspection proxy that’s misconfigured or overly permissive.
- User click-through: users ignoring certificate warnings (still a real-world issue in some environments).
- Application-level weaknesses: apps that skip certificate validation, don’t pin certificates, or accept any certificate.
Technical notes: what MITM looks like on a network
Below are practitioner-grade indicators and checks you can run when you suspect MITM on a LAN or Wi‑Fi.
Check for ARP poisoning (Linux/macOS)
# View ARP table; look for duplicate MACs or the gateway IP mapped to an unexpected MAC
arp -a
# Identify default gateway (Linux)
ip route | grep default
# Capture ARP traffic and watch for suspicious unsolicited ARP replies
sudo tcpdump -n -i any arp
Red flags: - Your default gateway IP suddenly maps to a MAC address that doesn’t match the router. - Frequent ARP replies that you didn’t request (“gratuitous ARP”) from a non-gateway host.
Validate DNS resolution and compare answers
# Compare DNS answers across resolvers
dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8
# On Windows PowerShell
Resolve-DnsName example.com
Red flags: - Different A/AAAA answers than expected for well-known domains (especially if they point to private IP space or unusual geographies). - DNS answers changing rapidly without a known CDN reason.
Spot TLS interception in a browser or via CLI
# Inspect certificate chain presented by a site
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -subject -dates -fingerprint
Red flags: - Issuer is an unexpected enterprise CA on unmanaged endpoints. - Certificate subject/issuer mismatch, unusual validity windows, or frequent certificate changes not consistent with the site.
Where you’ll encounter MITM attacks
MITM isn’t just a “movie hacker” trope—security teams see it in predictable places. These are the most common scenarios where it shows up in real environments:
1) Public Wi‑Fi and travel networks
Airports, hotels, conferences, cafés, and shared coworking networks are the classic MITM hunting grounds. Attackers may: - Stand up evil twin SSIDs (“HotelGuest”, “ConferenceWiFi”). - Use captive portals to trick users into installing profiles/certificates or entering credentials. - Passively harvest unencrypted traffic or target apps with weak TLS validation.
What to do: - Prefer mobile hotspot or known-good WPA2/WPA3 networks. - Use a VPN on untrusted networks (it won’t fix everything, but it meaningfully reduces exposure).
If you want an easy option for staff laptops on travel networks, a consumer VPN can reduce risk from rogue Wi‑Fi and local interception. Examples include NordVPN (Check NordVPN pricing →) or Surfshark (Try Proton VPN →)—just remember a VPN doesn’t stop phishing or a compromised endpoint.
2) Corporate environments with TLS inspection
Many organizations deploy TLS interception for DLP, malware scanning, or content controls. This is “legitimate MITM” by design—yet it creates risk when: - Root CAs are pushed too broadly (BYOD, unmanaged devices). - Exceptions are mismanaged (sensitive categories excluded improperly). - Inspection devices are misconfigured, outdated, or compromised.
What to do: - Restrict where inspection is allowed (e.g., block inspection for finance/health categories if required). - Monitor for unexpected new root CAs and certificate chain anomalies. - Ensure inspection appliances are patched and have strong admin controls and logging.
3) Home/SOHO router compromise
Small offices and homes often have: - Default credentials - Weak remote management settings - Outdated firmware
A compromised router can silently: - Change DNS servers (DNS hijack) - Redirect traffic - Inject content into HTTP pages
What to do: - Update router firmware, disable remote admin, set a strong admin password. - Pin DNS to trusted resolvers or use encrypted DNS (DoH/DoT) where feasible. - Monitor for unexpected DNS settings changes on endpoints.
4) Targeted attacks on admins and finance roles
Attackers focus MITM efforts where the payoff is high: - SaaS admin sessions - Payroll and banking logins - Email and SSO portals
What to do: - Enforce MFA (prefer phishing-resistant methods like FIDO2/WebAuthn where possible). - Use conditional access and device compliance checks. - Rotate credentials and revoke sessions immediately after suspected interception.
For credential hygiene, prioritize strong, unique passwords and secure sharing. A business password manager like 1Password can help centralize policy and reduce reuse (Try 1Password →).
5) Development and API troubleshooting gone wrong
Developers sometimes disable TLS verification or install debugging proxies. This can become an accidental “MITM-friendly” posture if it leaks into production or is copied into apps.
What to do: - Block builds that disable certificate validation. - Use certificate pinning where appropriate (balanced against operational complexity). - Run SAST checks for “insecure TLS” patterns.
Quick containment checklist (if you suspect a MITM attack)
1) Move affected devices to a trusted network (or disconnect).
2) Identify whether DNS/gateway settings changed (endpoint + router/firewall).
3) Check for new root CAs installed on endpoints.
4) Rotate exposed secrets: passwords, API keys, session tokens; revoke active sessions.
5) Review logs: VPN, proxy, IdP/SSO, firewall, DNS; look for new destinations and cert anomalies.
6) Patch/restore compromised network equipment; re-issue Wi‑Fi credentials if needed.
MITM attacks are best treated as a traffic integrity problem: protect the path (secure Wi‑Fi and routing), protect name resolution (DNS hardening), and protect the session (TLS correctness + MFA + rapid revocation).
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Related terms
A rogue Wi‑Fi access point impersonating a legitimate SSID to lure victims and intercept traffic.
Forging ARP messages on a LAN to redirect traffic through the attacker.
Manipulating DNS responses or settings to redirect users to attacker-controlled hosts.
Stealing or reusing session tokens/cookies to impersonate a user after login (often enabled by MITM on insecure channels).
A proxy terminates and re-establishes TLS connections to inspect traffic; legitimate in some enterprises but risky if abused or misconfigured.
A browser policy that forces HTTPS, reducing downgrade and SSL-stripping attacks.
An attacker downgrades HTTPS links to HTTP to capture traffic (less effective today due to HSTS and HTTPS-by-default).
An app remembers/validates expected certificates or public keys to resist fraudulent CAs and interception (can cause outages if not managed carefully).
A malicious DHCP server gives clients attacker-controlled gateway/DNS settings, enabling interception and redirection.
Internet routing manipulation that can reroute traffic through attacker networks for surveillance or disruption.