What Is a Man-in-the-Middle (MITM) Attack?
A man-in-the-middle (MITM) attack is a cyberattack in which an attacker covertly intercepts communication between two parties and relays it so both sides believe they have a direct, private connection.
You connect to the coffee shop Wi-Fi, open your bank, and the page loads. The padlock is there. Everything looks right. What you cannot see is that the access point you joined is a laptop in the corner running a fake hotspot, and every packet between you and your bank passes through it first. Your login goes out, the attacker reads it, then forwards it on so the real site responds normally. You see your balance. The attacker sees your credentials. Neither side noticed a third party in the middle.
A man-in-the-middle attack is exactly that: an attacker secretly positions themselves between two communicating parties, relaying and often altering traffic while both sides believe they are talking directly to each other. The attacker does not have to break a system. They break the assumption that a connection is private. MITRE ATT&CK catalogs the technique as Adversary-in-the-Middle (T1557), under the Credential Access and Collection tactics.
This guide covers what a MITM attack is, the two phases every one of them runs through, the specific techniques attackers use, a real-world case, and how blue teamers detect and prevent them. It is written for defenders who have to spot an interception that, by design, tries to look like nothing happened.
What is a man-in-the-middle attack?
A man-in-the-middle (MITM) attack is a cyberattack in which an attacker covertly intercepts communication between two parties, a user and a website, two servers, a client and an API, and relays it so that both endpoints believe they have a direct, private connection. The attacker sits on the path the data travels and can read it, record it, and modify it in transit.
The goal is usually one of three things: harvest sensitive data (credentials, session tokens, banking details, personal information), impersonate one of the parties to manipulate the other (change a payee account, approve a transaction, reset a password), or stage a later attack using what was captured. Because the attacker passes traffic through to its real destination, the victim's experience is normal. The page loads, the login works, the transfer completes. The interception is invisible from the endpoints.
What makes MITM different from a straightforward data theft is position. The attacker is not stealing a database from a server they broke into. They are standing in the communication channel itself, which means they see data while it is in motion and can tamper with it before either side acts on it. That is also why encryption matters so much here: a MITM attack succeeds or fails largely on whether the channel is properly encrypted and authenticated.
How a man-in-the-middle attack works
Every MITM attack runs through two phases: interception, then decryption. The first gets the attacker onto the path. The second turns the captured traffic into something useful.
Phase 1: Interception
First the attacker has to get in the middle of the traffic. The most common way is to control or poison the network path. That can mean standing up a rogue Wi-Fi access point that victims connect to, poisoning the local network so devices send their traffic to the attacker instead of the real gateway, or manipulating name resolution so a hostname points at the attacker's machine. Once traffic is flowing through them, the attacker uses capture tools to record everything and can selectively redirect or modify it.
The defining trick of this phase is transparency. The attacker forwards the victim's traffic to the genuine destination and forwards the response back, so the connection keeps working. Nothing breaks, no error appears, and the victim has no reason to suspect anyone is listening.
Phase 2: Decryption
Captured traffic is only valuable if the attacker can read it. If the connection was encrypted, the attacker has to defeat that encryption to get at the plaintext. The techniques here range from forcing the connection down to an unencrypted or weakly encrypted version, to presenting a forged certificate the victim's browser is tricked into trusting, to terminating the encrypted session at the attacker's machine and re-encrypting it onward. Whichever method, the result is the same: the attacker now holds the readable contents, the passwords, the session cookies, the account numbers, and can use them for fraud, identity theft, or follow-on intrusion.
Common man-in-the-middle attack techniques
MITM is a category, not a single method. Attackers use a range of techniques to get into the path and to read what flows through it. Most fall into one of the two phases above.
| Technique | Phase | What the attacker does |
|---|---|---|
| ARP spoofing | Interception | Sends forged ARP replies on a LAN so devices map the gateway IP to the attacker's MAC, routing local traffic through them |
| DNS spoofing | Interception | Corrupts name resolution so a legitimate hostname resolves to an attacker-controlled IP, sending the victim to a fake site |
| IP spoofing | Interception | Forges source IP addresses to impersonate a trusted host and divert or inject traffic |
| Rogue access point / evil twin | Interception | Stands up a Wi-Fi access point that mimics a legitimate one so victims connect through the attacker |
| HTTPS spoofing / forged certificates | Decryption | Presents a fraudulent SSL/TLS certificate so an encrypted-looking connection is actually controlled by the attacker |
| SSL stripping / downgrade | Decryption | Forces the connection from HTTPS down to plain HTTP, so traffic is sent unencrypted and readable |
| Session hijacking / cookie theft | Decryption | Steals session cookies in transit to take over an authenticated session without needing the password |
| Email hijacking | Either | Intercepts email threads to read activity and inject fraudulent instructions, often for payment redirection |
A few of these deserve more detail.
ARP spoofing is the classic local-network MITM. The Address Resolution Protocol has no authentication, so an attacker on the same LAN can send forged replies claiming the gateway's IP belongs to their machine. Devices update their ARP tables and start sending traffic to the attacker, who forwards it on. This is one form of ARP spoofing that maps directly to ATT&CK sub-technique T1557.002, ARP Cache Poisoning.
DNS spoofing attacks the lookup instead of the link. By poisoning a resolver cache or answering DNS queries faster than the real server, the attacker makes a trusted name resolve to their own address. The victim types the right URL and still lands on the attacker's page.
SSL stripping is a downgrade in disguise. The attacker sits between the victim and the site, speaks HTTPS to the real server, but serves plain HTTP to the victim, quietly removing the encryption the victim assumed was there. Because it strips the protection rather than breaking it, SSL stripping is a downgrade attack, and it is why the absence of HTTPS on a page that should have it is a real warning sign.
Session hijacking skips the password entirely. Web sessions are kept alive by a token, usually a cookie. An attacker who captures that cookie in transit can replay it and become the logged-in user, no credentials required, which is one reason interception on unencrypted connections is so dangerous.
A real-world MITM example: Trickbot's shaDll module
MITM is not theoretical. The Trickbot malware family included a module called shaDll that installed illegitimate SSL certificates on infected computers, which allowed the tool to gain access to the user's network. With those forged certificates trusted by the host, the module could redirect web activity, inject code, take screenshots, and gather data, a full interception capability planted on the endpoint itself.
According to CrowdStrike, the shaDll attack represented an apparent collaboration between two known cybercrime groups, LUNAR SPIDER and WIZARD SPIDER. The module used LUNAR SPIDER's BokBot proxy module as a foundation and then deployed WIZARD SPIDER's TrickBot module to complete the attack. The case shows how MITM techniques get packaged into commodity malware and operated by organized criminal crews, not just demonstrated in a lab.
Why MITM attacks are hard to detect
The whole design of a MITM attack is to leave the victim's experience untouched. Traffic still reaches its destination, responses still come back, pages still load. There is no crash, no error, no obvious sign that a third party is reading along. From the endpoints, a successful interception looks identical to a normal connection.
That puts most of the detection burden on the network and on cryptographic signals rather than on the user. The tells exist, but they are subtle: a certificate that does not match the expected issuer or is suddenly self-signed, a sensitive site loading over plain HTTP when it should be HTTPS, a gateway IP that maps to an unexpected MAC address, a flood of unsolicited ARP replies on the LAN, or DNS answers that disagree with an authoritative source. None of these jump out the way malware on a host does. They have to be looked for.
For defenders, the practical consequence is that you detect MITM by monitoring the things the attacker has to touch: certificates, ARP and DNS behavior, and the encryption state of connections that should never be plaintext.
How to detect a man-in-the-middle attack
Detection focuses on the artifacts an interception leaves on the network and in the crypto layer.
- Certificate validation. Watch for certificate warnings, mismatched or unexpected issuers, and self-signed certificates on sites that should present a trusted CA chain. A forged certificate is the core of HTTPS spoofing, so certificate anomalies are a primary signal. Certificate pinning and HSTS make forged certificates and downgrades far harder to pass off.
- ARP table monitoring. On a LAN, watch for a single MAC claiming multiple IPs, the gateway IP suddenly mapping to a new MAC, or bursts of gratuitous ARP replies. These are the fingerprints of ARP cache poisoning.
- DNS integrity. Compare resolved addresses against expected or authoritative answers, and use DNSSEC and trusted resolvers so a poisoned response stands out.
- Encryption-state monitoring. Alert when traffic that should be TLS appears as plain HTTP, which is the signature of SSL stripping. Sensitive destinations dropping to cleartext is rarely benign.
- Network behavior baselines. Unexpected new access points, rogue gateways, or traffic taking an unusual path are all worth surfacing. This is the kind of east-west and link-layer visibility that good network security monitoring provides.
How to prevent man-in-the-middle attacks
Prevention works on both fronts: deny the attacker the position, and make the captured traffic useless if they get it anyway.
- Encrypt everything, end to end. Strong TLS everywhere is the single most effective control, because properly authenticated encryption denies the attacker readable data even from the middle of the path. Enforce HTTPS, enable HSTS, and use certificate pinning where you can. Sound network security treats cleartext on sensitive paths as a defect.
- Require multi-factor authentication. MFA limits the damage of stolen credentials, so even captured passwords are not enough on their own. It does not stop session-cookie theft, which is why it pairs with the encryption controls above rather than replacing them.
- Use a VPN on untrusted networks. A VPN wraps traffic in an encrypted tunnel, which is the direct answer to the rogue-Wi-Fi opener. On any network you do not control, it removes the attacker's ability to read or tamper with what flows through them.
- Harden the local network. Use switch features like dynamic ARP inspection and DHCP snooping to blunt ARP and DHCP spoofing, and segment networks so a foothold on one segment does not expose the rest.
- Validate certificates and avoid open Wi-Fi. Train users to heed certificate warnings, check for HTTPS before entering credentials, and avoid open or unverified public networks, the access points most easily impersonated.
- Monitor and detect. Deploy the certificate, ARP, DNS, and encryption-state monitoring above so that an interception that slips past prevention still gets caught early.
The theme is the same as the attack: position and readability. Take away the attacker's ability to sit in the path, and encrypt strongly enough that sitting there buys them nothing.
How MITM relates to other attacks
A MITM attack is rarely the whole story. It is usually a means to an end, a way to harvest the credentials or session tokens that feed a larger intrusion. Captured passwords enable account takeover. Stolen session cookies enable immediate access without authentication. Intercepted email threads enable business email compromise and payment fraud. The interception is the collection step; the damage comes from what the attacker does with what they collected.
This is also why MITM sits at the network layer of most defensive models. The controls that stop it, strong encryption, certificate integrity, hardened link-layer protocols, network monitoring, are network and cryptographic controls, not endpoint antivirus. A signature scanner on a laptop will not notice that the laptop's traffic is being relayed through someone else's machine.
Frequently asked questions
What is a man-in-the-middle attack in simple terms?
A man-in-the-middle attack is when an attacker secretly inserts themselves between two parties who are communicating, such as a user and a website, and relays the messages between them. Both sides think they are talking directly to each other, but the attacker can read and change everything that passes through. The point is usually to steal credentials, session tokens, or financial data without the victim noticing.
How does a man-in-the-middle attack work?
It runs in two phases. First, interception: the attacker gets onto the communication path, often through a rogue Wi-Fi access point, ARP spoofing on a local network, or DNS manipulation, and forwards traffic so the connection still works. Second, decryption: if the traffic is encrypted, the attacker defeats that encryption, by stripping HTTPS down to HTTP, presenting a forged certificate, or terminating the TLS session, to read the contents.
What are the main types of man-in-the-middle attacks?
Common techniques include ARP spoofing and DNS spoofing to redirect traffic, rogue or evil-twin Wi-Fi access points, IP spoofing, HTTPS spoofing with forged SSL/TLS certificates, SSL stripping to downgrade HTTPS to plain HTTP, and session hijacking through stolen cookies. Email hijacking, intercepting email threads to inject fraudulent instructions, is another common variant used for payment fraud.
How can you detect a man-in-the-middle attack?
Detection relies on network and cryptographic signals because the victim's experience looks normal. Watch for certificate warnings, unexpected or self-signed certificates, sensitive sites loading over plain HTTP, ARP anomalies such as the gateway IP mapping to a new MAC or floods of unsolicited ARP replies, and DNS answers that disagree with an authoritative source. These are subtle and have to be monitored for deliberately.
How do you prevent man-in-the-middle attacks?
The strongest control is end-to-end encryption: enforce HTTPS, enable HSTS, and use certificate pinning so traffic stays unreadable and forged certificates fail. Add multi-factor authentication to limit stolen-credential damage, use a VPN on untrusted networks, harden the LAN with dynamic ARP inspection and DHCP snooping, segment networks, validate certificates, and avoid open Wi-Fi. Layer these so that defeating one does not hand over the data.
Does HTTPS stop man-in-the-middle attacks?
Properly implemented HTTPS makes MITM far harder because it encrypts and authenticates the connection, so an attacker in the path cannot read or forge the traffic without a certificate the browser trusts. But HTTPS can be undermined by SSL stripping (forcing the connection to plain HTTP) or by forged certificates the user is tricked into accepting. That is why HSTS, certificate pinning, and heeding certificate warnings matter alongside HTTPS itself.
The bottom line
A man-in-the-middle attack is an attacker quietly standing in the middle of a connection, relaying traffic so both sides think it is private while reading and sometimes altering what passes through. It works in two phases, getting onto the path through rogue access points, ARP spoofing, or DNS manipulation, then defeating any encryption through SSL stripping or forged certificates, and it is dangerous precisely because the victim's experience stays normal throughout. The defense follows from how the attack works. Encrypt strongly and authenticate properly so a position in the path buys nothing, harden the link layer and name resolution so getting into the path is hard, use a VPN on networks you do not trust, and monitor certificates, ARP, DNS, and encryption state so an interception that slips through still gets caught.
Frequently asked questions
<p>A man-in-the-middle attack is when an attacker secretly inserts themselves between two parties who are communicating, such as a user and a website, and relays the messages between them. Both sides think they are talking directly to each other, but the attacker can read and change everything that passes through. The point is usually to steal credentials, session tokens, or financial data without the victim noticing.</p>
<p>It runs in two phases. First, interception: the attacker gets onto the communication path, often through a rogue Wi-Fi access point, ARP spoofing on a local network, or DNS manipulation, and forwards traffic so the connection still works. Second, decryption: if the traffic is encrypted, the attacker defeats that encryption, by stripping HTTPS down to HTTP, presenting a forged certificate, or terminating the TLS session, to read the contents.</p>
<p>Common techniques include ARP spoofing and DNS spoofing to redirect traffic, rogue or evil-twin Wi-Fi access points, IP spoofing, HTTPS spoofing with forged SSL/TLS certificates, SSL stripping to downgrade HTTPS to plain HTTP, and session hijacking through stolen cookies. Email hijacking, intercepting email threads to inject fraudulent instructions, is another common variant used for payment fraud.</p>
<p>Detection relies on network and cryptographic signals because the victim's experience looks normal. Watch for certificate warnings, unexpected or self-signed certificates, sensitive sites loading over plain HTTP, ARP anomalies such as the gateway IP mapping to a new MAC or floods of unsolicited ARP replies, and DNS answers that disagree with an authoritative source. These are subtle and have to be monitored for deliberately.</p>
<p>The strongest control is end-to-end encryption: enforce HTTPS, enable HSTS, and use certificate pinning so traffic stays unreadable and forged certificates fail. Add multi-factor authentication to limit stolen-credential damage, use a VPN on untrusted networks, harden the LAN with dynamic ARP inspection and DHCP snooping, segment networks, validate certificates, and avoid open Wi-Fi. Layer these so that defeating one does not hand over the data.</p>
<p>Properly implemented HTTPS makes MITM far harder because it encrypts and authenticates the connection, so an attacker in the path cannot read or forge the traffic without a certificate the browser trusts. But HTTPS can be undermined by SSL stripping (forcing the connection to plain HTTP) or by forged certificates the user is tricked into accepting. That is why HSTS, certificate pinning, and heeding certificate warnings matter alongside HTTPS itself.</p>