Cybersecurity
Adversary-in-the-Middle Attacks: How Hackers Hijack Sessions After You Log In
MFA protects the login prompt, but AiTM phishing attacks steal the session that comes after it. Here is how reverse-proxy phishing kits intercept authenticated sessions in real time, why standard MFA cannot stop them, and which layered controls actually reduce exposure.
You click a link, sign in, approve the MFA prompt, and get on with your day. Completely unaware that someone else just logged into your account at the same moment.
That scenario surprises many businesses, particularly those that rely on multi-factor authentication (MFA) to protect cloud accounts. But this is exactly how Adversary-in-the-Middle (AiTM) phishing attacks work.
Rather than stealing passwords for later use, these attacks silently hijack an already-authenticated session in real time.
MFA remains a core control, and getting it implemented correctly is still a critical first step for any business.
But AiTM attacks exploit something MFA was never designed to protect: the trusted session that exists after authentication has already completed.
Phishing Has Moved Beyond Passwords
Phishing remains the most common starting point for account compromise, but the objective has changed.
Traditional phishing collected usernames and passwords. Modern phishing is after something more immediately useful: the authenticated session itself.
Security researchers have documented a significant shift toward session and token theft, where attackers intercept the authentication process as it happens.
Rather than reusing stolen credentials, which MFA typically blocks, they wait until the user successfully completes login, then steal the session token that proves it already occurred.
The technique has matured quickly. Phishing-as-a-Service (PhaaS) platforms now supply ready-made proxy toolkits that let even low-skilled attackers run AiTM campaigns targeting Microsoft 365 and Google Workspace.
How AiTM Attacks Actually Work
The Fake Login Page That Isn't Fake
An AiTM phishing site is not a basic replica of a login page. It is a live reverse proxy.
The attacker's infrastructure sits between the user and the real authentication service. Every keystroke, redirect, and server response flows through the attacker's system in real time. From the user's perspective, nothing looks wrong.
The page behaves exactly like the real service, with correct branding, working redirects, and a functioning MFA prompt. In most cases, the only clue is a slightly altered URL that goes unnoticed on a mobile screen or when someone is under time pressure.
Why MFA Doesn't Stop It
This is where many security assumptions fall apart.
MFA protects the moment of authentication, not what comes after it.
Once a user successfully completes MFA, the service issues a session cookie. What this means is that the cookie signals to the application that the user is already verified. From that point, no password or MFA prompt is required. The system trusts the token. Whoever holds the cookie holds the access.
AiTM attacks simply wait for that cookie to be issued then steal it.
In its 2024 Digital Defense Report, Microsoft reported a 146% rise in AiTM phishing attacks over the prior year, as cybercriminals increasingly shift focus to accounts already protected by MFA.
Much of this increase comes from ready-made tooling. Open-source reverse-proxy frameworks such as Evilginx, originally built for penetration testers, and commercial phishing-as-a-service kits such as EvilProxy let even low-skilled attackers run convincing campaigns against major cloud identity providers with minimal setup.
Session Cookies
Session tokens act as bearer credentials. So, whoever possesses the token can access the account, with no password or MFA challenge required.
Once the cookie is stolen, the attacker imports it into their own browser and immediately resumes the session.
This is a session replay attack. The attacker does not log in. They pick up where the legitimate user left off, inside a fully trusted, already-verified session.
What Happens After a Session Is Stolen
The aftermath of an AiTM attack tends to be quiet, which is precisely what makes it dangerous.
The attacker is operating inside a legitimate, authenticated session. There are no failed MFA attempts, and the sign-in itself looks successful. The warning signs, such as a sign-in from the proxy's unfamiliar IP address or a session cookie suddenly used from a different location, are easy to miss unless someone, or a detection tool, is looking for them.
Research from Proofpoint and Microsoft shows that attackers who gain access through session hijacking register their own MFA method to lock in persistent access, create hidden inbox rules to redirect or hide mail, monitor email threads for financial conversations, and use the trusted account to launch phishing or payment fraud against colleagues, customers, and finance teams.
These follow-on actions are a key reason AiTM attacks are frequently uncovered late, after financial fraud, data exposure, or wider network compromise has already begun.
Reducing Your Exposure
MFA is still essential. Building strong authentication practices remains the starting baseline. But reducing AiTM risk requires controls that extend beyond the login event itself.
Adopt Phishing-Resistant MFA
Methods like FIDO2 hardware keys and passkeys bind authentication to the specific device and the legitimate domain. A proxy in the middle cannot relay them: the process fails if the URL is not the real one.
The Canadian Centre for Cyber Security drew on more than 100 AiTM campaigns it detected against Microsoft Entra ID accounts in its guidance, Defending against adversary-in-the-middle threats with phishing-resistant multi-factor authentication. Its conclusion: standard methods such as push notifications and one-time passcodes can be relayed through a proxy, so phishing-resistant MFA should be the default.
Tighten Conditional Access Policies
In Microsoft 365, Conditional Access (a Microsoft Entra ID P1 feature included in Business Premium) can stop many AiTM sign-ins outright. A policy that requires a compliant or Microsoft Entra hybrid joined device blocks the attacker's proxy, because the proxy is not one of your managed devices. Authentication strength policies can require phishing-resistant methods for administrators and other high-value users. A policy on the "register security information" user action can limit where and how new MFA methods are added, which blocks a common persistence step. With Entra ID P2, sign-in risk and user risk policies can respond to detections such as Attacker in the Middle and Anomalous Token, and Token Protection can bind sign-in sessions to the device for supported Windows apps. Microsoft's guidance on protecting tokens in Microsoft Entra covers these layers in detail.
Monitor for Activity After Login
Detecting AiTM compromise also means watching for activity after login: new MFA method registrations, inbox rules created outside business hours, access from unfamiliar locations, or unusual data activity. Successful sign-ins alone will not surface the problem.
Train Users on URL Awareness
Employees who understand that a working MFA prompt on an unfamiliar-looking page still represents a risk are better positioned to pause, check the URL, and report before a session is compromised. A brief team walkthrough of what AiTM lures look like in Microsoft 365 contexts can meaningfully reduce exposure.
Stop Protecting Just the Login Screen
MFA is a baseline, not a finish line. The businesses that reduce AiTM risk are the ones that understand how sessions, tokens, and identity trust actually work. And they build controls around each layer, not just the login screen.
Want to review your identity security controls? Contact us or schedule a consultation to identify the gaps that matter most before an incident does it for you.
Frequently Asked Questions
What is an Adversary-in-the-Middle (AiTM) attack?
An AiTM attack is a phishing technique where attackers use a proxy to intercept login sessions in real time, allowing them to steal session cookies after authentication completes.
Can AiTM attacks bypass MFA?
Yes, but not by breaking MFA. AiTM attacks wait until MFA succeeds, then steal the authenticated session token so no further verification is required.
How can businesses reduce the risk of AiTM attacks?
Using phishing-resistant MFA, requiring managed devices through Conditional Access, restricting who can register new MFA methods, training users, and monitoring for unusual session behavior all help reduce exposure.