A standard incident-response question after a phishing report is “did they have MFA?” If the answer is yes, many teams relax. That instinct is increasingly wrong. Infostealer malware and adversary-in-the-middle phishing kits do not need to beat multifactor authentication, because they take what MFA produces: the session.
Once a user has signed in, the browser or app holds a session cookie or token that proves the sign-in already happened. Copy that artifact to another machine and the service sees an authenticated user. No password prompt, no MFA challenge. The incident does not end when the password is reset, and in some environments it does not end when the user is told to sign in again.
How the session gets stolen
Two routes dominate. Infostealers such as Lumma, RedLine, StealC, and Vidar, the strains Flashpoint named as most prolific in its 2025 midyear threat intelligence index, harvest saved passwords, browser cookies, and tokens from infected endpoints in bulk. Flashpoint reported about 1.8 billion credentials compromised in the first half of 2025 from roughly 5.8 million infected devices; the report’s headline growth figure has been described in coverage against different baselines, so quote the totals, not the percentage.
The second route is adversary-in-the-middle phishing. A reverse proxy sits between the victim and the real sign-in page, relays the MFA challenge, and captures the cookie issued after the user succeeds. Session lifetime then sets the damage: a persistent cookie that stays valid for weeks gives the attacker weeks.
Notice what neither route requires: breaking the cryptography of the second factor. This is why phishing-resistant authentication such as FIDO2 security keys and passkeys helps against the proxy route (the credential is bound to the real site’s origin) but does nothing against malware that steals the session after a legitimate sign-in on a compromised endpoint.
Why a password reset does not end it
Responders often reach for a password reset, which is necessary but not sufficient. Microsoft’s documentation on continuous access evaluation notes that, by default, access tokens last one hour and are then refreshed, so what matters is whether the refresh token and the session behind it are killed. In a Microsoft Entra environment the response checklist has to include revoking the user’s refresh tokens (the Revoke Session action, or the equivalent Graph command), not only changing the password.
Persistence is the other trap. In the gift-card fraud campaign Unit 42 described in October 2025, attackers registered rogue authenticator apps and enrolled their own devices in Entra ID, which kept access after password resets or session revocations. After a suspected token theft, audit authentication methods and registered devices, and remove what the user did not add.
Three layers that change the outcome
No single control closes this gap. Three layers, applied together, do most of the work.
1. Revoke fast, and evaluate continuously
Continuous access evaluation (CAE) in Microsoft Entra lets supported services such as Exchange Online, SharePoint Online, and Teams react to critical events without waiting for a token to expire. Microsoft lists those events as account deletion or disablement, password change or reset, MFA enablement for the user, an administrator revoking all refresh tokens, and high user risk detected by Entra ID Protection. Microsoft says the goal is near real time, with latency of up to 15 minutes possible, and IP-location policy enforcement is instant.
Know the limits. CAE covers a defined set of services and clients; some Office web combinations are listed as not supported, and guest accounts are not supported. A revocation that works for Outlook may leave a third-party SaaS app untouched, so your playbook needs a revocation step for each application that holds its own sessions.
2. Bind the session to the device
If a stolen cookie only works on the machine that created it, replay from the attacker’s infrastructure fails. Two implementations matter now.
Microsoft Entra’s Token Protection, a Conditional Access session control, requires device-bound sign-in session tokens such as Primary Refresh Tokens. Microsoft’s documentation lists general availability for native apps on Windows, iOS, iPadOS, and macOS, with browser-based support still in preview and limited to selected web apps that access Azure Resource Manager. Supported resources for native apps are Exchange Online, SharePoint Online, and Teams, plus Azure Virtual Desktop and Windows 365 on Windows. In practice that means it protects the desktop client; it does not yet cover the ordinary browser session that most SaaS use depends on.
Google’s Device Bound Session Credentials (DBSC) tackles the browser directly. According to Google, Chrome generates a key pair in hardware-backed storage such as the TPM, issues short-lived cookies only after the browser proves it holds the key, and so exfiltrated cookies expire quickly. Google announced availability on Chrome 146 for Windows in April 2026, with macOS to follow, and a Workspace update in May 2026 described it as generally available there. Treat it as a strong but uneven control: sites must adopt it, unsupported devices fall back to standard behavior, and it protects the cookie, not the passwords or other secrets a stealer also harvests.
3. Make conditional access punish replay
Where binding is unavailable, use policy to narrow the window. Require a compliant or managed device for mail and file access, so a cookie replayed from an unmanaged machine fails the device check. Use IP-based named locations where your egress is stable, since CAE enforces those instantly. Shorten sign-in frequency for privileged roles, and treat risk signals such as new ASN, new OS, or impossible travel as grounds for step-up or session termination rather than for a note in the ticket.
What to change in the incident playbook
Rewrite the “suspected account compromise” runbook around the session, not the password:
- Revoke all sessions and refresh tokens first, then reset the password.
- Review authentication methods, registered devices, inbox rules, and OAuth consents; remove anything unrecognized.
- Isolate and reimage the endpoint if infostealer activity is suspected. Resetting a credential while the malware remains simply hands the attacker the next one.
- Rotate secrets the endpoint could reach: saved browser credentials, API keys, and SSH keys.
- Check sign-in logs for the stolen session’s use from a new device or network, and scope what it accessed.
MFA is still worth having; it stops the unsophisticated majority of credential-stuffing and password-spray attempts. It just no longer marks the end of the investigation. The question to ask after a phishing report is not whether the account had MFA, but whether the session that MFA produced is still in someone else’s hands.
Product behavior described here reflects Microsoft’s and Google’s published documentation as of October 2026; confirm licensing requirements and platform support in your own tenant before relying on it. Infostealer volume figures come from vendor research. See Microsoft’s Token Protection documentation and continuous access evaluation documentation.