You approve an MFA prompt and get on with your day — completely unaware that someone else just logged into your account at the same moment. No password was stolen. No brute-force attack triggered any alerts. The attacker simply waited for you to finish authenticating, then took the session that proved you already had.
This is how AiTM phishing attacks work. Adversary-in-the-Middle attacks don’t target the login step — they target what happens after it. Understanding the mechanics is the first step toward building defenses that actually close the gap, because standard MFA alone was never designed to stop this.
AiTM Phishing Attacks: Why Standard MFA Has a Blind Spot
MFA remains one of the most effective security upgrades a business can make. It blocks the overwhelming majority of credential-based attacks and dramatically raises the cost of basic account takeover. The problem is that AiTM phishing attacks don’t try to beat MFA — they go around it entirely.
The shift is documented and significant. Microsoft has tracked a 146% rise in AiTM attacks over the past year, driven in large part by Phishing-as-a-Service platforms like Evilginx that allow even low-skilled attackers to run reverse-proxy campaigns at scale against Microsoft 365 and Google Workspace accounts.
MFA protects the moment of authentication. It does not protect what comes after. Once a user successfully completes login, the service issues a session cookie — the token that signals the user is already verified. AiTM phishing attacks simply wait for that cookie to be issued, then steal it.
How AiTM Phishing Attacks Actually Work
The mechanics are straightforward once you understand what’s being targeted. An AiTM phishing site is not a basic replica of a login page — it’s a live reverse proxy. The attacker’s infrastructure sits between the user and the real authentication service. Every request, redirect, and server response flows through the attacker’s system in real time.
The Fake Login Page That Isn’t Fake
From the user’s perspective, the login experience looks entirely normal. The page has correct branding, working redirects, and a functioning MFA prompt. The user enters their credentials, receives and approves an MFA challenge, and lands on the real service. In most cases, the only clue is a slightly altered URL — easy to miss on a mobile screen or when someone is under time pressure.
Meanwhile, the attacker’s proxy has captured everything: the session cookie that was issued the moment authentication completed. That cookie is the key. Whoever holds it can access the account — no password, no MFA challenge required.
Session Replay: Walking In Through the Back Door
Once the session cookie is captured in an AiTM phishing attack, the attacker imports it into their own browser. They are not logging in. They are resuming a session that the legitimate user just opened, inside a fully trusted, already-verified context. Proofpoint describes this as session replay — the attacker picks up exactly where the legitimate user left off.
There are no failed login attempts. No anomalous MFA requests. Nothing in standard sign-in logs that signals a problem. The session looks clean because it is clean — it was legitimately authenticated. The compromise happened after the fact.
What Attackers Do With the Access
The aftermath of AiTM phishing attacks tends to be quiet, which is precisely what makes them dangerous. Research shows that attackers operating inside a compromised session commonly create hidden inbox rules to redirect mail, register additional MFA methods to establish persistent access, monitor email threads for financial conversations, and use the trusted account to launch follow-on phishing against internal colleagues or finance teams.
These follow-on actions are why AiTM attacks are frequently discovered late — after financial fraud, data exposure, or wider network compromise has already occurred.
3 Controls That Actually Stop AiTM Phishing Attacks
Reducing AiTM risk requires defenses that go beyond the login event itself. These three controls address the attack at different points in the chain.
1. Adopt Phishing-Resistant Authentication
Standard MFA methods — push notifications, one-time passcodes, SMS codes — share a common weakness: a proxy in the middle can relay them in real time. Phishing-resistant methods like FIDO2 hardware keys and passkeys eliminate that weakness by binding authentication to the specific device and the legitimate domain. If the URL isn’t the real one, the process fails. A proxy cannot relay what it can’t capture.
The Canadian Centre for Cyber Security analyzed over 100 AiTM campaigns targeting Microsoft Entra ID accounts and found that phishing-resistant MFA consistently blocked session theft where standard methods — including push notifications and one-time passcodes — did not.
2. Tighten Session and Conditional Access Policies
Shorter session lifetimes for high-risk applications — email, financial tools, admin consoles — shrink the window an attacker has to use a stolen session cookie before it expires. Re-authentication requirements for sensitive actions add another layer of friction. Conditional Access policies that flag suspicious sign-in patterns, new MFA method registrations, and access from unfamiliar locations can catch AiTM compromise in progress when authentication controls alone don’t stop it first.
3. Train Users on What AiTM Lures Look Like
Employees who understand that a working MFA prompt on an unfamiliar-looking page still represents a risk are better positioned to pause and check the URL before completing authentication. A brief team walkthrough of what AiTM lures look like in Microsoft 365 contexts — particularly the slightly-off domain names that are the most reliable signal — can meaningfully reduce exposure. Awareness doesn’t replace technical controls, but it adds a human checkpoint that catches what filters miss.
Stop Protecting Just the Login Screen
AiTM phishing attacks are a reminder that perimeter thinking about authentication has limits. The login screen is protected. What happens after it is where the gap lives. Phishing-resistant credentials, tighter session policies, and behavioral monitoring together close that gap in a way that securing the login prompt alone cannot.
If you’d like help reviewing your authentication stack and identity controls for your Southeast Texas team, our endpoint protection and cybersecurity services include identity and access control reviews — connect with our team to get your cyber shield assessment started.
Frequently Asked Questions: AiTM Phishing Attacks
What makes AiTM phishing attacks different from traditional phishing? Traditional phishing steals passwords for later use. AiTM phishing attacks steal the session cookie that’s issued after a successful login — meaning MFA has already been completed and the attacker doesn’t need credentials at all. They replay your already-authenticated session from a different device, accessing your account as if they were you.
Does enabling MFA protect against AiTM phishing attacks? Standard MFA — push notifications, SMS codes, one-time passcodes — does not stop AiTM attacks because the proxy relays the MFA challenge in real time and steals the session token after authentication completes. Phishing-resistant MFA methods like FIDO2 hardware keys and passkeys do stop them, because the credential is cryptographically bound to the legitimate domain and cannot be relayed by a proxy.
How do I know if my account has been compromised by an AiTM attack? Standard sign-in logs typically won’t surface it — the session looks legitimate because it was legitimately authenticated. The signals to watch for are new inbox rules created outside business hours, new MFA methods registered without a helpdesk request, access from unfamiliar locations or impossible travel patterns, and unusual data access or email forwarding activity. Behavioral anomaly detection catches what authentication logs miss.
Are small businesses in Southeast Texas realistic targets for AiTM phishing attacks? Yes. Phishing-as-a-Service platforms have made AiTM campaigns accessible to low-skilled attackers targeting organizations at scale. Small businesses running Microsoft 365 or Google Workspace are viable targets — and in many cases more attractive, because their authentication and session controls are less hardened than enterprise environments. The defenses are not enterprise-only, and the risk is not enterprise-only either.
What’s the fastest improvement a business can make to reduce AiTM risk? Tightening session lifetime policies on high-risk applications is often the fastest change — it’s a configuration adjustment that doesn’t require new tools. For accounts handling sensitive data or admin access, requiring re-authentication after a defined idle period significantly shrinks the window a stolen session cookie remains usable. Moving toward phishing-resistant MFA for those same high-risk accounts is the most durable fix against AiTM phishing attacks.
Photo credit: Pixabay
