AiTM Phishing: Session Hijacking and MFA Bypass Explained

AiTM (adversary-in-the-middle) phishing is why simply turning on MFA no longer lets you sleep soundly. Instead of stealing only the password, the attacker places a reverse proxy between the victim and the real login page, lets authentication complete for real (second factor included), and steals the session cookie the identity provider issues. With that cookie the attacker walks into the account without a password and without ever passing MFA again. It matters now because it is the technique driving enterprise account takeovers.

This article explains exactly what AiTM phishing is, how it differs from the classic network man-in-the-middle attack, how the session-cookie theft works step by step, why OTP or push-based MFA does not protect against it, and which defenses actually work. We close with detection, response, and a FAQ so you can review your own exposure.

Key takeaways

• AiTM is reverse-proxy phishing (for example, Evilginx): the attacker relays traffic in real time between the victim and the legitimate login.
• The victim authenticates for real, so MFA "passes"; the real target is the post-authentication session cookie.
• With the stolen cookie, the attacker replays it in their own browser and gets in without a password or second factor.
• Traditional MFA (OTP, SMS, push) does not protect; phishing-resistant credentials (FIDO2 and passkeys) do, because they are bound to the origin.
• Microsoft reported a 146% rise in AiTM attacks in 2024 and the growth of Phishing-as-a-Service (PhaaS) platforms.
• The key defenses are phishing-resistant MFA, token binding, conditional access, short sessions, and detection of anomalous reuse.

What AiTM phishing is

AiTM stands for adversary-in-the-middle. It is an evolution of phishing in which the attacker does not simply clone a login page visually to harvest credentials. Instead, they deploy a reverse proxy that sits between the victim and the service's real sign-in page (for example, the corporate identity portal) and relays traffic in both directions in real time.

The result is that the victim sees a page that looks authentic, with the real service's wording and behavior, because they are in fact interacting with the legitimate service through the attacker's proxy. The difference is the domain: the URL and TLS certificate the victim sees belong to the attacker, not to the real site. Everything the victim enters (username, password, and the second factor) travels to the real service. Authentication completes correctly. And that is the problem: the moment the identity provider issues the post-authentication session cookie, the proxy intercepts and exfiltrates it.

The role of tools like Evilginx

Tools of this kind, such as Evilginx, work precisely as that reverse-proxy phishing layer. They do not fake a static page; they forward requests to the legitimate server and capture the tokens and cookies exchanged during the session. This explains why AiTM campaigns are so convincing: the victim's experience is almost identical to a normal login (the domain in the URL is usually the only tell), including the MFA prompt appearing on their phone.

The rise of Phishing-as-a-Service (PhaaS) platforms has lowered the barrier to entry. An attacker no longer needs to build their own reverse-proxy infrastructure: they rent it. That has industrialized the technique and widened the pool of potential victims.

How it differs from the classic man-in-the-middle

It is easy to confuse AiTM with the classic network man-in-the-middle attack, but they are not the same. In a traditional man-in-the-middle, the attacker interposes at the network layer (for example, on a compromised Wi-Fi or via ARP poisoning) to intercept or manipulate traffic between two parties who believe they are communicating directly. The goal is usually to eavesdrop on or alter data in transit.

In AiTM the vector is different. The attacker does not compromise your network: they lure you through social engineering to a phishing link pointing at their proxy. And the goal is not generic either: it is specifically the session cookie that proves you have already authenticated. That is why this is an identity-focused attack, not a network one. Understanding this difference is critical, because network defenses (VPN, TLS encryption) do not stop an AiTM attack: TLS works perfectly between the victim and the proxy, and between the proxy and the real service.

How the session hijacking works step by step

Let us walk through the full flow to understand why MFA "passes" and yet the account still falls.

1. The lure and the link

It all starts with a phishing email, message, or ad that leads the victim to a URL controlled by the attacker. That URL is the gateway to the reverse proxy. It can arrive through the same channels as any of the other types of phishing we already know, and it is often combined with urgent pretexts or techniques like ClickFix with a fake CAPTCHA to reduce suspicion.

2. The real-time relay

When the victim clicks, the proxy serves the real login page by forwarding the request to the legitimate service. The victim enters their credentials. The proxy relays them. The service validates them and requests the second factor.

3. MFA completes for real

The victim receives their OTP, SMS, or push notification and approves the authentication, because to them it is a legitimate login. The second factor also travels through the proxy to the real service. MFA is satisfied. This is the point that baffles many teams: there is no flaw in MFA, the attacker has simply turned the victim into the operator who solves it for them.

4. Capturing the session cookie

Once full authentication is validated, the identity provider issues the post-authentication session cookie, the token that tells the service "this person has already proven who they are, let them through". The proxy intercepts and exfiltrates that cookie.

5. Replay and account takeover

The attacker imports the stolen cookie into their own browser and replays the session. To the service, that cookie is valid, so it grants access to the authenticated account without asking again for a password or second factor. The account takeover is complete. From there the attacker can read email, exfiltrate data, create forwarding rules, or pivot to other accounts.

Why traditional MFA does not protect against AiTM

This is the uncomfortable but necessary message: MFA based on OTP, SMS, or push does not protect against AiTM. The reason is simple. All those factors are secrets or approvals the victim enters or grants, and can therefore be relayed through the proxy. The attacker does not need to know your OTP in advance; it is enough that you enter it into their proxy at the right moment.

The same holds for push notifications. In fact, AiTM shares ground with other second-factor abuse techniques, such as MFA fatigue or push bombing, where the attacker bombards the victim with approvals until they give in. In AiTM you do not even need to wear anyone down: the victim approves because they believe it is their own login.

That is why, although MFA remains essential against password reuse and credential stuffing, it must not be considered a complete defense against modern phishing.

The defenses that actually work

The good news is that effective countermeasures exist, and the main one attacks the root of the problem.

Phishing-resistant MFA (FIDO2 and passkeys)

Phishing-resistant credentials, based on FIDO2 and WebAuthn, break the AiTM attack at its critical point. The key is that these credentials are cryptographically bound to the origin (the service's real domain). When the browser performs authentication, it verifies the origin and signs a challenge tied to that domain. If the victim is on the attacker's proxy domain, and not the real one, the signature does not match and authentication does not complete. The proxy cannot relay that credential because it cannot spoof the origin.

This is what makes passkeys the strongest defense available. To go deeper, we have guides on what a passkey is, on FIDO2, passkeys, and WebAuthn, and a specific one on phishing-resistant MFA that explains why a proxy cannot relay it.

Token binding and device-bound sessions

Token binding and device-bound sessions attack the replay phase. The idea is to stop the session cookie from being a portable token that works in any browser. If the session is cryptographically bound to the device or client that originated it, a cookie stolen and replayed from the attacker's browser stops being valid, because it does not come from the same device.

Conditional access

Conditional access policies add context to the authorization decision. They can require managed and compliant devices, restrict access by location or network, or force reauthentication on risk signals. A well-designed conditional access setup can block a replay coming from an unknown device or an unexpected geography.

Short session lifetime and revocation

Reducing session lifetime and having agile revocation mechanisms limits the attacker's window of opportunity. The sooner the stolen cookie expires and the faster you can revoke active sessions on suspicion, the smaller the damage. Revocation must be a real, rehearsed button, not a theoretical checkbox.

Detection and response

No defense is infallible, so detecting anomalous session reuse is essential. The most useful signals are the classic ones from identity risk analysis: impossible travel (the same session active in two incompatible geographies in a short time), the appearance of a new or unknown device, sudden changes in IP address or user agent, and the creation of email forwarding rules right after a login.

These capabilities fit squarely into an identity threat detection and response strategy. If your organization has not yet formalized that layer, it is worth understanding what ITDR is and how it integrates with the rest of your security telemetry.

The human component

It is worth remembering that many account-takeover campaigns combine AiTM with targeted social engineering. Groups clustered under the Scattered Spider umbrella have shown how effective it is to attack the help desk and people to obtain initial access or factor resets. Phishing-resistant technology reduces the surface, but training and identity verification processes in support remain decisive.

How to review your exposure

A practical exercise is to ask: if an employee entered their credentials and second factor into an AiTM proxy right now, what would stop it? If the answer is "nothing until someone notices strange activity", the organization depends entirely on reactive detection. The goal is to move that response toward prevention: origin-bound credentials, device-bound sessions, and conditional access that does not blindly trust a cookie.

Auditing this realistically requires simulating the attack, not just reviewing the configuration on paper. A controlled phishing campaign that includes an AiTM proxy reveals which users take the bait, which factors resist, and which sessions can be replayed. It is the difference between assuming you are protected and proving it.

Frequently asked questions

Is MFA useful at all if AiTM bypasses it?

Yes, it is still necessary. Traditional MFA stops password reuse, credential stuffing, and basic phishing. What it does not do is protect against AiTM, because the attacker relays the second factor in real time. The conclusion is not to disable MFA, but to migrate to phishing-resistant MFA based on FIDO2 and passkeys.

Why do passkeys resist AiTM?

Because they are cryptographically bound to the origin. The browser only completes authentication if the domain matches the one where the credential was registered. Since the attacker's proxy uses a different domain, the signature is not valid and cannot be relayed. The proxy cannot spoof the origin, so the attack breaks at its critical point.

How does AiTM differ from a network man-in-the-middle?

The classic man-in-the-middle interposes at the network layer to eavesdrop on or alter traffic. AiTM does not compromise the network: it uses a reverse-proxy phishing page the victim reaches through social engineering, and its specific goal is to steal the post-authentication session cookie to replay it. TLS does not stop it, because it works correctly on both legs.

How do I detect that a session was stolen by AiTM?

By looking for anomalous session reuse: impossible travel, new or unknown devices, unexpected IP or user-agent changes, and suspicious actions right after login, such as creating email forwarding rules. These signals are the core of an ITDR capability.

Is AiTM the same as MFA fatigue?

No, although both abuse the second factor. In MFA fatigue or push bombing the attacker bombards the victim with notifications until they approve one by mistake. In AiTM the victim approves because they believe they are on their legitimate login, and the focus is not the approval but the capture and replay of the session cookie.

What should I implement first?

Phishing-resistant MFA (FIDO2 and passkeys) for privileged and higher-risk accounts, together with conditional access requiring managed devices. After that, short sessions, token binding, and detection of anomalous reuse. That combination attacks both the capture phase and the replay phase at once.

Related resources

• Phishing-resistant MFA
• What is a man-in-the-middle attack
• What is a passkey
• FIDO2, passkeys, and WebAuthn
• Types of phishing
• MFA fatigue and push bombing
• ClickFix and fake CAPTCHA
• What is ITDR
• Scattered Spider and help-desk social engineering

Test your resistance to AiTM phishing

Secra is an offensive cybersecurity company with its own vulnerability research program. We have published real CVEs, such as CVE-2025-40652 in CoverManager and CVE-2023-3512 in Setelsa ConacWin CB, both in the NVD and INCIBE-CERT. We apply that same offensive mindset to auditing your real exposure to AiTM: controlled reverse-proxy phishing campaigns, review of your MFA and conditional access, and validation of whether a stolen session cookie could be replayed in your environment.

If you want to know what would really happen if your employees fell for an AiTM proxy, get in touch with us and we will help you check it before an attacker does.