How Phishing Sites Steal Your Active Login
You click a link, sign in, approve an MFA prompt, and move on with your day, completely unaware that someone else has just accessed your account at the same time.
This scenario catches many organizations off guard, especially those that rely on multi-factor authentication (MFA) to secure cloud accounts. It is exactly how Adversary-in-the-Middle (AiTM) phishing attacks operate.
Instead of stealing credentials for later use, these attacks hijack an authenticated session in real time.
MFA remains a critical control, and implementing it properly is still essential. However, AiTM attacks exploit a gap MFA was never designed to address: the trusted session created after authentication.
Phishing Has Evolved Beyond Passwords
Phishing is still the most common entry point for account compromise, but its objective has shifted.
Traditional attacks focused on capturing usernames and passwords. Modern campaigns target something far more valuable: the authenticated session itself.
Security research shows a clear rise in session and token theft, where attackers intercept authentication as it happens. Rather than attempting to reuse credentials—which MFA often blocks—they wait for the user to successfully log in, then capture the session token that proves authentication has already occurred.
This approach has rapidly matured. Phishing-as-a-Service (PhaaS) platforms now offer ready-made proxy tools, enabling even low-skilled attackers to run AiTM campaigns against services like Microsoft 365 and Google Workspace.
How AiTM Attacks Work
A login page that is not really fake
AiTM phishing sites are not simple lookalikes—they function as live reverse proxies.
The attacker positions their infrastructure between the user and the legitimate authentication service, relaying every keystroke, redirect, and server response in real time. To the user, everything appears normal.
The page uses correct branding, valid redirects, and even presents a working MFA prompt. Often, the only warning sign is a slightly altered URL—easy to miss on mobile devices or under time pressure.
Why MFA does not stop it
This is where many assumptions about security break down.
MFA protects the login process, not what follows. After successful authentication, the service issues a session cookie that signals the user is verified. From that point forward, no additional password or MFA challenge is required. The system trusts the session.
AiTM attackers simply wait for that cookie—and then steal it.
Microsoft reported a 146 percent increase in AiTM attacks over the past year, driven in part by PhaaS platforms like Evilginx that make large-scale campaigns easy to deploy.
The role of session cookies
Session tokens act as bearer credentials: whoever holds them gains access.
Once stolen, the attacker imports the cookie into their own browser and resumes the session immediately. This is known as a session replay attack. The attacker does not log in—they continue from an already authenticated, trusted session.
What Happens After Session Hijacking
Session hijacking is different. The attacker’s goal is to steal the proof that you’re already logged in, then reuse it, often without triggering another sign-in challenge. AiTM attacks are often quiet, which makes them particularly dangerous.
Because the attacker operates within a legitimate session, there are no failed logins, no MFA alerts, and little indication of compromise in standard authentication logs.
Common post-compromise actions include creating hidden inbox rules, registering new MFA methods to maintain access, monitoring email conversations for financial activity, and launching phishing attacks from the compromised account.
These actions often go undetected until financial loss, data exposure, or broader compromise has already occurred.
Reducing Your Exposure
MFA is necessary, but it is only the starting point. Mitigating AiTM risk requires controls that extend beyond authentication.
Adopt phishing-resistant MFA: Technologies like FIDO2 security keys and passkeys bind authentication to the device and legitimate domain, preventing proxy-based interception.
Strengthen conditional access: Risk-based policies evaluate signals such as device health, location, and behavior, allowing detection of suspicious activity even when sessions appear valid.
Monitor post-login activity: Look for anomalies such as new MFA registrations, unusual inbox rules, unfamiliar access locations, or abnormal data access patterns.
Train users on URL awareness: Even a fully functional login page with MFA can be malicious. Users should be trained to verify URLs before proceeding.
Move Beyond Protecting the Login
MFA is a baseline, not the finish line. Organizations that effectively reduce AiTM risk understand how sessions, tokens, and identity trust function—and secure each layer accordingly.
If you want to assess your identity security posture, now is the time to identify gaps before an incident does it for you.