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 same moment. 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. For businesses in McAllen and across the Rio Grande Valley relying on MFA to protect cloud accounts, this is a critical gap to understand.

Phishing Has Moved Beyond Passwords

Traditional phishing collected usernames and passwords. Modern phishing is after something more immediately useful: the authenticated session itself. 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. Microsoft tracked a 146% rise in AiTM attacks over the past year.

How AiTM Attacks Actually Work

The fake login page that isn't fake

An AiTM phishing site 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 and a functioning MFA prompt. The only clue is a slightly altered URL that goes unnoticed on a mobile screen or when someone is under pressure.

Why MFA doesn't stop it

MFA protects the moment of authentication, not what comes after it. Once a user successfully completes MFA, the service issues a session cookie. Whoever holds the cookie holds the access — no password or MFA prompt required. AiTM attacks simply wait for that cookie to be issued, then steal it.

Session cookies as bearer credentials

Once the cookie is stolen, the attacker imports it into their own browser and immediately resumes the session — inside a fully trusted, already-verified session. There are no failed login alerts and nothing in standard sign-in logs to signal a problem.

What Happens After a Session Is Stolen

Attackers operating inside a stolen session commonly create hidden inbox rules to redirect mail, register additional MFA methods for persistent access, monitor email threads for financial conversations, and launch phishing campaigns against internal colleagues or finance teams. These follow-on actions are why AiTM attacks are frequently discovered late — after financial fraud or data exposure has already begun.

Reducing Your Exposure

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 found phishing-resistant MFA consistently blocked session theft where standard MFA methods did not.

Tighten Conditional Access policies

Watch for activity after login: new MFA method registrations, inbox rules created outside business hours, access from unfamiliar locations. Authentication logs alone will not surface AiTM compromise.

Train users on URL awareness

Here at IT Umbrella Group, we include AiTM awareness in the security training we provide to our McAllen-area managed IT clients. Employees who understand that a working MFA prompt on an unfamiliar URL still represents a risk are far better positioned to catch attacks before they succeed.

Frequently Asked Questions

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

An AiTM attack uses a live proxy to intercept login sessions in real time, stealing session cookies after authentication completes and bypassing MFA entirely.

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 (FIDO2/passkeys), tightening Conditional Access policies, and monitoring for unusual post-login session behavior all significantly reduce exposure.