A man-in-the-middle attack is, in NIST's words, "an attack in which an attacker is positioned between two communicating parties in order to intercept and/or alter data traveling between them." Both ends keep working normally, and neither sees the third party on the wire.
In 2011, attackers compromised the Dutch certificate authority DigiNotar. ENISA reported that "false certificates were created for hundreds of websites, including Google and Skype," and that "for two months, false certificates were used to eavesdrop on users in Iran." Every session was encrypted and every browser showed a padlock. That is what a man-in-the-middle attack looks like from the victim's side: nothing.
This page covers what a man-in-the-middle attack is, how attackers get into position, which controls break each technique, which controls are weaker than their reputation, and how Fluid Attacks tests for the weaknesses that make interception possible.
What is a man-in-the-middle attack?
A man-in-the-middle attack, or MITM attack, puts an attacker in the communication path between two endpoints that believe they are talking directly to each other. From there the attacker can read traffic, change it, replay it, or hold it. MITRE ATT&CK catalogs the behavior as Adversary-in-the-Middle (T1557) and describes adversaries positioning themselves between two or more networked devices.
The position is what makes it a man-in-the-middle attack. What the attacker does from there is a separate question, and it is where most explanations go wrong.
Being in the path does not mean reading the content. An attacker relaying TLS traffic without breaking the channel sees packet sizes, timing, and destinations, not plaintext. A man-in-the-middle attack that reads or modifies protected content needs the client to accept an identity it should reject: a certificate from a compromised authority, a certificate the application never validates, or a connection the browser was allowed to downgrade to HTTP. The problem is authentication more than encryption.
Three things get confused with a man-in-the-middle attack. Eavesdropping on an unencrypted channel needs access, not interposition. Spoofing forges an identity but may not relay anything. A compromised endpoint sees plaintext because it is one of the two parties, which is not the same as sitting between them.
How a man-in-the-middle attack works
Every man-in-the-middle attack has two stages: get into the path, then do something with the traffic. The stages are independent, and an attacker can succeed at the first while failing at the second. Against a correctly configured TLS connection, that is the normal outcome of a man-in-the-middle attack.
Stage one is positioning. The attacker manipulates a protocol that decides where traffic goes: address resolution, name resolution, address assignment, or wireless association. None were designed with authentication, which is why they still carry a man-in-the-middle attack decades after the problem was first described.
Stage two is acting on the traffic. The outcome depends on how the endpoints authenticate each other. Against plaintext protocols, the attacker reads and rewrites at will. Fluid Attacks' requirement 181, Transmit data using secure protocols, names HTTP, FTP, POP3, and Telnet as the examples, and maps to CAPEC-94, CWE-319, PCI DSS 4.2.1, and NIST SP 800-115. Against TLS, the attacker needs a validation failure. Against TLS plus a client that pins or presents its own certificate, the attacker usually needs code execution on the device.
The controls that stop each stage are different. Organizations buy the first set and leave the second unexamined, which is how a man-in-the-middle attack gets through a network that looks defended.
Types of man-in-the-middle attacks
The techniques below are the ones seen in real networks. MITRE classifies four as sub-techniques of T1557. SSL stripping and man-in-the-browser sit outside it because they attack the transport and the endpoint rather than the routing.
Technique | MITRE ID | What the attacker gets |
ARP poisoning | T1557.002 | Traffic for any host on the local segment |
DHCP spoofing | T1557.003 | Gateway and DNS server of its choosing |
LLMNR and NBT-NS poisoning | T1557.001 | NTLM authentication material from Windows hosts |
Evil twin Wi-Fi | T1557.004 | Everything a victim sends after associating |
SSL stripping and HTTP spoofing | — | Plaintext, by preventing the upgrade to HTTPS |
Man-in-the-browser | — | Session content after TLS has already terminated |
Techniques that enable a man-in-the-middle attack, with their MITRE ATT&CK classification.
ARP poisoning
The attacker answers ARP requests on a local segment, binding its own MAC address to the IP address of a legitimate host, usually the gateway. Traffic for that host reaches the attacker instead. ARP has no authentication, so the last answer wins.
DNS spoofing
The attacker returns forged responses to name lookups, sending the victim to infrastructure it controls. That is redirection, not interception, and the distinction matters: the victim's browser still validates the certificate at the destination. DNS spoofing becomes a full man-in-the-middle attack only when paired with a certificate the victim will accept, which is what the DigiNotar compromise provided.
SSL stripping and HTTP spoofing
The attacker intercepts the plaintext request a browser makes before any redirect to HTTPS, then serves an unencrypted copy of the site while keeping a proper HTTPS session with the real server. The victim sees a working page without a padlock. Fluid Attacks' weakness 131 covers the server-side condition that allows it: a missing or short-lived Strict-Transport-Security header.
Evil twin Wi-Fi
The attacker broadcasts an access point using the name of a network the victim's device already trusts. The device associates automatically, and every packet after that crosses the attacker's hardware. Fluid Attacks' pentesters use Aircrack-ng and bettercap for this kind of wireless assessment.
LLMNR poisoning and NTLM relay
This is the man-in-the-middle attack that does the most damage inside corporate networks, and it has nothing to do with coffee-shop Wi-Fi. When Windows fails to resolve a name through DNS, it falls back to Link-Local Multicast Name Resolution and NetBIOS Name Service, which broadcast the query to the local segment. An attacker answers, the victim authenticates, and the attacker receives an NTLMv2 hash to crack offline or relay elsewhere. Fluid Attacks' weakness 388 states that NTLM "can be vulnerable to several security flaws, including Relay attacks, Man in the Middle" and brute force. Fluid Attacks' internal penetration testing covers this technique, along with Kerberos ticket theft and IPv6 attacks.
Man-in-the-browser
Malware or a malicious extension operates inside the browser, after TLS has terminated. The channel is intact and the certificate is valid; the attacker reads and rewrites the decrypted page. No transport control stops it, which is why it counts as endpoint compromise.
IP spoofing
The attacker forges source addresses to impersonate a trusted host. On its own it rarely produces a usable man-in-the-middle attack on modern networks, but it supports the techniques above.
One note on tooling: mitmproxy, Wireshark, and OWASP ZAP all intercept traffic, and none is an attack tool by nature. Authorization is what separates a man-in-the-middle attack from an assessment.
Man-in-the-middle attacks at Fluid Attacks
Fluid Attacks tests for the conditions that make a man-in-the-middle attack possible: in applications, in infrastructure, and in the networks its pentesters are authorized to assess. Each weakness is catalogued, assigned a severity, and verified after remediation.
What we assess, and under what rules
Interception testing is scoped and authorized in writing before anything is instrumented, and Fluid Attacks keeps full control of the communication channel between the pentester and the target of evaluation. The tooling that makes an assessment realistic is the same tooling attackers use: OWASP ZAP is described in Fluid Attacks' own documentation as a "man-in-the-middle proxy," because reproducing a man-in-the-middle attack under controlled conditions is what an authorized tester has to do.
What it looks like in practice
Surface | Tooling | What a finding looks like |
Web and API transport | mitmproxy, Burp Suite Professional, OWASP ZAP | Weakness 016: insecure TLS versions accepted |
Application and service channels | Source and configuration review | Weakness 332: "Intercept communication and steal or forge requests and responses" |
HTTP response headers | Weakness 131: missing Strict-Transport-Security | |
Mobile app traffic | Frida, Objection, Mobile Application Security Testing (MAST) | Rule SAST-NATDC: a Kotlin TrustManager that accepts any certificate |
Wireless and internal networks | Aircrack-ng, bettercap, Wireshark | Weakness 388: NTLM authentication in use |
Surfaces where a man-in-the-middle attack is possible, the tooling Fluid Attacks' pentesters use on each, and the catalogued weakness a finding maps to.
The HSTS weakness as it appears in Fluid Attacks' database, with its remediation.
What manual testing finds that scanners miss
In Fluid Attacks' benchmark of 36 third-party AppSec tools against an application seeded with 1,201 vulnerabilities, a pentester detected 89.6% of them at 100% precision. The best-performing automated scanner in that exercise was Fluid Attacks' own, at 22.7% recall, corresponding to 8.8% of the application's total risk exposure measured in CVSSF. The pentester exclusively found 743 vulnerabilities, 86.8% of total risk exposure.
The flaws behind a man-in-the-middle attack split cleanly along that gap. A scanner reliably reports a missing header or a weak cipher suite. Establishing that an application accepts a certificate it should reject, across a specific flow with a specific client, takes someone doing it.
What security testing will not tell you
A scanner flags a missing Strict-Transport-Security header or a TrustManager that trusts everything. It does not tell you whether anyone is on the wire right now. Detecting a man-in-the-middle attack in progress is network telemetry and incident response work, not application security testing. Fluid Attacks reports the conditions that make interception feasible and verifies they were fixed.
The same caution applies to mobile defenses. Fluid Attacks' analysis of in-app protection makes the point that turning a control on is not the same as fixing the flaw underneath it: malicious-proxy detection and pinning are layers over a base that has to be sound first.
How we secure our own transport
Fluid Attacks' documented controls apply this page's recommendations to its own systems, closing every stage of a man-in-the-middle attack in turn. The domain accepts only TLSv1.3 end to end. Origins authenticate through Authenticated Origin Pulls, a mutual TLS arrangement backed by a private CA, so the TLS layer rejects handshakes without a leaf certificate signed by that CA. Every public handshake uses the X25519MLKEM768 hybrid post-quantum key exchange. The three primary zones are on the browser-baked preload list, so browsers refuse plaintext HTTP on the first request. Certificates for fluidattacks.com are valid for 14 days.
Hop | TLS | Origin authentication |
Browser → Cloudflare | TLS 1.3 | HSTS preload, first contact |
Cloudflare → ALB | TLS 1.3 | mTLS, private CA |
Cloudflare → CloudFront | TLS 1.3 | mTLS, private CA |
CloudFront → S3 origin | TLS, SigV4 | CloudFront OAC |
Fluid Attacks' public data path: every hop carries transport encryption and an identity check on the receiving side.
What actually stops a man-in-the-middle attack
Five controls do most of the work against a man-in-the-middle attack, and each stops a different stage. Deploying them without knowing which is which is how organizations end up protected against the attack they were not facing.
Control | What it stops | What it does not stop |
TLS certificate validation | Any attacker without a certificate the client accepts | A compromised or malicious CA in the trust store |
HSTS with preload | The plaintext first request, before data leaves the device | Interception after a valid TLS session is established |
Certificate pinning | A rogue CA, for one app against one server | Instrumentation of the app on a device the attacker controls |
Mutual TLS | A server that cannot prove its identity to the client, and the reverse | Traffic after either endpoint is compromised |
Phishing-resistant MFA | Credential and session theft through an AiTM proxy | Interception of traffic that carries no credentials |
Which stage of a man-in-the-middle attack each control interrupts, and where each one ends.
TLS certificate validation
This is the control everything else rests on. TLS gives confidentiality, integrity, and server authentication, and only the third one stops a man-in-the-middle attack. A client that encrypts to an unverified party has encrypted to the attacker.
The mechanism is clearest from the offensive side. Describing how an interception proxy is set up against an Android app, Fluid Attacks security analyst Jonathan Armas notes that the proxy's certificate has to reach the device's trusted list first: "Without this, we cannot intercept secure channel traffic." That sentence is the defense, read backwards: a man-in-the-middle attack on TLS starts with trust, not with cryptography.
The common failure is not a missing certificate but a disabled check. Fluid Attacks' rule SAST-NATDC detects Kotlin TrustManager implementations that bypass certificate validation. The connection is HTTPS. The validation is gone.
A `TrustManager` with an empty check method accepts any certificate presented to it; the corrected version uses the system trust store.
HSTS and the preload list
RFC 6797 defines HTTP Strict Transport Security (HSTS). Its Strict-Transport-Security header tells a browser to use HTTPS for a domain and stops users from clicking through certificate warnings. It closes SSL stripping for every connection after the first.
The first connection is the hole, and preloading closes it. Domains on the browser-baked preload list are compiled into the browser, so plaintext never leaves the device. OWASP warns that the preload flag carries permanent consequences: a listed domain cannot be returned to HTTP quickly.
Certificate pinning is narrower than its reputation
Advice to pin by default is overdue for correction, and OWASP is direct: "There is almost no situation where you should consider pinning," and "If it is not a native mobile application, do not pin." Certificate pinning solves one problem, a certificate authority you do not trust, for one client-server pair you control both ends of. It does not survive an attacker with instrumentation access to the device, and it breaks whenever a certificate rotates unexpectedly.
Mutual TLS
Mutual TLS makes both sides prove identity. It is the right control for service-to-service traffic, where a man-in-the-middle attack inside a cluster is as plausible as one on a public network. Fluid Attacks' requirement 088 asks systems handling business-critical information to require client certificates, mapping to NIST SP 800-63B 5.2.5 and OWASP Top 10 A07. Fluid Attacks recommends it for all communication between a Model Context Protocol client and a remote server.
Phishing-resistant MFA
Adversary-in-the-middle phishing kits run a reverse proxy between the victim and the real identity provider. The victim enters a password and a one-time code, the proxy forwards both, catches the session cookie the server returns, and replays it. Codes sent by SMS or generated in an app do not survive this form of man-in-the-middle attack. CISA describes SMS and voice MFA as "Vulnerable to phishing, SS7, and SIM swap attacks," and calls FIDO/WebAuthn "the only widely available phishing-resistant authentication." The reason is binding: a FIDO credential will not sign a challenge for a domain that does not match its registered origin, so the proxy gets nothing.
Classic SSL stripping and a modern AiTM proxy, with the point where HSTS preload and FIDO2 interrupt each one. Own work.
How to detect a man-in-the-middle attack
Detection of a man-in-the-middle attack is behavioral. You look for the side effects of someone being in the path, because the interception itself raises no alert. MITRE's detection strategy DET0296 lists what to watch for a man-in-the-middle attack: "suspicious DNS/ARP poisoning attempts, unauthorized modifications to registry/network configuration" and "abnormal TLS downgrade activity." Its analytics also cover unauthorized edits to /etc/hosts and /etc/resolv.conf, suspicious ARP broadcasts, and configuration changes on network devices.
Three signals are worth instrumenting first, because they are cheap and specific: certificates that do not match what your monitoring expects for a domain, TLS version or cipher negotiation dropping below your floor, and ARP or DNS responses that change the mapping of a host you control.
For users, the advice that actually detects a man-in-the-middle attack is narrower than the usual checklist: never click through a certificate warning. A browser reporting a hostname mismatch, an expired certificate, or an untrusted issuer is describing the exact condition a man-in-the-middle attack needs.
When the chain of trust fails
Both cases below ended with encrypted sessions being read, and neither involved breaking encryption. They remain the clearest public evidence that a man-in-the-middle attack defeats HTTPS through trust rather than through cryptography.
DigiNotar and Superfish
In 2011, attackers compromised the Dutch certificate authority DigiNotar and issued certificates the whole web trusted, including one for Google. ENISA's analysis records that false certificates "were used to eavesdrop on users in Iran" for two months. Browsers removed trust in DigiNotar and the company went bankrupt.
In 2015, consumer Lenovo laptops shipped with adware that ran a man-in-the-middle attack by design, installing its own root certificate authority in the Windows trust store to inject content into HTTPS pages. CISA's alert TA15-051A warned that the flaw let an attacker "successfully impersonate (spoof) any website."
The two differ in where the betrayal happened. DigiNotar broke the public trust hierarchy; Superfish broke the trust store on the device. Both produced a man-in-the-middle attack that no amount of encryption would have prevented.
Conclusions
A man-in-the-middle attack is an authentication problem wearing an encryption costume. Encryption without verified identity protects nothing, which is what DigiNotar and Superfish both demonstrated on sessions that looked secure in the address bar.
The controls that work against a man-in-the-middle attack are specific: validate certificates and never disable the check, send HSTS and preload the domain, require mutual TLS where both ends are yours, and move authentication to FIDO2 where session theft is the real risk. Pinning is a narrow tool, not a default.
Testing tells you which of these you have. The weaknesses behind a man-in-the-middle attack — insecure channels, obsolete TLS versions, missing headers, permissive trust managers, legacy NTLM — are all findable before an attacker finds them, and a man-in-the-middle attack is one of the few threats where the fix list is this short and this specific.
Frequently asked questions
Does HTTPS prevent man-in-the-middle attacks?
Only when certificate validation works. HTTPS encrypts the channel and authenticates the server, and it is the authentication that blocks a man-in-the-middle attack. An application that disables certificate checks, trusts a rogue CA, or accepts a hostname mismatch is encrypting its traffic straight to the attacker. Fluid Attacks' rule SAST-NATDC exists because disabled validation inside otherwise correct HTTPS code is common.
How does HSTS stop SSL stripping?
It removes the plaintext request SSL stripping depends on. The Strict-Transport-Security header tells a browser to use HTTPS for a domain and to refuse to let users click through certificate warnings. It protects every connection after the first. Preloading closes the first one too, which is why Fluid Attacks submitted its three primary zones to the preload list.
Does certificate pinning prevent all man-in-the-middle attacks?
No. OWASP now advises against pinning in most cases, stating that "there is almost no situation where you should consider pinning" and that non-native applications should not pin at all. Certificate pinning defends one client-server pair against an untrusted authority. It does not stop a man-in-the-middle attack mounted from a device the attacker can instrument, and it breaks when certificates rotate.
Can two-factor authentication stop an adversary-in-the-middle attack?
Not if the second factor is an SMS or an app-generated code. An AiTM proxy forwards the code in real time and steals the authenticated session cookie, so the man-in-the-middle attack succeeds with the second factor in place. CISA calls FIDO/WebAuthn "the only widely available phishing-resistant authentication," because a FIDO credential refuses to sign a challenge for a domain that does not match its registered origin.
Does Fluid Attacks test for man-in-the-middle weaknesses?
Yes, across application code, transport configuration, mobile apps, and authorized network assessments, with each finding mapped to a catalogued weakness and verified after remediation. In Fluid Attacks' benchmark of 36 third-party AppSec tools against an application with 1,201 seeded vulnerabilities, a pentester reached 89.6% recall at 100% precision, while the best automated scanner reached 22.7%. The flaws behind a man-in-the-middle attack fall on both sides of that gap: scanners find the missing header, people find the flow that accepts a certificate it should reject.
Test the controls you think you have
Our pentesters and scanners check your transport configuration, certificate validation, and authentication the way an attacker running a man-in-the-middle attack would, so the weaknesses that make interception possible get fixed before someone uses them. Start free trial · Contact us.
Get started with Fluid Attacks' application security solution right now
