Microsoft 365 Session Token Theft: Why MFA Passes and the Attacker Still Gets In
MFA does not make every session immune to theft. Understand the token type, require appropriate authentication and device controls, and use a containment process that checks whether access has actually ended.
AZ / decision fieldnote
Authentication ends. The session continues.
Session theft / access pathway
User signs in
A deceptive intermediary relays authentication
Session captured
The authenticated session becomes the target
Session replay
Access can continue without a new password prompt
Use this in your decision
Review the life of the session alongside the strength of the sign-in.
- Which sign-in methods resist phishing?
- What constrains access after authentication?
- Can the response team identify and revoke affected sessions?
Reading aid for this article. The analysis and supporting sources follow below.
An adversary-in-the-middle phishing page can relay a legitimate sign-in and capture a resulting session artifact. MFA may have succeeded while the attacker still obtains a way to reuse the session. The useful response is to identify the access path and its controls, rather than treating “MFA enabled” as the end of the assessment.
Match the control to the access path
| Control | What to check | Limit to account for |
|---|---|---|
| Phishing-resistant authentication | The required strength and actual user method | Registration alone does not enforce a policy |
| Device requirements | Which apps and devices must satisfy the access policy | Coverage and exceptions need validation |
| Token Protection | Supported resource, platform and application | It does not cover every browser or application |
| Detection and response | An alert reaches an accountable reviewer | A licensed detection is not a staffed response service |
Microsoft’s Token Protection documentation now includes limited browser support in preview for selected applications accessing Azure Resource Manager, alongside supported native-app resources. Do not describe it as protecting every browser session, or as having no browser support at all. Check the current Token Protection support matrix for the exact scope.
A password reset is not a complete containment check
Password changes and administrator resets affect token classes differently. Microsoft’s refresh-token revocation matrix distinguishes password-based tokens, non-password cookies and other sessions. Avoid claiming that a reset either ends all access or never revokes anything.
Use an authorized response runbook: block or disable compromised access as appropriate, revoke sessions, address affected devices and investigate persistence. Existing access tokens and application-owned sessions may require additional action or time. Verify containment using Microsoft’s access-revocation guidance and the affected application’s controls.
Check what could outlive the stolen session
- Unexpected authentication methods or credential changes.
- New application consent or permissions.
- Mailbox forwarding, inbox rules and delegated access.
- Other affected users, devices and sessions.
- Emergency-access arrangements and the evidence needed before restoring normal access.
These checks need an incident owner and appropriate authorization. A public checklist cannot determine which accounts to disable in a specific live system. Preserve relevant evidence and record what was changed, when and by whom.
For preventive work, start with a bounded pilot
Agree representative allowed and denied sign-ins. Check emergency access and reporting before enforcement. Document exceptions with owners and review dates. A tenant-wide policy should not go live merely because a test administrator can sign in.
The MFA and Conditional Access hardening scope covers agreed preventive changes and validation. Device-code phishing is a separate authentication path to include in the review.
About this article
Published by AZ Innovations, led by Alwatheq Zboun. We complete scoped Microsoft 365, security, migration and automation work. See who does the work or the delivered work.
Know which accounts are properly protected, and be able to prove it.
We review sign-in controls, agree pilot changes and validate the allowed and denied access paths. Active compromise needs a separately authorized response scope.