What is a man-in-the-middle attack?
A man-in-the-middle (MITM) attack is when an attacker secretly gets between two parties who think they are talking directly. Examples are your laptop and your bank, or a user and Microsoft 365. From there the attacker can read, steal or change what passes between them.
Today the most damaging version targets logins. The attacker passes on a real sign-in page and steals the session after the victim completes MFA. (MFA is the second login step, such as a code on your phone.)
You will also see the term adversary-in-the-middle (AiTM). It means the same thing and is now common in security research.
How a man-in-the-middle attack works
Every MITM attack follows the same three steps:
- Get in the path. The attacker gets traffic to flow through a device or server they control. Examples are a fake Wi-Fi hotspot, a poisoned network table or a lookalike website.
- Defeat the encryption. Most traffic is scrambled by HTTPS (TLS), the padlock in your browser. So the attacker tries to weaken it or trick the user into accepting a fake certificate. Or they simply get the user to log in to the attacker's own site, which has a valid certificate of its own.
- Use what they captured. That can be passwords, session cookies (the token that keeps you logged in) or payment details. It can also be the chance to change a message on its way, such as the bank details in an invoice.
HTTPS is now used almost everywhere. That has made simple snooping on coffee shop Wi-Fi much less useful than it was ten years ago. So attackers have moved to phishing pages that sit in the middle of a real login. (Phishing is a fake message that tricks you into clicking or sharing a password.)
Types of man-in-the-middle attack
There are six main types. Some need the attacker to be on the same network as you, such as public Wi-Fi. Others, like AiTM phishing, work from anywhere on the internet.
| Type | How it works | Where you meet it |
|---|---|---|
| Evil twin Wi-Fi | A rogue access point uses a trusted network name so devices connect to it. It may show a fake login portal. | Airports, hotels, cafes, conferences |
| ARP spoofing | On a local network, the attacker sends forged ARP replies so traffic meant for the router goes to their machine. | Shared office or guest networks |
| DNS spoofing | A poisoned DNS cache or hijacked router setting makes a real domain name point to the attacker's server. | Home routers, compromised networks |
| SSL stripping | The attacker intercepts the first plain HTTP request and keeps the victim on HTTP while talking HTTPS to the real site. | Sites without HSTS |
| Session hijacking | The attacker steals a session cookie or token and replays it, so they are logged in without needing the password or MFA. | Web apps, SaaS, cloud consoles |
| AiTM phishing | A reverse proxy relays the real login page. The victim enters their password and MFA code, and the attacker keeps the session cookie. | Microsoft 365, Google Workspace, banking |
Adversary-in-the-middle phishing deserves extra attention because it defeats the MFA most businesses rely on. Here is how it works. The victim clicks an email link and sees what looks like their normal sign-in page. It is the real page, passed through the attacker's server. They type their password and approve the MFA prompt. The real service issues a session cookie, and the attacker's server copies it. The attacker now has a logged-in session. They often add inbox rules or register their own MFA device to stay in.
Microsoft has published research on large AiTM campaigns against Microsoft 365 users. Ready-made phishing kits make the attack cheap to run.
This is how many business email compromise cases start, where criminals take over a mailbox to redirect payments. For the wider picture, see our guide to social engineering attacks.
Signs of a man-in-the-middle attack
A well-run MITM attack often shows the user nothing at all. So spotting it relies on system logs as much as on people. Signs worth acting on:
- A browser certificate warning on a site that normally loads cleanly
- A site that usually uses
https://loading over plainhttp:// - A login page reached from an email link whose address is close to, but not exactly, the real domain
- Two Wi-Fi networks with the same name, or an open hotspot that asks for your email password
- In sign-in logs: a new login from an unfamiliar IP address or country minutes after the user's real login
- New inbox forwarding rules, new MFA methods or new app permissions (OAuth consents) that the user did not set up
How to prevent man-in-the-middle attacks
No single control covers every type. Use this checklist and give each line to an owner.
| Defense | What it stops | Owner |
|---|---|---|
| HTTPS everywhere, with HSTS and HSTS preload | SSL stripping, passive sniffing | Web team |
| Never click through certificate warnings | Interception with fake certificates | Everyone |
| Company VPN or phone hotspot on public Wi-Fi | Evil twin hotspots, local sniffing | Staff and IT |
| Phishing-resistant MFA: passkeys or FIDO2 security keys | AiTM phishing | IT |
| Conditional access, compliant devices only, shorter session lifetimes | Session hijacking and token replay | IT |
| Certificate pinning in mobile apps | Interception through rogue or user-installed certificates | App developers |
| Dynamic ARP inspection, DHCP snooping, 802.1X | ARP spoofing on office networks | Network team |
| Secured router admin, DNSSEC or encrypted DNS | DNS spoofing | IT |
Why passkeys matter most. A passkey or FIDO2 security key is tied to the real website's address. When a user lands on a lookalike site, the browser simply will not hand over the login. So there is nothing to pass on. Codes sent by text or typed from an authenticator app can be passed on. And a tricked user can simply tap "approve" on a phone prompt.
Certificate pinning lets a mobile app accept only your own certificate or key. That blocks snooping even on a phone with an extra trusted certificate installed. It needs care. Plan backup pins and a way to replace them, or a certificate change can break the app.
What to do if you suspect a MITM attack
- Disconnect from the suspicious network.
- From a trusted device and network, change the password for any account you used.
- Sign out all active sessions for that account. A password change alone may not end a stolen session.
- Check MFA methods, inbox rules and connected apps, and remove anything unfamiliar.
- Report it to IT or your security provider so they can check logs for other affected users.
Has an attacker already used a stolen session to send email or change payment details? Then treat it as an incident. Our incident response team can help contain it.
How NextGarrison helps
We test for MITM gaps the way attackers find them. That includes Wi-Fi and internal network penetration tests (expert attempts to break in). It also includes web and mobile app tests that check HSTS and certificate pinning. Our practice phishing campaigns show whether your MFA would survive an AiTM kit. Our 24/7 SOC, a team that watches for attacks around the clock, checks sign-in logs for stolen sessions and impossible travel. See our services.
Need a hand with this?
Talk to a senior consultant. We reply within one business day with clear next steps and a scoped quote.
Written by
NextGarrison Security TeamPenetration testers, SOC analysts and compliance consultants
Our consultants test applications and networks, run 24/7 security monitoring and prepare companies for SOC 2, ISO 27001 and PCI DSS assessments. We write about what we see in real engagements, in plain English.