Adversary-in-the-Middle Attacks: How Phishing Sites Steal Your Active Login

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 exact same moment.

That scenario catches a lot of business owners in South Bend, Goshen, and Elkhart off guard, especially the ones who did everything right by rolling out multi-factor authentication years ago and assumed that box was checked for good. But this is exactly how Adversary-in-the-Middle (AiTM) phishing attacks work. Rather than stealing a password for later use, these attacks silently hijack an already-authenticated session in real time, while MFA is doing exactly what it was designed to do.

MFA remains a core control, and getting it implemented correctly is still a critical first step for any business we work with. But AiTM attacks exploit something MFA was never designed to protect: the trusted session that exists after authentication has already completed. We wrote this to walk through why phishing has moved beyond passwords, how AiTM attacks actually work, what happens after a session is stolen, and the specific controls that close this gap for businesses across Michiana.

Phishing has moved beyond passwords

Phishing remains the most common starting point for account compromise, but the objective behind it has changed. Traditional phishing collected usernames and passwords for later use. 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 platforms now supply ready-made proxy toolkits that let even low-skilled attackers run AiTM campaigns targeting Microsoft 365 and Google Workspace, the exact platforms most small businesses in our area run their entire operation on.

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’s a live reverse proxy. The attacker’s infrastructure sits between the user and the real authentication service, and 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 — which, if we’re honest, describes most of a normal workday.

Why MFA doesn’t stop it

This is where a lot of security assumptions fall apart, including ones we’ve heard from business owners who thought MFA closed the book on this issue entirely.

MFA protects the moment of authentication, not what comes after it. Once a user successfully completes MFA, the service issues a session cookie. That cookie signals to the application that the user is already verified. From that point forward, no password or MFA prompt is required again — the system trusts the token, and whoever holds the cookie holds the access.

AiTM attacks simply wait for that cookie to be issued, then steal it. Microsoft tracked a 146% rise in AiTM attacks over the past year, as cybercriminals increasingly shift focus toward accounts already protected by MFA rather than the ones that are easier but less valuable. Much of this increase is driven by Phishing-as-a-Service platforms like Evilginx that allow even low-skilled attackers to run convincing reverse-proxy campaigns at scale, targeting major cloud identity providers with minimal setup on their end.

Session cookies, explained plainly

Session tokens act as bearer credentials, meaning 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 called a session replay attack. The attacker doesn’t log in at all in the traditional sense. They pick up exactly where the legitimate user left off, inside a fully trusted, already-verified session — invisible to any control that only watches the login event itself.

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, no unusual login alerts, and nothing in standard sign-in logs to signal a problem — because, as far as the system is concerned, nothing unusual happened.

Research from Proofpoint shows that attackers who gain access through session hijacking commonly create hidden inbox rules to redirect mail, register additional MFA methods to lock in persistent access, monitor email threads for financial conversations, and use the trusted account to launch phishing campaigns against internal colleagues or finance teams.

These follow-on actions are a key reason AiTM attacks are frequently uncovered late, often after financial fraud, data exposure, or wider network compromise has already begun quietly running its course.

Reducing your exposure

MFA is still essential, and building strong authentication practices remains the starting baseline for every client we onboard. But reducing AiTM risk specifically 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 simply cannot relay them — the process fails outright if the URL isn’t the real one, no matter how convincing everything else looks.

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 MFA methods, including push notifications and one-time passcodes, did not.

Tighten Conditional Access policies

Detecting AiTM compromise typically means watching for activity after login: new MFA method registrations, inbox rules created outside business hours, access from unfamiliar locations, or unusual data activity. Authentication logs alone won’t surface the problem, because from that log’s point of view, the login itself was completely legitimate.

Train users on URL awareness

Employees who understand that a working MFA prompt on an unfamiliar-looking page still represents a real risk are better positioned to pause, check the URL, and report before a session is compromised. A brief team walkthrough of what AiTM lures actually look like in a Microsoft 365 context can meaningfully reduce exposure, and it’s one of the quicker wins available.

Why small businesses are an increasingly attractive target

There’s a common assumption that AiTM attacks are reserved for large enterprises with high-value targets worth the effort of building a custom proxy campaign. That assumption made sense a few years ago. It doesn’t anymore.

Phishing-as-a-Service has collapsed the cost of running a convincing AiTM campaign to something close to zero effort for the attacker. A toolkit that once required real technical skill to build is now a subscription product, complete with support forums and regularly updated proxy templates that mimic Microsoft 365’s login flow down to the pixel. That shift means a 20-person accounting firm in Elkhart is just as reachable a target as a Fortune 500 company, and in some ways more attractive, because the payoff-to-effort ratio is better against a business with no dedicated security team watching for the follow-on signs.

This is the same dynamic we see across most of the cybersecurity topics we write about: attackers increasingly go where the defenses are thinnest, not where the money is biggest. A stolen Microsoft 365 session at a small business gives an attacker access to real client data, real financial conversations, and a real trusted identity to launch further attacks from — all of which are just as valuable to a criminal as anything they’d get from a larger target, without the incident response team waiting on the other side.

What to do if you suspect a session has been hijacked

If something feels off — a colleague mentions a strange email that appeared to come from you, an inbox rule you don’t recognize, or a login notification from a location nobody on your team has been — treat it as a live session compromise until proven otherwise, not as a minor annoyance to look into later.

The first step is revoking active sessions for the affected account, which forces a fresh login and invalidates any stolen token immediately, regardless of what the attacker has done with it since. From there, check for newly created inbox rules and newly registered MFA methods, both of which are the two most common ways attackers quietly lock in persistent access after the initial session theft. Reset the password as a precaution even though the original attack likely didn’t involve the password at all, and review sign-in logs for the affected account over the preceding several days, looking specifically for logins from unfamiliar locations or devices around the time the suspicious activity started.

None of this requires a large security team to execute. It requires knowing to look, and having someone who can move quickly once you do. That’s the part most small businesses in our area are missing, not the technical capability itself.

Stop protecting just the login screen

MFA is a baseline, not a finish line. The businesses that actually reduce AiTM risk are the ones that understand how sessions, tokens, and identity trust really work, and they build controls around each layer of that chain, not just the login screen sitting at the front of it.

This distinction matters more every year. As phishing kits get cheaper and more automated, the gap between “we have MFA” and “we’re actually protected against session hijacking” keeps widening, and most small businesses don’t discover which side of that gap they’re on until something has already gone wrong.

The encouraging part of all this is that closing the gap doesn’t require replacing your entire identity stack or overhauling how your team works day to day. It requires a handful of specific, well-understood changes — phishing-resistant MFA on the accounts that matter most, a Conditional Access policy tuned to catch post-login anomalies, and a team that knows what an AiTM lure looks like when it shows up in their inbox. None of that is exotic. It’s just not yet standard practice at most businesses our size, which is exactly why the attackers keep finding it worth their time.

Frequently Asked Questions

What is an Adversary-in-the-Middle (AiTM) attack?

An AiTM attack is a phishing technique where attackers use a live proxy to intercept login sessions in real time, allowing them to steal session cookies after authentication completes rather than stealing the password itself.

Can AiTM attacks bypass MFA?

Yes, but not by breaking MFA directly. AiTM attacks wait until MFA succeeds, then steal the authenticated session token so no further verification is ever required again during that session.

How can businesses reduce the risk of AiTM attacks?

Using phishing-resistant MFA such as FIDO2 keys or passkeys, tightening Conditional Access policies, training users on URL awareness, and monitoring for unusual post-login session behavior all help reduce exposure meaningfully.

Why don’t failed-login alerts catch AiTM attacks?

Because there’s no failed login to alert on. The attacker isn’t guessing a password or bypassing MFA through brute force — they’re capturing a session token after a completely legitimate, successful authentication event.

Are passkeys enough on their own to stop session hijacking?

Passkeys close the specific gap that lets AiTM proxies relay credentials, since the login is cryptographically bound to the real domain. They’re a major improvement, but pairing them with Conditional Access monitoring and user awareness training gives you defense at more than one layer.