# Man-in-the-middle (MITM) attacks: how they work, examples and prevention

> A man-in-the-middle attack puts an attacker between you and a service to read or alter traffic. How ARP, Wi-Fi, DNS and AiTM attacks work, and how to stop them.

- URL: https://computese.com/understanding-man-in-the-middle-mitm-attacks/
- Author: Duong Quan Nguyen, CEO, Computese
- Published: 2024-10-19
- Updated: 2026-09-25
- Topics: Security

## In short
- A man-in-the-middle (MITM) attack puts an attacker between two parties who think they are talking directly, so the attacker can read, change or replay their traffic. Unlike passive eavesdropping, the attacker must first redirect that traffic.
- Attackers get in the middle by abusing protocols that believe whoever answers: ARP and DHCP on a local network, Wi-Fi network names, DNS, and BGP routes between internet providers.
- Encryption alone does not stop MITM; checking who is at the other end does. HSTS removes two of a network attacker's main openings: the downgrade to HTTP and the option to click through a certificate warning.
- Adversary-in-the-middle phishing relays a real sign-in page and keeps the session cookie issued after MFA. Codes and push approvals can be relayed; passkeys and FIDO2 security keys cannot, because they only sign in to the real domain.
- Defend by layer: HTTPS with HSTS, phishing-resistant MFA, DNSSEC and encrypted DNS, WPA3 with 802.1X, Dynamic ARP Inspection on switches, and a firm rule never to click through a certificate warning.

A man-in-the-middle (MITM) attack is one where an attacker positions themselves between two parties who believe they are talking directly, such as your laptop and your bank, and relays their traffic so they can read it, change it or steal passwords and session cookies inside it. Unlike passive eavesdropping, it is active: the attacker must first redirect the traffic.

This guide explains how attackers get into the middle of a connection, from ARP spoofing on an office network to BGP hijacks across the internet, what they do once they are there, how adversary-in-the-middle phishing gets past multi-factor authentication, real examples, and the defences that work at each layer. If you want the listening-only kind of attack, read our guide to [eavesdropping attacks](https://computese.com/understanding-eavesdropping-attacks-how-they-work/); for the broader term, see [snooping in cyber security](https://computese.com/understanding-snooping-attacks-how-they-work/).

## What is a man-in-the-middle attack?

[NIST's glossary](https://csrc.nist.gov/glossary/term/man_in_the_middle_attack) defines it as an attack where the attacker sits between two communicating parties in order to intercept or alter the data passing between them. It adds a detail that matters later: in authentication, the attacker sits between the person signing in and the service that verifies them.

The attack has several names for one position: man-in-the-middle, person-in-the-middle, [manipulator-in-the-middle](https://owasp.org/www-community/attacks/Manipulator-in-the-middle_attack) (OWASP), [adversary-in-the-middle](https://attack.mitre.org/techniques/T1557/) (MITRE ATT&CK technique T1557) and, in IETF documents, an on-path attacker. OWASP describes the mechanics plainly: the attacker splits one connection into two, one with the victim and one with the real server, and acts as a proxy that can read, insert and modify what passes through. Over HTTPS that means two separate TLS sessions, and the victim's browser should notice that the certificate it receives is not the real server's.

Every MITM attack therefore needs three things:

1. **A position on the path.** On a switched network or across the internet, other people's traffic does not reach an attacker by default. The attacker has to abuse a protocol that decides where traffic goes: ARP, DHCP, DNS, Wi-Fi association or BGP.
2. **Relaying.** Both ends must keep working, or the victim notices. MITM tools forward everything, which is why nothing looks broken.
3. **A way past authentication.** Encryption alone does not stop a MITM, because the attacker can encrypt too. What stops it is each side proving who it is: the server with its certificate, the user with their sign-in. Most of the attacks below are ways of defeating one of those two checks.

## How MITM differs from eavesdropping and snooping

The three terms overlap, and quiz questions often blur them. The difference is what the attacker has to do and what they can do afterwards.

|                                    | Snooping                                             | Passive eavesdropping                             | Man-in-the-middle                                                            |
| ---------------------------------- | ---------------------------------------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------- |
| What it is                         | Unauthorized access to data, in transit or at rest   | Listening to traffic the attacker can already see | Sitting between two parties and relaying their traffic                       |
| Does the attacker change anything? | Not necessarily                                      | No                                                | Yes: routing, names or trust, and sometimes the data itself                  |
| What it threatens                  | Confidentiality                                      | Confidentiality                                   | Confidentiality, integrity and authentication                                |
| Typical example                    | Reading an unlocked screen or someone else's mailbox | Capturing traffic on an open Wi-Fi network        | ARP spoofing, an evil twin, an AiTM phishing proxy                           |
| Trace left behind                  | Access logs, sometimes                               | Almost none                                       | Duplicate addresses, certificate warnings, unusual sign-ins                  |
| Main defence                       | Least privilege and access reviews                   | Encryption in transit                             | Checking who is at the other end: certificates, HSTS, phishing-resistant MFA |

The integrity column is the one that makes MITM dangerous. OWASP's own example is an attacker who changes the amount of a money transfer inside an intercepted session, and [Google's Chrome team warns](https://security.googleblog.com/2025/10/https-by-default.html) that a single plain-HTTP navigation lets an attacker load content of their choosing, malware included.

## How attackers get into the middle

### ARP spoofing on a local network

On an Ethernet or Wi-Fi segment, devices find each other's hardware (MAC) addresses with the Address Resolution Protocol. [MITRE ATT&CK notes](https://attack.mitre.org/techniques/T1557/002/) that ARP is stateless and has no authentication, so a device updates its cache from any reply it receives, including a gratuitous one nobody asked for. An attacker on the same segment tells the victim that the router's IP address belongs to the attacker's MAC address, and can tell the router the same about the victim for the return traffic. Both then send their packets to the attacker, who forwards them on. Tools such as Ettercap, listed by OWASP, automate the whole thing.

![A laptop, a network switch and a router in a row. A second laptop, in orange, is plugged into the switch, and the first laptop's traffic now detours through it before reaching the router.](https://computese.com/images/blog/understanding-man-in-the-middle-mitm-attacks/arp.769620507b-1536.webp)

*Nothing on the victim's screen changes: the traffic still reaches the router, only by way of the attacker.*

Two related tricks work on the same local segment:

- **Name resolution poisoning.** When DNS cannot resolve a name, Windows falls back to LLMNR and NBT-NS broadcasts. An attacker running a tool such as Responder answers them, and the victim sends its username and NTLMv2 hash, which can be cracked offline ([MITRE T1557.001](https://attack.mitre.org/techniques/T1557/001/)).
- **Rogue DHCP.** A fake DHCP server hands devices a network configuration that names the attacker's system as their DNS server or gateway ([MITRE T1557.003](https://attack.mitre.org/techniques/T1557/003/)).

All three need the attacker on your local network: a compromised PC, a device plugged into a spare port, or a shared Wi-Fi network.

### Rogue access points and evil twins

An [evil twin](https://attack.mitre.org/techniques/T1557/004/) is an access point that broadcasts the same network name (SSID) as a real one, often with a stronger signal. MITRE notes that attackers also listen for devices probing for networks they have joined before and answer with the matching name, so a phone can connect on its own to what it believes is the office network. Once a device joins, the attacker is its gateway: every packet passes through them, and a fake captive portal can ask for credentials. Airports, coffee shops and libraries are typical locations, and MITRE records the APT28 group using a Wi-Fi Pineapple for exactly this. Our [eavesdropping guide](https://computese.com/understanding-eavesdropping-attacks-how-they-work/) illustrates the setup; here, the point is that an evil twin gives the attacker the position for everything that follows.

### DNS spoofing and cache poisoning

Whoever answers a DNS query decides where your browser goes. An attacker already in the middle on a local network can answer queries directly, which is DNS spoofing. Cache poisoning goes further: it gets a forged answer into a resolver's cache, so every user of that resolver is sent to the wrong address. A [2008 CERT/CC vulnerability note](https://www.kb.cert.org/vuls/id/800113) described how the DNS protocol's 16-bit transaction ID, combined with the fixed source ports many implementations used, let attackers inject forged answers into caching resolvers. Randomizing source ports made the attack far harder, but CERT/CC noted that only protocol changes such as DNSSEC could prevent it completely.

The most damaging DNS attacks skip the protocol altogether. In January 2019, CISA's [Emergency Directive 19-01](https://www.cisa.gov/news-events/directives/ed-19-01-mitigate-dns-infrastructure-tampering) described attackers who took over accounts that manage DNS records for several US federal agency domains, pointed A, MX and NS records at their own servers, and then obtained valid TLS certificates for those domains. Because the certificates were valid, users saw no warning at all.

### BGP hijacking

The Border Gateway Protocol, which carries routes between internet providers, largely trusts each network to announce only addresses it is allowed to announce. On April 24, 2018, [Cloudflare documented](https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/) a two-hour hijack in which eNet (AS10297) announced more-specific routes for part of the address space of Amazon's Route 53 DNS service. The hijacked servers answered queries for myetherwallet.com with addresses at a Russian provider, which poisoned the resolvers that used them. The fake site presented a self-signed certificate; users who clicked through the warning handed over their logins, which were used to steal Ethereum. The fix at the routing layer is route origin validation with RPKI ([RFC 6811](https://www.rfc-editor.org/rfc/rfc6811.html), which counts "monkey-in-the-middle" attacks among the threats it addresses), and that is work for ISPs and cloud providers. For everyone else, the lesson is the certificate warning.

## What attackers do once they are in the middle

### TLS stripping, and why HSTS stops it

Many visits start with a typed name or a plain `http://` link, so the first request goes out unencrypted and the site answers with a redirect to HTTPS. An attacker in the middle catches that redirect, keeps the browser on HTTP and talks HTTPS to the real site on the victim's behalf. The victim sees the right site, only without the padlock. This is TLS stripping, also called SSL stripping, and the [HSTS preload site](https://hstspreload.org/) lists it as the protocol downgrade that HSTS prevents, alongside cookie hijacking.

![A laptop connects to a middle box over a line with an open orange padlock, and the middle box connects to a web server over a line with a closed padlock.](https://computese.com/images/blog/understanding-man-in-the-middle-mitm-attacks/strip.0f1168315e-1536.webp)

*The site is still encrypted, just not on the victim's side of the attacker: the one hop that matters.*

[HTTP Strict Transport Security (RFC 6797)](https://www.rfc-editor.org/rfc/rfc6797.html) closes the gap. A site sends one response header:

```http
Strict-Transport-Security: max-age=31536000; includeSubDomains
```

From then on, for as long as `max-age` says, the browser rewrites every `http://` link to that site as `https://` before sending anything, and treats any certificate error as fatal, with no button to continue. The weakness is the first visit, before the browser has seen the header, which the RFC calls the bootstrap MITM vulnerability. The **HSTS preload list** covers it: domains on the list are built into Chrome, and Firefox, Safari and Edge use lists based on Chrome's, so the browser never tries HTTP for them at all.

As of September 2026, preloading is a commitment. The preload site requires a `max-age` of at least 31,536,000 seconds (one year), `includeSubDomains`, the `preload` directive and HTTPS on every subdomain, including internal ones, and it warns that removal is slow. It now says preloading is not recommended for most sites, because Chrome and Safari already upgrade navigations to HTTPS by themselves; preloading adds value when those upgrades fail in the presence of an active attacker, which is exactly the MITM case. Turn on HSTS for every site you run, and preload a domain once you are sure all of its subdomains will stay HTTPS-only. Browsers are moving the same way: in October 2025, [Google said](https://security.googleblog.com/2025/10/https-by-default.html) that Chrome 154, scheduled for October 2026, turns on "Always Use Secure Connections" for public sites by default, asking the user before the first visit to a public site without HTTPS. Our guide to [renewing an SSL certificate](https://computese.com/ssl-certificate/) covers the other half: a certificate that expires on an HSTS site locks every visitor out.

### Certificate warnings people click through

If stripping fails, the attacker can present their own certificate and hope. The browser shows a warning, and many people continue. In a [2013 field study of more than 25 million browser warnings](https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/akhawe), users clicked through 70.2% of Google Chrome's SSL warnings and 33.0% of Mozilla Firefox's. RFC 6797 is blunt about it: letting users click through certificate errors is "a recipe for a man-in-the-middle attack", which is why a site that sends HSTS opts out of the button entirely.

Two situations produce no warning at all, which makes them worse:

- **A rogue root certificate on the device.** In February 2015, [US-CERT (now part of CISA) warned](https://www.cisa.gov/news-events/alerts/2015/02/20/lenovo-superfish-adware-vulnerable-https-spoofing) that Superfish VisualDiscovery adware, pre-installed on some Lenovo PCs from September 2014, installed its own trusted root certificate and intercepted, decrypted and re-encrypted all browser HTTPS traffic, a man-in-the-middle built into the machine. Its private key could be recovered from the software, so any attacker could create certificates those PCs would trust, and uninstalling the software did not remove the certificate.
- **A valid certificate obtained through DNS control**, as in the 2019 CISA directive above. Monitoring Certificate Transparency logs for certificates you did not request is how that case is caught.

### Session cookie theft

After you sign in, the site gives your browser a session cookie, and from then on that cookie, not your password, is what proves who you are. [MITRE ATT&CK (T1539)](https://attack.mitre.org/techniques/T1539/) notes that a stolen session cookie lets an attacker use a web application as the signed-in user without credentials, and can get around some forms of multi-factor authentication. On any plain HTTP request, an attacker in the middle can read and inject cookies. HTTPS with HSTS removes that chance, and the `Secure` cookie attribute, described in RFC 6797's introduction, tells the browser to send a cookie only over an encrypted connection. [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) points to an emerging answer for the cookies that do get copied: Device Bound Session Credentials, which prove possession of a key held on the device instead of presenting a bearer token anyone can replay.

## Adversary-in-the-middle phishing: stealing the session after MFA

AiTM phishing moves the middle from the network to the sign-in page, which is why it works from anywhere. The victim follows a link to a look-alike domain. Behind it, a proxy loads the real sign-in page and relays every step: the victim types their password, approves the push notification or enters the code, the real service issues a session cookie, and the proxy passes it on while keeping a copy.

![A laptop signs in through a proxy server to a real sign-in server, with a phone approving the login. The server sends back a cookie token, and the proxy keeps an orange copy of it.](https://computese.com/images/blog/understanding-man-in-the-middle-mitm-attacks/aitm.ef1e3ae857-1536.webp)

*MFA did its job and the sign-in succeeded. The attacker never needed the password again, only the cookie that came back.*

[Microsoft Threat Intelligence reported](https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/) on July 12, 2022 that one AiTM campaign had targeted more than 10,000 organizations since September 2021, using the open-source Evilginx2 kit against Office 365 (now Microsoft 365) sign-ins. The phishing page held two TLS sessions, one with the victim and one with the real site. Microsoft stressed that this is not a vulnerability in MFA: the attacker steals the session after it, whatever sign-in method the user chose. In some cases the attackers started payment fraud from the victim's mailbox as little as five minutes after stealing the session. A [June 2023 follow-up](https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/) described a kit from a group Microsoft tracks as Storm-1167, sent from a compromised trusted vendor. After replaying the stolen cookie, the attacker added a new phone-based MFA method, which the tenant's settings allowed without an MFA challenge, then sent more than 16,000 phishing emails to the victim's contacts. Recovery meant revoking session cookies and rolling back the MFA change, not just resetting a password. The kits keep changing (Microsoft names Evilginx2, Modlishka, Muraena, EvilProxy and NakedPages, and [MITRE's T1557 entry](https://attack.mitre.org/techniques/T1557/) now lists newer ones such as Kali365), but the mechanism does not.

That mechanism is also why most MFA fails against it. A one-time code or a push approval is something the user relays, and a proxy relays it too. NIST SP 800-63B-4 states that authenticators whose output is entered by hand, such as one-time passwords and out-of-band codes, are not phishing-resistant for exactly this reason. WebAuthn, the standard behind FIDO2 security keys and passkeys, is: the response is cryptographically bound to the domain name the browser actually connected to, so a proxy on a look-alike domain receives nothing the real site will accept. [CISA's October 2022 fact sheet](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) calls FIDO/WebAuthn the only widely available phishing-resistant authentication, with smart-card (PKI) sign-in as the less widely available alternative. A [passkey](https://fidoalliance.org/passkeys/) is a FIDO credential of this kind, stored on a phone, computer or security key, and either synced between a person's devices or bound to one.

> [!IMPORTANT]
> Passkeys and FIDO2 security keys are the one control that defeats AiTM phishing. Conditional access, sign-in alerts and short session lifetimes limit the damage, but a code or a push approval can always be relayed.

## Real man-in-the-middle attack examples

Documented cases show the same pattern: a position on the path, then a failed or bypassed identity check.

| When         | What happened                                                        | How the attacker got in the middle                                          | What would have stopped it                                          |
| ------------ | -------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| 2014 to 2015 | Superfish adware on some Lenovo PCs intercepted all browser HTTPS    | A pre-installed trusted root certificate with a recoverable private key     | An inventory of trusted roots; removing the rogue certificate       |
| 2018         | MyEtherWallet users lost Ethereum                                    | BGP hijack of Route 53 addresses, poisoned DNS, a self-signed certificate   | RPKI filtering by providers, HSTS, not clicking through the warning |
| 2019         | DNS tampering against US federal agency domains                      | Stolen DNS account credentials, then valid certificates for the domains     | MFA on DNS accounts, Certificate Transparency monitoring            |
| 2021 to 2022 | AiTM phishing aimed at more than 10,000 organizations                | An Evilginx2 proxy relaying the Office 365 sign-in page                     | Phishing-resistant MFA, conditional access                          |
| 2023         | Storm-1167 AiTM and business email compromise                        | An indirect-proxy sign-in page, linked from a compromised vendor's email    | Phishing-resistant MFA, revoking sessions, MFA to add MFA methods   |
| Various      | APT28 evil twins; LuminousMoth ARP spoofing; Lazarus Group Responder | Rogue Wi-Fi, forged ARP replies and poisoned name resolution (MITRE ATT&CK) | WPA3 with 802.1X, Dynamic ARP Inspection, LLMNR and NBT-NS disabled |

## How to prevent man-in-the-middle attacks

No single control covers every layer, so defend each place an attacker can stand. In rough order of value for most organizations:

1. **Serve everything over HTTPS with HSTS.** Every site, API and admin panel, subdomains included, with the `Secure` attribute on session cookies. Preload the domain once you are sure. Our [security testing service](https://computese.com/services/security-testing/) checks TLS, HSTS and security headers on the sites you expose, along with DNSSEC and registrar lock on your domains.
2. **Move sign-in to phishing-resistant MFA.** Passkeys or FIDO2 security keys for everyone you can, administrators first, plus conditional access policies that check the device or location, which Microsoft recommends alongside MFA. Our [IT support](https://computese.com/services/it-support/) team sets up MFA and conditional access on Microsoft Entra ID or Google identity, with phishing-resistant sign-in where possible.
3. **Protect DNS and the domain.** Validate DNSSEC on your resolvers and sign your zones; [RFC 4033](https://www.rfc-editor.org/rfc/rfc4033.html) is clear that DNSSEC authenticates answers but does not encrypt them. For privacy and tamper protection on the path to the resolver, use encrypted DNS: DNS over TLS on port 853 ([RFC 7858](https://www.rfc-editor.org/rfc/rfc7858.html)) or DNS over HTTPS ([RFC 8484](https://www.rfc-editor.org/rfc/rfc8484.html)). Put MFA on every DNS and registrar account, as CISA required of federal agencies, and watch Certificate Transparency logs for certificates you did not order.
4. **Authenticate the Wi-Fi network, not just the user.** Use WPA3, which the [Wi-Fi Alliance](https://www.wi-fi.org/discover-wi-fi/security) says requires Protected Management Frames, and WPA3-Enterprise with 802.1X for staff. On a network with one shared password, anyone who knows it can run a convincing twin. With 802.1X, each device signs in with its own credentials and checks the authentication server's certificate; [Microsoft's EAP documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/network-access) warns that a client that skips that check may connect to a rogue network, and recommends not letting users approve untrusted servers. Wi-Fi Enhanced Open encrypts guest traffic but does not authenticate the network, so it does not stop an evil twin.
5. **Harden the switches.** On managed switches, enable DHCP snooping and [Dynamic ARP Inspection](https://www.juniper.net/documentation/us/en/software/junos/security-services/topics/topic-map/understanding-and-using-dai.html), which checks every ARP packet on an untrusted port against the DHCP snooping database and drops the ones that do not match. Disable LLMNR and NetBIOS name resolution by Group Policy where nothing needs them, and require SMB signing.
6. **Pin certificates only where it fits.** The [OWASP Pinning Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html) says there is almost no situation where pinning is worth it, because the risk of outages usually outweighs the benefit. Consider it only for a native mobile app talking to servers you control, with a pinset you can update safely; never for websites.
7. **Keep an inventory of trusted root certificates** on managed devices, so an interception certificate like Superfish's stands out.

And for everyone, at work and at home:

- **Never click through a certificate warning** on a site you use regularly. Close the tab and report it; on your own network, check for an evil twin or a compromised router.
- Check the address bar before you sign in, especially after following a link from an email or a message. A passkey that refuses to work on a page is a warning sign in itself.
- Forget open Wi-Fi networks you no longer use, so devices do not rejoin a look-alike automatically, and prefer mobile data or a [VPN](https://computese.com/how-to-set-up-a-vpn/) on networks you do not control. Our guides to [securing home Wi-Fi](https://computese.com/how-to-set-up-secure-home-wi-fi-network/) and the [home network](https://computese.com/how-to-secure-your-home-network/) cover the router side, and our [cyber security tips](https://computese.com/cyber-it-security/) cover the everyday habits.

## Signs of a man-in-the-middle attack, and what to do

Pure relaying is hard to see, but getting into the middle usually leaves marks.

| Sign                                                                              | What it may mean                               | What to do                                                                     |
| --------------------------------------------------------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------ |
| Certificate warning on a familiar site                                            | An interception certificate or a hijacked name | Do not continue; try from another network and report it to IT                  |
| A site you always reach over HTTPS loads over HTTP                                | TLS stripping on the current network           | Disconnect, and add HSTS if it is your site                                    |
| The router's IP address maps to an unfamiliar MAC address in `arp -a`             | ARP spoofing on the local segment              | Find the port, isolate the device, enable Dynamic ARP Inspection               |
| An open network named like a secured one, or a portal asking for work credentials | An evil twin                                   | Disconnect and forget the network; alert whoever runs the real one             |
| A new MFA method, inbox rule or unfamiliar sign-in after a phishing click         | AiTM session theft                             | Revoke all sessions, remove the added MFA method and rules, reset the password |
| Certificates in CT logs that nobody ordered                                       | DNS or registrar account takeover              | Audit DNS records, secure the accounts, have the certificate revoked           |

For a business, the last two rows are the urgent ones. Microsoft's 2023 case is the reminder: a password reset alone leaves the stolen session and the attacker's MFA method in place.

## Key terms
- **Man-in-the-middle (MITM) attack**: An attack in which someone positions themselves between two communicating parties and relays their traffic to read or alter it. Also called manipulator-, person- or adversary-in-the-middle, or an on-path attack.
- **Adversary-in-the-middle (AiTM) phishing**: Phishing through a proxy that relays the real sign-in page, so the attacker captures the password and the session cookie the service issues after multi-factor authentication.
- **ARP spoofing**: Sending forged Address Resolution Protocol replies so devices on a local network map another device's IP address, usually the router's, to the attacker's MAC address. Also called ARP cache poisoning.
- **DNS cache poisoning**: Getting forged answers into a DNS resolver's cache, so everyone who uses that resolver is sent to the attacker's address for a name.
- **Evil twin**: A rogue Wi-Fi access point that broadcasts the name of a legitimate network so devices connect to it and route their traffic through the attacker.
- **BGP hijacking**: Announcing internet address space that belongs to someone else, so routers that accept the announcement send traffic for those addresses to the wrong network.
- **TLS stripping**: Keeping a victim on plain HTTP by intercepting the redirect to HTTPS, while the attacker talks HTTPS to the real site. Also called SSL stripping or an HTTPS downgrade.
- **HSTS**: HTTP Strict Transport Security (RFC 6797): a response header that tells browsers to use only HTTPS for a site and to treat certificate errors as fatal. The preload list builds that policy into browsers.
- **Session cookie**: The token a site sets after you sign in. It proves on every later request that you already authenticated, so whoever holds it can act as you until it expires or is revoked.
- **Passkey**: A FIDO credential stored on a phone, computer or security key and unlocked like the device. It is bound to the site's domain name, so it produces nothing usable on a look-alike phishing site.

## Common questions

### Is an attack that monitors network communication without users knowing a man-in-the-middle attack?

In quiz questions that offer network tracing, man-in-the-middle, spear phishing and ransomware, the expected answer is man-in-the-middle. Strictly, pure listening is passive eavesdropping; a man-in-the-middle attack is the active form, where the attacker routes the traffic through their own system and can change it as well as read it.

### Does HTTPS prevent man-in-the-middle attacks?

It stops most of them, as long as the browser checks the certificate and nobody clicks through a warning. It does not help if the site can still be reached over HTTP without HSTS, if a rogue root certificate is installed on the device, if an attacker who controls your DNS obtains a valid certificate, or if you sign in on a look-alike phishing domain.

### Can multi-factor authentication stop a man-in-the-middle attack?

Only phishing-resistant MFA can. One-time codes, SMS and push approvals can be relayed through an adversary-in-the-middle proxy, which then keeps the session cookie. Passkeys and FIDO2 security keys bind the sign-in to the real domain, so a proxy on a different domain gets nothing it can use.

### Does a VPN protect against man-in-the-middle attacks?

A VPN encrypts traffic between your device and the VPN server, which protects you from ARP spoofing or an evil twin on untrusted Wi-Fi. It does not protect traffic beyond the VPN server, and it does nothing against adversary-in-the-middle phishing, because you still reach the phishing site through the tunnel.

### How can I tell if I am the target of a man-in-the-middle attack?

Watch for a certificate warning on a site you use every day, a familiar site suddenly loading over HTTP, the router's address mapping to an unfamiliar device in the ARP table, and unexpected requests to sign in again. In business accounts, a new MFA method, a new inbox rule or a sign-in from an unfamiliar place shortly after someone clicked a link points to AiTM phishing.

### What is the difference between man-in-the-middle and adversary-in-the-middle?

They name the same position. MITRE ATT&CK uses adversary-in-the-middle for all of these techniques, OWASP says manipulator-in-the-middle, and IETF documents describe on-path attackers. In phishing reports, AiTM usually means the proxy technique that relays a real sign-in page to steal session cookies.

## Sources
1. [Glossary: man-in-the-middle attack (MitM)](https://csrc.nist.gov/glossary/term/man_in_the_middle_attack), NIST Computer Security Resource Center
2. [Manipulator-in-the-middle attack](https://owasp.org/www-community/attacks/Manipulator-in-the-middle_attack), OWASP Foundation
3. [Adversary-in-the-Middle, Technique T1557](https://attack.mitre.org/techniques/T1557/), MITRE ATT&CK
4. [Adversary-in-the-Middle: ARP Cache Poisoning, T1557.002](https://attack.mitre.org/techniques/T1557/002/), MITRE ATT&CK
5. [Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay, T1557.001](https://attack.mitre.org/techniques/T1557/001/), MITRE ATT&CK
6. [Adversary-in-the-Middle: DHCP Spoofing, T1557.003](https://attack.mitre.org/techniques/T1557/003/), MITRE ATT&CK
7. [Adversary-in-the-Middle: Evil Twin, T1557.004](https://attack.mitre.org/techniques/T1557/004/), MITRE ATT&CK
8. [VU#800113: Multiple DNS implementations vulnerable to cache poisoning](https://www.kb.cert.org/vuls/id/800113), CERT Coordination Center
9. [Emergency Directive 19-01: Mitigate DNS Infrastructure Tampering](https://www.cisa.gov/news-events/directives/ed-19-01-mitigate-dns-infrastructure-tampering), CISA
10. [BGP leaks and cryptocurrencies](https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/), Cloudflare
11. [RFC 6811: BGP Prefix Origin Validation](https://www.rfc-editor.org/rfc/rfc6811.html), IETF
12. [HSTS Preload List Submission](https://hstspreload.org/), Chromium project (hstspreload.org)
13. [RFC 6797: HTTP Strict Transport Security (HSTS)](https://www.rfc-editor.org/rfc/rfc6797.html), IETF
14. [HTTPS by default](https://security.googleblog.com/2025/10/https-by-default.html), Google Security Blog
15. [Alice in Warningland: A Large-Scale Field Study of Browser Security Warning Effectiveness](https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/akhawe), USENIX Security Symposium (Akhawe, Felt, 2013)
16. [Lenovo Superfish Adware Vulnerable to HTTPS Spoofing](https://www.cisa.gov/news-events/alerts/2015/02/20/lenovo-superfish-adware-vulnerable-https-spoofing), CISA (US-CERT alert TA15-051A)
17. [Steal Web Session Cookie, Technique T1539](https://attack.mitre.org/techniques/T1539/), MITRE ATT&CK
18. [NIST SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html), NIST
19. [From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud](https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/), Microsoft Threat Intelligence
20. [Detecting and mitigating a multi-stage AiTM phishing and BEC campaign](https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/), Microsoft Threat Intelligence
21. [Implementing Phishing-Resistant MFA (fact sheet)](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf), CISA
22. [Passkeys](https://fidoalliance.org/passkeys/), FIDO Alliance
23. [RFC 4033: DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033.html), IETF
24. [RFC 7858: Specification for DNS over Transport Layer Security (TLS)](https://www.rfc-editor.org/rfc/rfc7858.html), IETF
25. [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484.html), IETF
26. [Extensible Authentication Protocol (EAP) for network access in Windows](https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/network-access), Microsoft Learn
27. [Wi-Fi security](https://www.wi-fi.org/discover-wi-fi/security), Wi-Fi Alliance
28. [Understanding and Using Dynamic ARP Inspection (DAI)](https://www.juniper.net/documentation/us/en/software/junos/security-services/topics/topic-map/understanding-and-using-dai.html), Juniper Networks
29. [Pinning Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html), OWASP Cheat Sheet Series