Stolen session tokens walk straight past your MFA

Earlier this week we wrote about BigBear, a phishing service that got past Microsoft 365 two-factor authentication at 258 organisations. That article covered what happens. This one covers the how and the why, because once you understand the technique, you see straight away where the real weak spot is. It is not in the second factor itself, it is in the environment we work in every day. That is a reason to feel slightly uneasy.

MFA protects a single moment

HTTP, the protocol underneath every website, has no memory: by your second click the server no longer knows that you just signed in. That is why you are handed a proof of sign-in, a cookie or token, which your browser sends along with every request that follows.

That proof is called a bearer token: whoever carries it gets in. Think of the wristband at a festival. Your ticket is checked at the gate, and after that nobody looks at your face again. Cut the band off and put it on yourself, and you walk onto the site just as easily.

In Microsoft 365, one of those wristbands is called ESTSAUTHPERSISTENT: the cookie you receive when you click "stay signed in", which according to Varonis can remain valid for up to ninety days. Many tokens are JSON Web Tokens (JWTs), made up of a header, a payload with data and a digital signature. The signature stops anyone from altering the contents, but the payload is only base64 encoded. Packaging, not a safe.

A Microsoft token also carries a field called amr, which records how you signed in, for example pwd and mfa. At that point the second factor is no longer a check, it is a line of text. Whoever reuses the token gets that line for free. Attackers have found three ways to obtain such a token.

Route 1: the middleman who listens in

BigBear ran on Evilginx, an open source reverse proxy released in 2017 as a tool for penetration testers. The victim clicks a link to the attacker's domain. That server fetches the genuine Microsoft sign-in page, passes it on and rewrites every reference along the way, so the victim's browser stays with the proxy.

The victim therefore sees the real page, complete with their own organisation's logo and a real padlock. The connection is encrypted, just with the wrong party. Password and MFA code travel through the proxy to Microsoft, which approves the sign-in and returns the session cookie. To the proxy, which keeps a copy. Text message, authenticator code or push notification: it makes no difference. The proxy does not have to break anything, it only has to listen.

CloudSEK gained access to the BigBear 2.0 control panel and found over four thousand session cookies. Traffic ran through residential proxies in 69 countries, each time close to the victim, so that Microsoft saw no unusual location.

Passkeys hold up, as long as the back door stays shut

Where this trick breaks down is FIDO2, the technology behind passkeys and hardware keys. With a code, a human judges whether the page is genuine. With a passkey, the browser does. The key belongs to one domain, and the browser itself puts the address of the page into the signed sign-in. On a phishing domain, the passkey is not even offered. A person can be misled. A browser comparing two domain names cannot.

So attackers aim at the fallback instead. Proofpoint showed how a modified Evilginx configuration poses as Safari on Windows, a combination for which Entra ID does not support FIDO. Microsoft then politely offers the authenticator app. BigBear simply switched off the passkey function in the victim's browser with a piece of JavaScript. Your sign-in is only as strong as the weakest method still enabled.

Route 2: not intercepting, just taking

Why intercept a session when it is already sitting on the disk? Browsers keep cookies in a database file in the user profile. On Windows, that file was encrypted with DPAPI for years, which lets any program running under the same account decrypt the data again. Malware included.

In July 2024, with Chrome 127, Google introduced App-Bound Encryption: the key is released only if the request really comes from Chrome. According to Elastic, that held for about two months. Stealers read cookies from memory, granted themselves system rights or abused Chrome's debugging feature. Google closed that route, after which VoidStealer this year attached itself as a debugger and looked on at the moment Chrome decrypts its key. A game of cat and mouse, with a creative mouse.

The loot ends up in log files traded on Telegram. Okta analysed a free dump that appeared on 2 August: seven gigabytes from 5,871 infected computers in 162 countries, including 9,213 valid tokens for Google and 1,763 for Microsoft. With an anti-detect browser, which imitates the victim's digital fingerprint, such a cookie is loaded in moments. To the service it looks as though the user is simply carrying on.

Route 3: let the victim issue the token for you

The most cunning route uses no fake website at all. The device code flow is the method you use to sign in a smart TV, for instance: go to this page and enter this code. An attacker requests such a code himself and sends it to the victim, dressed up as an invitation to a Teams meeting. The victim signs in at the genuine microsoft.com/devicelogin, completes the genuine MFA and thereby authorises the attacker's device.

Because everything happens on the real domain, not even a passkey helps here. According to Microsoft, the Storm-2372 group went further still and used this route to register a device of its own in the victim's Entra environment. At that point they have not borrowed a session, they have been handed a workstation.

AI keys: tokens with no expiry date

A session cookie eventually expires, an API key often does not. No session, no device, no second factor: just a string of characters in a configuration file, exactly what stealers look for. The same dump held 24 working API keys for AI services and 164 valid tokens for Anthropic, which at the end of August signed out Claude users whose sessions had been captured by malware. The biggest risk lies in the integrations: an agent that reads mail on behalf of an employee runs on a token with precisely those rights. Whoever holds the token holds the agent.

The defence moves to the session

If a token works everywhere, the answer is to make it work on one device only. That is what Device Bound Session Credentials (DBSC) does. The browser creates a key pair in the TPM chip, the service issues only short-lived cookies, and to obtain a fresh cookie the browser has to prove, with that non-exportable key, that it is still the same computer. A stolen cookie becomes worthless outside the door before long. Since Chrome 146, DBSC has been generally available on Windows. Microsoft offers something comparable with Token Protection in Entra ID, although for browser sessions that is still in preview.

It is no silver bullet. Malware watching live on the computer can simply use the session from inside the browser that is already signed in. A clean, managed workstation remains the foundation.

What you can do

•        Use passkeys or FIDO2 keys and switch off weaker fallback options, certainly for administrators and finance roles.

•        Give only managed, up-to-date devices access to company data, and enable Token Protection where you can.

•        Block the device code flow through Conditional Access, unless you genuinely need it.

•        Shorten sessions for sensitive applications and be careful with "stay signed in".

•        Map which API keys are in circulation, keep them in a vault, give them minimal rights and set spending limits.

•        When in doubt, a password reset is not enough: revoke sessions and tokens explicitly.

How we look at this

In the environments we manage, these are not separate measures but settings in the policy around identity and devices: which sign-in methods are enabled, how long sessions stay valid, and how unusual token use is spotted. That work is largely invisible to employees, and that is precisely the point. This is our balancing act: maximum security is priority number one, but it must not get in people's way, because then the rules will be worked around sooner or later.

Would you like to know which fallback options are still open in your environment and how long your sessions stay valid? Book a call with one of our engineers and we will go through it together.

Sources

1. Infostealer Logs Expose Replayable AI Tokens That Can Bypass MFA — The Hacker News (2026-09-09)
2. Anthropic waarschuwt Claude-gebruikers voor malware die tokens steelt — Security.NL (2026-08-31)
3. The Secrets Agentic AI Leaves Behind — Okta (2025-06-30)

Read also

Why two-step verification does not stop this phishing

Record Windows update round with two exploited flaws

Attackers take over routers through open admin access