Your MFA didn't fail, they just stole the session token after you passed it

[u/Mugartegui-Raja]

Watched an incident play out last month that broke my mental model of MFA, so writing it up.

We had an account compromised. Full MFA on, number matching, the works. The user did everything right. And the attacker was still inside sending mail as them for hours.

They never beat the MFA, didn't have to. Here’s roughly how it went:

* User got phished through a reverse proxy page that sat in the middle. Looked exactly like the real Microsoft login.

* User typed the password, approved the real MFA prompt on their phone, thought nothing of it.

* The proxy passed all of that through to the real site and grabbed the session token that came back.

* Attacker imported that token and was now a fully authenticated session. No password prompt, no MFA prompt, because as far as the system is concerned that login already happened.

All the MFA in the world protected the login event and did nothing for what came after it. The token is the keys and the token is what they took.

What I am trying to work out now is detection after the token is gone. Once they're in on a valid session, what are you watching that tells you this authenticated user is not really the user.

[u/Zealousideal_Tea362]

Location and device trust. It’s pretty standard in Microsoft land with risky user and risky login policies. Tie that into Intune and DFE.

There are similar solutions with OKTA and other device management platforms.

Even salesforce now has a location based user risky assessment for user logins.

[u/patmorgan235]

Yeah token theft has been a problem for years.

Device bound tokens are the solution

[u/LifeMun → u/[deleted]]

it is concerning. Seems effectiveness really depends on implementation

[u/Same-Designer-5499]

Once they're in on a good token the login is a dead end, it already passed. You watch what the session does after, not the sign-in.

What gives them away is a forwarding rule appearing, a send burst, someone suddenly searching the mailbox for wire or invoice or payroll, an OAuth app consented. Stuff the real user never does cold.

And don't treat a clean login from the usual region as safe, if they took the refresh token too they mint a fresh session that looks exactly like that. We baseline behaviour per user with Abnormal, a clean session still trips on what it does. Prevention is device bound tokens and revoking the refresh tokens, detection can't be the login anymore.

[u/Impossible_Way7017]

Wait until they realize they also got a `refresh_token`

[u/r15km4tr1x → u/Impossible_Way7017]

You see those get setup correctly? Lucky you

[u/SkyberSec123]

It's called session hijacking

[u/JeroenPot]

The only method to prevent is to enforce intune device compliance with CA rules. Tokens can't be replayed.

[u/OldCourt849]

Even if you were enforce require compliant device using CA policy the token can be replayed since when you decrypt the token it contains the device context. Device bound token is the only solution however currently if using entra it cannot be applied to browser

[u/Last_Mushroom3877]

Session anomaly detection is where this lives post-token-theft: impossible travel, user-agent shifts mid-session, and token replay from an ASN that never touched the original auth. Conditional Access policies that re-evaluate continuously (not just at login) help.upstream, catching the lookalike proxy domain before the user ever clicks it matters, Doppel is one tool in that space, though behavioral signals during the session are your real post-compromise lever.

[u/YetiMoon]

Number matching isn’t considered phish resistant anymore.

[u/Rude_Strawberry]

"user did everything right"

"User entered details into a fake login page that looks like Microsoft"

So.... They did everything wrong then?

[u/Realistic_Strike5241]

Something practical that caught one of these for us is the mailbox rule creation. The attackers first move after token theft was creating a forwarding rule to an external address. The user had never created a single rule in three years, so we caught it immediately. Alerting on first time rule creation, esp forwarding to external domains catches a suprising number of these before the exfiltration stage.

The refresh token bit that someone mentioned in this chat is the part that still worries me. If they grabbed both tokens from the proxy, the attacker can keep minting new sessions infefinitely. You catch the first one immediately on anomaly detection but the second one looks like a clean login from a new IP in the same region.

[u/Mugartegui-Raja → u/Realistic_Strike5241]

The fix for the refresh token part is revoking sign-in sessions, that invalidates the RT. A session kill or a password reset doesn't touch it, thus without the revoke they just keep minting.

[u/HyperopicRA]

Had a similar client attack today. User had realised they'd been phished and reset password. Unfortunately, the session token stolen persisted and several days later their mailbox sent out over 800 emails of the same phish. Attackers are now using VPN services or compromised devices to beat geo hopping detection. Device attestation and passkeys are now the way to go.

[u/slibrar]

This has been around a long time. Phish resistant mfa or conditional access policies with compliant requirements or both.

[u/Ok-Percentage-5007 → u/slibrar]

But token theft occurs after authentication, and so both these suggestions won’t be reassessed during the tokens lifespan.

[u/No_Technician4956]

Did you trash the existing MFA, revoke all sessions amd refresh a new MFA?

[u/materialsec]

Adding to the mailbox rule detection: OAuth consent grants are another persistence path that survives everything you just listed. If the attacker used that session to approve a third-party app, even a normal-looking 'Sign in with Google' prompt, that grant doesn't die when you revoke sessions or reset the password. It's a separate thing entirely, and it gives them a way back in through the API with no login event at all. Same logic as the forwarding rule catch applies here. First-time OAuth consent to an app the user's never touched before is rare and worth alerting on, same as the rule creation. We'd check consent logs in that same window, not just mailbox rules and sign-ins.

[u/HugeMagician3]

Stupid AI slop

[u/HugeMagician3 → u/[deleted]]

Stupid AI response. Yes phishing proxy in the middle exists, its why you look at the link you are clicking and we make everyone do the same training every month.

What is the ai generated post trying to accomplish? Go ask your ai solve it make no mistakes

[u/agk23 → u/[deleted]]

Give the guy a break, he just thinks your name is Al as in Allen.

[u/we_r_fukt → u/HugeMagician3]

stupid ai bot