Why MFA Alone Will Not Stop Modern Phishing Attacks
You click a link, sign in, approve the MFA prompt, and move on with your day, completely unaware that someone else just stepped into your account at the same moment.
That scenario catches a lot of business owners off guard, especially those who assume multi-factor authentication is the finish line for cloud account security. But this is exactly how Adversary-in-the-Middle (AiTM) phishing attacks operate. Instead of stealing a password to use later, these attacks hijack an already-authenticated session in real time.
MFA still matters, and configuring it correctly remains a critical first step for any organization. The problem is that AiTM attacks target something MFA was never built to defend: the trusted session that exists after authentication is complete.
Phishing Has Moved Beyond Passwords
Phishing is still the most common entry point for account compromise, but the goal has shifted. Traditional phishing harvested usernames and passwords. Modern phishing goes after something far more useful, which is the authenticated session itself.
Security researchers have documented a clear move toward session and token theft, where attackers intercept the authentication process while it happens. Rather than reusing stolen credentials that MFA would normally block, they wait for the user to finish logging in, then steal the session token proving that login already occurred.
The technique has matured fast. Phishing-as-a-Service platforms now supply ready-made proxy toolkits that let even low-skilled attackers run AiTM campaigns against Microsoft 365 and Google Workspace.
How AiTM Attacks Actually Work
An AiTM phishing site is not a crude copy of a login page. It is a live reverse proxy. The attacker's infrastructure sits between the user and the real authentication service, so every keystroke, redirect, and server response passes through their system as it happens. From the user's side, nothing looks wrong. The branding is correct, the redirects work, and the MFA prompt functions normally. Usually the only clue is a slightly altered URL, easy to miss on a phone screen or when someone is rushing between meetings.
This is where common security assumptions break down. MFA protects the moment of authentication, not what comes after it. Once a user completes MFA, the service issues a session cookie that tells the application this person is already verified. From that point forward, no password or MFA prompt is required. The system simply trusts the token, and whoever holds the cookie holds the access.
AiTM attacks wait for that cookie to be issued, then take it. Microsoft has tracked a 146% rise in AiTM attacks over the past year as criminals increasingly focus on accounts that already have MFA enabled. Much of that growth is driven by PhaaS kits such as Evilginx, which let attackers run convincing reverse-proxy campaigns at scale against major cloud identity providers with very little setup.
Session tokens function as bearer credentials. Once the cookie is stolen, the attacker imports it into their own browser and resumes the session instantly. They never log in. They pick up exactly where the legitimate user left off, inside a fully trusted and already-verified session.
What Happens After a Session Is Stolen
The aftermath tends to be quiet, and that is precisely what makes it dangerous. The attacker is operating inside a legitimate session, so there are no failed MFA attempts, no unusual login alerts, and nothing in standard sign-in logs to raise a flag.
Research from Proofpoint shows that attackers who gain access this way commonly create hidden inbox rules to reroute mail, register additional MFA methods to lock in long-term access, monitor email threads for financial conversations, and use the trusted account to phish colleagues and finance staff. Those follow-on actions explain why AiTM attacks are so often discovered late, after financial fraud, data exposure, or broader network compromise has already started.
Reducing Your Exposure
Strong authentication remains the baseline, but reducing AiTM risk requires controls that reach past the login event.
Start with phishing-resistant MFA. Methods like FIDO2 hardware keys and passkeys bind authentication to a specific device and the legitimate domain, so a proxy in the middle cannot relay them. If the URL is not the real one, the process fails. The Canadian Centre for Cyber Security reviewed more than 100 AiTM campaigns targeting Microsoft Entra ID accounts and found that phishing-resistant MFA consistently blocked session theft where push notifications and one-time passcodes did not.
Next, tighten Conditional Access and post-login monitoring. Detecting AiTM compromise means watching what happens after sign-in, including new MFA method registrations, inbox rules created outside business hours, access from unfamiliar locations, and unusual data movement. Authentication logs on their own will not surface the problem.
Finally, train your team on URL awareness. Employees who understand that a working MFA prompt on an unfamiliar page is still a risk are far more likely to pause, verify the address, and report it. A short walkthrough of what AiTM lures look like in Microsoft 365 can meaningfully reduce exposure.
Stop Protecting Just the Login Screen
MFA is a baseline, not a finish line. The businesses that genuinely reduce AiTM risk are the ones that understand how sessions, tokens, and identity trust actually work, then build controls around each layer instead of the login screen alone.
Cyclone 365 works with organizations across the Gulf Coast to harden identity security, deploy phishing-resistant authentication, and put monitoring in place that catches suspicious session activity early. If you are unsure where your gaps are, contact us to schedule a consultation and find out before an incident does it for you. Click to Call or Email us today!