A man-in-the-middle (MitM) attack is one where an attacker secretly places themselves between two parties that believe they are talking directly to each other, so they can read, alter or replay what passes between them. MITRE ATT&CK calls this adversary-in-the-middle (AiTM, T1557); in identity security "AiTM" usually means a phishing proxy. The same idea covers a poisoned office network, a fake café Wi-Fi hotspot and a phishing proxy that relays a real login page. This explainer starts with the plain-language picture, then gives practitioners the mechanisms, the controls that actually close each gap, how to roll them out, what to monitor and how the topic maps to NIST, CIS and ISO. It is for security engineers and network and identity teams.
Key takeaways
- The attacker sits in the path, not at either end. Interception works by redirecting traffic (ARP, DHCP, DNS, rogue Wi-Fi) or by luring the user to a proxy, then exploiting whatever the protocol fails to authenticate.
- Authenticated encryption is the core defence. TLS with strict certificate validation, HSTS with preload, and mTLS between services turn a successful redirect into a failed connection rather than a silent compromise.
- AiTM phishing defeats most MFA, not passkeys. A relay proxy captures the password, the one-time code and the session cookie; FIDO2 and passkeys fail at the proxy because the credential is bound to the real origin.
- Stolen sessions need binding, not just stronger login. Token binding approaches such as DPoP (RFC 9449), certificate-bound tokens (RFC 8705) and device-bound session tokens make a captured token far less useful.
- Detection lives in identity and network logs. Watch for ARP and DHCP anomalies, certificate errors, impossible-travel sessions and token reuse from a new device or network.
What it is
In plain terms, imagine posting a letter through a sorting office run by someone who opens it, reads it, perhaps changes it and reseals it before it reaches the recipient. Neither sender nor recipient notices anything. A MitM attacker does the same with network traffic or a web sign-in. The attack has two halves: getting in the path (interception) and doing something useful once there (eavesdropping, tampering, credential or session theft, or downgrading the connection to something weaker).
ATT&CK v20 describes T1557 Adversary-in-the-Middle as abusing features of common protocols that determine traffic flow, such as ARP, DNS and LLMNR, to force a device to talk through an attacker-controlled system, and notes that a Downgrade Attack (T1689) can be used to establish the position. Its sub-techniques are T1557.001 Name Resolution Poisoning and SMB Relay, T1557.002 ARP Cache Poisoning, T1557.003 DHCP Spoofing and T1557.004 Evil Twin. Session-focused outcomes appear separately as T1539 Steal Web Session Cookie and T1185 Browser Session Hijacking.
How it works
Every MitM attack exploits a step where one side accepts an answer without proof of who sent it. The table summarises the common interception routes in general terms and the control that removes the missing proof.
| Interception route | What is abused | Where it happens | Control that closes it |
|---|---|---|---|
| ARP cache poisoning (T1557.002) | ARP replies are unauthenticated, so a host accepts a forged mapping of the gateway IP to the attacker's MAC | Same layer 2 segment | Dynamic ARP Inspection with DHCP snooping on switches, 802.1X port authentication, segmentation, encryption above layer 2 |
| DHCP spoofing (T1557.003) | A rogue DHCP server hands out an attacker gateway or DNS server | Same broadcast domain | DHCP snooping (trusted ports only), NAC, monitoring for unexpected DHCP servers |
| Name resolution poisoning and relay (T1557.001) | LLMNR and NBT-NS fallbacks answer to anyone; captured authentication is relayed | Windows networks | Disable LLMNR and NBT-NS, require SMB signing and LDAP signing and channel binding, Kerberos over NTLM |
| Rogue or evil twin Wi-Fi (T1557.004) | Devices join a familiar SSID or respond to probe requests for remembered networks; captive portals harvest logins | Public and guest Wi-Fi, near offices | WPA3-Enterprise with EAP-TLS and server certificate validation, wireless intrusion detection, VPN or ZTNA on untrusted networks |
| DNS spoofing or hijack | Plain DNS answers can be forged or the resolver setting changed | Local network, home routers, compromised resolvers or registrars | DNSSEC validation, encrypted DNS (DoH or DoT) to a configured resolver, registrar lock, TLS validation as the backstop |
| TLS stripping and downgrade (T1689) | The first request goes over HTTP, or the client accepts an older protocol, so the attacker keeps the user on plaintext or weak crypto | Any path the attacker controls | HSTS with includeSubDomains and preload, TLS 1.2 minimum with TLS 1.3 preferred, disable legacy protocols |
| Rogue certificate interception | The client trusts a certificate it should not (user clicks through a warning, a rogue root is installed, an app skips validation) | Endpoints and apps | Strict validation with no click-through, managed trust stores, Certificate Transparency monitoring, mTLS for services |
| AiTM phishing proxy | The user is lured to a look-alike domain that relays the real sign-in page and captures the session cookie after MFA | The internet, via email, QR code or ad | FIDO2 or passkeys, certificate-based authentication, compliant device policies, token binding |
Once in the path, what the attacker can do depends on the protection above. Over plaintext they can read and change everything (T1040 Network Sniffing). Over correctly validated TLS they see only metadata, which is why most real-world interception now targets the human (accepting a bad certificate, signing in through a proxy) or the session token that survives after authentication. For the wire-level detail of handshakes and certificate checks, see the How TLS Works Guide.
The AiTM phishing variant
Microsoft's 2022 analysis of a campaign that attempted to target more than 10,000 organisations describes the pattern: a proxy between victim and real site shows the genuine login page, relays credentials and the MFA response, and keeps the resulting session cookie, which lets the attacker skip authentication entirely. Microsoft stresses that this is not a vulnerability in MFA, it is a weakness of any method where the user can be tricked into completing authentication on the wrong site. The full lifecycle and response steps are in the AiTM Phishing Guide; what happens to the stolen cookie afterwards is covered in the Session Hijacking and Cookie Theft Guide.
Why it matters
A successful interception usually leads to credential theft, session takeover, business email compromise, or tampering with data and software in transit. For machine-to-machine traffic the prize is often an API key or bearer token, which is as good as the identity that owns it until it expires.
Defences mapped to the attack stage
| Control | Stops | Does not stop | Key specifics |
|---|---|---|---|
| TLS everywhere with strict validation | Eavesdropping and tampering after redirection | Users who click through warnings; apps that skip validation | NIST SP 800-52 Rev 2 requires TLS 1.2 and TLS 1.3 support; disable SSL 3.0, TLS 1.0 and 1.1 |
| HSTS and preload (RFC 6797) | TLS stripping on repeat visits; click-through on certificate errors | The first visit, unless preloaded | Header ignored over HTTP; preload list needs max-age of at least 31536000, includeSubDomains and preload, and every subdomain on HTTPS |
| mTLS for services | Impersonation of either end between workloads | A compromised endpoint holding a valid key | Short-lived certificates from an internal CA; see the mTLS Guide |
| 802.1X and NAC | Unknown devices joining the wired or wireless LAN | A legitimate but compromised device | EAP-TLS with server certificate validation on clients; see the Network Access Control (NAC) Guide |
| Switch protections | ARP and DHCP spoofing | Attacks above layer 2 | DHCP snooping, Dynamic ARP Inspection, port security |
| DNSSEC and encrypted DNS | Forged DNS answers (DNSSEC); on-path snooping and diversion of queries (DoH, RFC 8484) | DNSSEC gives no confidentiality; DoH does not prove the data is authentic | Use both; RFC 4033 notes the stub-to-resolver hop needs its own channel security |
| Phishing-resistant MFA | AiTM phishing proxies | Malware on the endpoint stealing live sessions | FIDO2/WebAuthn passkeys, smart card or certificate-based authentication |
| Token binding | Replay of stolen access and refresh tokens or session cookies | Code running inside the legitimate client (RFC 9449 says so explicitly) | DPoP header with signed proof (RFC 9449); certificate-bound tokens with cnf x5t#S256 (RFC 8705); device-bound session tokens such as Entra Token Protection |
Passkeys defeat AiTM because the browser includes the site's origin in what the authenticator signs, so a credential created for the real domain will not produce a valid assertion for a look-alike proxy domain. FIDO Alliance describes phishing resistance as a core design goal of the challenge-response model. See the Phishing-Resistant MFA Guide and the DPoP Guide.
Rolling out the controls
- Inventory exposure: list public domains and subdomains, internal services still on HTTP, apps with custom certificate handling, and networks where untrusted devices share a segment with users.
- Harden TLS first: enforce TLS 1.2 minimum, redirect port 80 to HTTPS on the same host, then deploy HSTS with a short max-age (for example one day), raising it in steps once nothing breaks.
- Preload only when ready: submit to the preload list after every subdomain, including internal-only names, serves HTTPS. hstspreload.org warns that removal can take months and is not guaranteed in every browser, so treat preload as one-way.
- Fix the LAN: enable DHCP snooping and Dynamic ARP Inspection in monitor mode, review violations, then enforce. Disable LLMNR and NBT-NS through Group Policy in a pilot ring before estate-wide.
- Move privileged users to phishing-resistant MFA: administrators first, then high-risk roles, then everyone, with recovery that does not fall back to SMS.
- Bind tokens: run device-bound session policies in report-only mode, analyse sign-in logs across a full business cycle, then enforce for a pilot group. Enable DPoP or mTLS-bound tokens on APIs that issue long-lived tokens.
- Roll back safely: keep each change behind a policy toggle. HSTS cannot be withdrawn quickly from browsers that cached it (setting max-age=0 only reaches clients that visit again), so stage max-age increases rather than relying on rollback.
Choosing where to start
- Small organisations: most risk is AiTM phishing and public Wi-Fi. Passkeys or security keys on email and cloud admin, HSTS on public sites, and an always-on VPN or ZTNA client on laptops give the largest reduction for the least effort.
- Large or regulated organisations: add 802.1X with EAP-TLS, switch protections, mTLS for service meshes, token binding, and TLS inspection only where policy requires it, recognising that inspection is itself a sanctioned middlebox that must be secured. See the TLS Inspection Guide.
Detection and measurement
- Network signals: DAI and DHCP snooping violations, gratuitous ARP floods, new DHCP servers, rogue access points broadcasting corporate SSIDs, LLMNR or NBT-NS traffic after it was disabled.
- TLS signals: certificate validation failures in proxy and client logs, unexpected issuers for your domains in Certificate Transparency logs, clients negotiating TLS 1.0 or 1.1.
- Identity signals: sign-ins from unfamiliar ISPs or anonymising networks, a session cookie used from a different device or location than the sign-in, new inbox rules shortly after sign-in, as Microsoft lists for AiTM.
Useful metrics: percentage of public hostnames on the HSTS preload list; percentage of workforce sign-ins using phishing-resistant methods; number of switch ports with DAI enforced; count of internal services still accepting plaintext or TLS below 1.2; median time to revoke sessions after a suspected AiTM event.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-02, PR.AA-03, PR.IR-01, DE.CM-01 | Data in transit protected; users, services and hardware authenticated; networks protected and monitored |
| NIST SP 800-53 Rev 5 | SC-8 and SC-8(1), SC-23, IA-2(8), IA-3, AC-18, SC-20, SC-21, SI-4 | Transmission confidentiality and integrity, session authenticity, replay-resistant authentication, device authentication, wireless access, secure name resolution, monitoring |
| CIS Controls v8.1 | 3.10 Encrypt sensitive data in transit; 12 Network infrastructure management; 13 Network monitoring and defence | Encryption and network hardening safeguards |
| ISO/IEC 27001:2022 Annex A | A.8.20 Networks security, A.8.21 Security of network services, A.8.24 Use of cryptography | Network and cryptographic controls |
| MITRE ATT&CK v20 | T1557 and sub-techniques, T1689, T1539; mitigations M1041 Encrypt Sensitive Information, M1037 Filter Network Traffic, M1042 Disable or Remove Feature or Program, M1031 Network Intrusion Prevention | Technique and mitigation catalogue |
Common misconceptions
- "HTTPS means we are safe": only if certificates are validated without click-through and the first request cannot be stripped. HTTP-to-HTTPS redirects alone leave the first hop exposed, which is exactly what RFC 6797 and the preload list address.
- "MFA stops MitM": one-time codes and push approvals are relayed by AiTM proxies in real time. Only origin-bound methods break the relay.
- "MitM needs physical proximity": ARP and Wi-Fi attacks do, but DNS hijacks, rogue certificates and phishing proxies work from anywhere on the internet.
- "A VPN solves it": a VPN protects the path to the VPN endpoint. It does nothing against a phishing proxy the user visits willingly, and split tunnelling or captive portals can leave gaps.
- "DNSSEC encrypts DNS": it signs data and provides no confidentiality; encrypted DNS protects the channel and does not prove the answer is genuine.
Failure patterns seen in practice follow from these: internal admin consoles left on HTTP because they are "inside"; mobile and IoT apps that disable certificate checks for convenience; HSTS deployed without includeSubDomains so a forgotten subdomain becomes the way in; MFA rolled out with SMS fallback that the AiTM kit simply selects; and bearer tokens for service accounts with lifetimes measured in months, so one interception yields lasting access.
Related concepts
- Session hijacking: the usual payoff of AiTM. See the Session Hijacking and Cookie Theft Guide.
- Wireless attacks: evil twins, WPA3 and enterprise Wi-Fi design are covered in the Wi-Fi Security Guide.
- DNS attacks: resolver hardening, DNSSEC and protective DNS are in the DNS Security Guide.
- Machine identity: mTLS and token binding depend on well-run certificate lifecycles. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practitioner checklist
- Enforce TLS 1.2 minimum (TLS 1.3 preferred) on every external and internal service, and remove plaintext listeners except redirects.
- Deploy HSTS with includeSubDomains, raise max-age in stages, and submit apex domains to the preload list once all subdomains are ready.
- Block certificate warning click-through in managed browsers and audit apps for disabled validation.
- Enable DHCP snooping and Dynamic ARP Inspection, and use 802.1X with EAP-TLS for wired and wireless access.
- Disable LLMNR and NBT-NS, and require SMB signing and LDAP signing with channel binding.
- Validate DNSSEC on resolvers and point managed devices at an approved encrypted DNS resolver.
- Move administrators and then all users to passkeys or other FIDO2 authenticators, with no SMS fallback.
- Bind tokens with DPoP, mTLS or device-bound sessions for high-value APIs and apps, and keep bearer token lifetimes short.
- Alert on session reuse from new devices, Certificate Transparency entries you did not request, and rogue access points.
Standards and references
- MITRE ATT&CK: T1557 Adversary-in-the-Middle
- IETF: RFC 6797 HTTP Strict Transport Security (HSTS)
- HSTS Preload List Submission
- IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- IETF: RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
- IETF: RFC 4033 DNS Security Introduction and Requirements
- NIST: SP 800-52 Rev 2 Guidelines for TLS Implementations
- Microsoft Security: From cookie theft to BEC, AiTM phishing sites
Related NHI Mgmt Group resources: AiTM Phishing Guide · How TLS Works Guide · mTLS Guide · Phishing-Resistant MFA Guide · Drive-by Downloads Guide