Most phishing attacks are still caught the same way they always have been. A suspicious link, an unusual sender, credentials entered on a page that doesn’t quite look right. MFA fires, the attacker is blocked, and the attempt is logged.
That model worked reasonably well for a long time.
It works less well now.
A category of attacks called Adversary-in-the-Middle (AiTM) phishing doesn’t try to steal credentials and log in later. It goes after something more valuable: the authenticated session itself. And by the time the attack is complete, there’s often nothing visibly wrong.
What Actually Happens
The setup looks familiar. A user receives an email that references payroll, a shared document, or something that appears time sensitive. They click the link and are taken to what looks exactly like a Microsoft login page. The branding is correct. The login behaves as expected.
They enter their credentials and approve the MFA prompt.
What they don’t know is that the page they’re on is a live relay controlled by an attacker. The authentication request is passed through to Microsoft in real time. MFA completes legitimately. A fully authenticated session is created.
At that moment, the attacker captures that session through the proxy.
The login was real. The MFA was real. The attacker just relayed the authentication to Microsoft and took the session on the way out.
There’s nothing left to bypass.
Why This Is Different
Traditional credential theft produces a username and password. That’s useful, but MFA often stops it. And even when it doesn’t, session cookies expire and persistence is limited.
AiTM attacks capture something different. A modern authenticated session isn’t just a login. It’s a collection of tokens, claims, and context that represents trust to the systems it touches. That includes access tokens, refresh tokens, session cookies, MFA claims, and device context.
When an attacker has all of that, they aren’t logging in as the user. They’re operating as a trusted identity inside the environment.
From Microsoft’s perspective, the activity can appear to originate from a legitimate, Azure AD-joined device. Normal user behavior and malicious activity can look identical.
From Initial Access to Long-Term Presence
A stolen session is not a temporary problem. It can be expanded.
Once inside, attackers typically move quietly. They review email, map out financial workflows, and observe how the environment operates. Then they use the session to take the next step.
In one recent event, a threat actor used a stolen session to register new devices into the environment. No new login. No new MFA request. The session was already trusted, so the device registration was treated as legitimate.
At that point, the attacker no longer needed the original session to maintain access. They had established additional paths, created persistence, and positioned themselves to operate inside the environment for as long as they needed.
This is how short-term access becomes long-term risk.
What Defense Looks Like
There is no single control that stops this type of attack. Protection comes from layering controls across identity, session, and device.
Phishing-resistant MFA such as FIDO2 or Windows Hello ties authentication to the legitimate service, not a relay. These methods significantly reduce the effectiveness of proxy-based phishing at the point of entry.
Token protection binds sessions to the device they were issued on. Without this, a stolen session can be replayed from anywhere. With it, that replay becomes significantly harder.
Device registration controls matter more than most organizations realize. If any user can register a device into the environment, an attacker with a stolen session can too. Restricting registration removes that persistence path.
Conditional Access policies add context beyond authentication. A valid login from an unexpected location or a non-compliant device should not be trusted the same way a clean login from a known device is.
Legacy authentication protocols should be removed where possible. These older methods can bypass modern controls entirely and create unnecessary exposure.
The Detection Challenge
For a long time, reviewing a login came down to a few questions. Did the user authenticate successfully? Was MFA completed? Did the login come from a known IP or device?
If those boxes checked out, the activity was trusted.
That approach no longer holds.
In an AiTM-driven attack, the login can appear to come from a trusted device. MFA is completed legitimately. The IP and location may look expected. And the attacker can still have full access.
The signals that once indicated a clean login have not disappeared. They’ve just become insufficient on their own.
Detection has to shift toward behavior. New device registrations, unusual access patterns, session activity from unexpected locations, mailbox rules created shortly after login, these are the indicators that matter in this type of attack.
The login is no longer the signal. What happens after it is.
What This Means for Your Organization
Layered controls reduce the attacker’s ability to expand access and establish persistence. But tools alone don’t close the gap.
The difference between legitimate activity and malicious activity in these attacks often comes down to subtle behavioral patterns. Catching that requires more than alerts. It requires experienced analysts who are actively reviewing, correlating, and interpreting what those alerts are actually telling them.
A trusted login does not always mean a trusted user. Understanding the difference is where the real work happens.
If you want to talk through how your environment is positioned against this type of attack, talk to our team today.
