A man-in-the-middle attack puts an attacker between two communicating parties so they can intercept or alter the data passing between them. It works when at least one side cannot prove who it is talking to. Authenticated, encrypted connections such as TLS, plus strict enforcement of them, defeat most of it.
What is a man-in-the-middle attack?
NIST's glossary defines it as an attack in which an attacker is positioned between two communicating parties in order to intercept and/or alter data traveling between them. OWASP describes the web version: the attacker splits the original TCP connection into two new connections, one between the client and the attacker, and one between the attacker and the server. Each side believes it is talking to the other. The attacker reads and can rewrite everything in between.
MITRE ATT&CK uses the term adversary-in-the-middle for the same idea (technique T1557) and notes the goal is usually to enable follow-on behavior such as network sniffing, transmitted data manipulation or credential capture.
How does an attacker get in the middle?
Position is the hard part. ATT&CK lists four sub-techniques that show how it happens in practice:
- ARP cache poisoning. On a local network, the attacker convinces hosts that the attacker's hardware address belongs to the gateway.
- DHCP spoofing. A rogue server hands out settings that route traffic through the attacker.
- Name resolution poisoning and SMB relay. Abusing local name lookup (such as LLMNR) to make a device talk to the wrong machine.
- Evil twin. A wireless access point that imitates a legitimate one.
Notice that none of these break encryption. They change where traffic goes. Encryption matters because of what happens next.
Why does TLS help?
RFC 8446, which defines TLS 1.3, states that TLS lets client and server applications communicate in a way designed to prevent eavesdropping, tampering and message forgery. The defense depends on the client validating the server's certificate. If an attacker presents a certificate for a name they do not control, a correct client rejects it.
The weak points are people and configuration. A user clicks through a certificate warning. An application disables certificate checks "just for testing" and ships that way. A site still answers on plain HTTP first, so the attacker intercepts that first request and never lets the upgrade happen.
HTTP Strict Transport Security addresses the last one. RFC 6797 defines a mechanism for sites to declare themselves accessible only over secure connections, so a browser that has seen the policy refuses to downgrade.
A constructed example
A developer connects to conference Wi-Fi and runs a script that calls an internal API. The script uses a library flag that skips certificate verification because a staging certificate once expired. An evil twin access point on that network answers, forwards requests and copies the bearer token from the header. The network was hostile, but the token leaked because the client would accept any certificate. Removing the flag, so the client rejects a mismatched certificate, ends the attack at the handshake.
How to check or apply this
- Search your code for disabled verification settings and fix them. Look in HTTP clients, test helpers and deployment scripts.
- Serve everything over TLS and redirect plain HTTP, then set HSTS once you are sure every subdomain supports HTTPS.
- Never train users to accept certificate warnings. Make the warning a stop sign.
- On networks you control, enable the switch and DHCP protections your equipment offers against rogue servers and ARP abuse, and disable name resolution protocols you do not use.
- For high-value tokens, prefer short lifetimes and binding to a device, so a copied token expires fast or fails elsewhere.
- Treat public Wi-Fi as hostile for any tool that handles credentials.
Quick check
Does HTTPS make a man-in-the-middle attack impossible?
No. It makes it fail when clients validate certificates and refuse downgrades. If a client skips validation or accepts a bad certificate, the attacker can still sit in the middle.
Is a man-in-the-middle attack the same as an adversary-in-the-middle attack?
They describe the same idea. MITRE ATT&CK uses the term adversary-in-the-middle for technique T1557, while NIST and OWASP use the older phrase.
Sources
- NIST CSRC Glossary: man-in-the-middle attack, fetched 18 October 2026.
- OWASP: Manipulator-in-the-Middle attack.
- MITRE ATT&CK T1557, Adversary-in-the-Middle.
- RFC 8446, TLS 1.3.
- RFC 6797, HTTP Strict Transport Security.
Last reviewed: 18 October 2026.
