Your organization deployed multi-factor authentication. Password attacks dropped to zero. Credential stuffing became irrelevant. You won the authentication war.
Then the attackers adapted.
Cybercriminals realized they don’t need to break down your front door when they can steal your house key after you’ve already unlocked it and walked inside. This approach bypasses MFA entirely because the authentication already happened—legitimately.
You’ll see it in your logs as successful sign-ins from legitimate user accounts. No failed password attempts. No MFA bypass alerts. Just normal-looking authentication events that aren’t normal at all.
This technique is called token theft, and it’s becoming the new standard attack method. Microsoft detected a 111% increase in these attacks from 2022 to 2023, with incidents surging 703% in 2024. Attackers have moved beyond trying to break authentication—they’re stealing the proof that authentication already happened.
Welcome to the post-MFA threat landscape, where stolen tokens are the new stolen passwords.
How do tokens work?
When a user signs into M365 successfully, 2 or 3 tokens get created for them.
- ID token - proves who the user is
- Access token - grants access to specific resources
- Refresh token - allows the user to request new Access tokens, without prompting them to login again - this one is only created if the settings allow it
Access tokens have a pretty short life-span, usually an hour. Refresh tokens have a longer life-span and allow the user to request new Access tokens.
Tokens are included in the API requests to prove authorization.
Attackers can take either an Access token or a Refresh token and start causing trouble.
Understanding how tokens work explains why traditional security measures feel inadequate against modern attacks. Microsoft Entra ID can’t distinguish between legitimate user sessions and stolen tokens making identical API calls. Your MFA already happened when the legitimate user signed in. Your endpoint protection sees normal application behavior. This is why organizations with strong security foundations still face successful breaches.
How do hackers steal them?
Man-in-the-Middle Phishing (The New Standard) Modern phishing kits like Evilginx, Tycoon 2FA and Mamba 2FA operate as reverse proxies. When your user enters their credentials on a fake Microsoft login page, the kit forwards those credentials to the real Microsoft servers. Your user completes MFA successfully, Microsoft issues tokens, and the phishing kit captures everything—including the tokens—before showing the user a convincing “login successful” page.
From Microsoft’s perspective, this was a completely legitimate login. From your perspective, someone now has access to your user’s account without triggering any MFA alerts.
Browser Compromise and Info Stealers Malware like RedLine Stealer, Raccoon, and Vidar specifically target browser data. They extract saved passwords, cookies, session tokens, and even browser fingerprints. Once installed on a user’s device (often through malicious downloads or compromised websites), these tools export everything needed for account access.
The stolen data gets packaged and sold on underground markets, often including active Microsoft 365 tokens along with the credentials.
Device Code Phishing This technique exploits Microsoft’s legitimate device authorization flow. Attackers trick users into visiting a Microsoft page and entering a device code, claiming they need to “verify their account” or “update security settings.” Once the user approves the request, attackers gain long-term access through the device authorization token.
This method is particularly effective because users see legitimate Microsoft pages throughout the process.
Session Hijacking Through Network Attacks Attackers on the same network (public WiFi, compromised corporate networks) can intercept tokens transmitted over unencrypted connections or through various network-based attacks. While HTTPS protects most traffic, implementation flaws or certificate bypasses can expose tokens in transit.
These attack methods share a common characteristic: they all target the authentication system’s trust assumptions. Traditional security assumes that once someone proves their identity through MFA, their subsequent access attempts are legitimate. Token theft exploits this assumption by stealing proof of that legitimate authentication.
What can we do about it?
Token protection requires a layered approach that goes beyond traditional MFA. Here’s how to build defenses that actually stop token theft and abuse:
Conditional Access: Your First Line of Defense
Require Compliant Devices for Sensitive Access (Requires Entra ID P1) Configure policies that require device compliance for access to critical applications like Exchange Online, SharePoint, and administrative portals. This means stolen tokens won’t work from non-compliant devices—attackers need both the token and access to a managed, compliant device.
Implement Location-Based Restrictions (Requires Entra ID P1) Block access from countries where your organization doesn’t operate. Most Canadian organizations don’t need access from Eastern Europe or Southeast Asia—common sources of token abuse. This simple policy eliminates a significant portion of token-based attacks with minimal impact on legitimate users.
Session Lifetime Controls (Requires Entra ID P1) Enable session lifetime policies that force re-authentication periodically, limiting the value of stolen refresh tokens. Even if attackers steal tokens, they lose access when sessions expire and users need to re-authenticate with legitimate devices.
Advanced Token Protection
Continuous Access Evaluation (CAE) (Included with M365 Business Premium) CAE provides near real-time revocation of tokens when risk conditions change. When you disable a user account or detect suspicious activity, their active tokens become invalid within minutes instead of hours. This significantly reduces the window of opportunity for attackers using stolen tokens.
Token Binding (Requires Entra ID P2) Token binding ties authentication tokens to specific devices using hardware security features. This prevents stolen tokens from working on different devices, even if attackers have all the credential information. Currently only supported on Windows 10 and newer devices.
Privileged Identity Management (PIM) (Requires Entra ID P2) For administrative accounts, PIM requires just-in-time elevation rather than persistent admin rights. Even if admin tokens are stolen, attackers can’t access elevated privileges without additional approval workflows that alert your security team.
Detection and Response
Automated Threat Detection (Requires Microsoft 365 E3/E5 or Defender for Office 365) Modern security platforms can automatically identify suspicious patterns that indicate token theft: users appearing to sign in from multiple countries simultaneously, accounts accessing resources in unusual ways, or authentication events that don’t follow normal patterns. These systems alert your security team when legitimate accounts are being used illegitimately.
Sign-in Monitoring (Available with all M365 plans) Your existing Microsoft 365 environment already logs authentication events that can reveal token theft. Regular review of these logs helps identify compromised accounts before significant damage occurs. Look for patterns that don’t match normal user behavior.
The key to effective token protection is layering these defenses so that attackers must overcome multiple barriers, not just steal a single credential. Even sophisticated attack groups struggle when they need to compromise specific devices, bypass geographic restrictions, and avoid behavioral detection simultaneously.
Technical Requirements and Protection Scope
Where Token Protection Actually Works:
Token protection is most effective for cloud-based applications and services. This includes:
- Microsoft 365 applications (Outlook, Teams, SharePoint, OneDrive)
- Azure-hosted applications and services
- SaaS applications that integrate with Entra ID for authentication
- Custom applications using modern authentication (OAuth 2.0/OpenID Connect)
Important Note: Legacy on-premises applications using older authentication methods (NTLM, Kerberos, basic authentication) don’t use the same token-based authentication system, so these token protection techniques don’t apply to them. However, if these legacy systems are accessible through modern authentication proxies or gateways, some protections may still be relevant.
Immediate Implementation Priorities:
Rather than a lengthy project timeline, focus on these high-impact configurations you can implement immediately:
-
Block Non-Canadian Locations (Entra ID P1 required)
- Create Named Location for Canada in Entra ID
- Apply Conditional Access policy blocking all other countries
-
Require Device Compliance for Admin Accounts (Entra ID P1 + Intune)
- Configure device compliance policy in Intune
- Apply to administrative accounts only initially
-
Enable Continuous Access Evaluation (Included with Business Premium)
- Verify CAE is enabled in Entra ID settings
- Test token revocation timing in lab environment
-
Configure Session Lifetime for High-Risk Roles (Entra ID P1)
- Set 4-8 hour re-authentication for admin accounts
- Apply to financial system access
Monitoring and Detection Setup:
-
Create Sign-in Anomaly Alerts (Available with all plans)
- Set up automated monitoring for “Previously satisfied” authentication
- Alert on sign-ins from new locations with existing sessions
-
Deploy Microsoft Defender Alerts (E3/E5 required)
- Configure alerts for simultaneous sessions from different countries
- Set up detection for unusual API activity patterns
These six configurations provide immediate protection against the most common token theft scenarios.
What are the requirements?
Minimum Licensing for Basic Protection:
- Microsoft 365 Business Premium or Enterprise E3
- Entra ID P1 (included with both Business Premium and E3)
- Microsoft Intune for device compliance policies
Advanced Protection Licensing:
- Entra ID P2 for token binding and PIM
- Microsoft 365 E5 or Microsoft Defender for Office 365 P2 for advanced analytics
- Microsoft 365 E5 Security for full UEBA capabilities
Technical Prerequisites:
- Device management through Intune or compatible MDM solution
- Devices joined to Entra ID (Azure AD joined or hybrid joined)
- Staff trained on new authentication requirements and procedures
Organizational Requirements:
- Clear device usage policies (personal vs. corporate devices)
- Incident response procedures updated for token theft scenarios
- Regular review of access policies and user behavior patterns
- Executive support for implementing potentially disruptive access controls
The Bottom Line
Your MFA investment wasn’t wasted—it stopped the last generation of attacks. But cybercriminals have adapted faster than most organizations’ security strategies.
The 703% surge in these attacks isn’t slowing down. While you’re reading this, attackers are targeting organizations with the same Microsoft 365 environment and MFA setup you have. The difference between victims and survivors isn’t luck—it’s recognizing that authentication security has fundamentally changed.
Organizations that implement token protection now gain a critical advantage. Those that wait will discover their “bulletproof” MFA was actually Swiss cheese—effective against old threats, but full of holes against new ones.
Token protection isn’t a major IT overhaul. Most of what you need is already included in your Microsoft 365 subscription. The question isn’t whether you can afford to implement these protections—it’s whether you can afford not to.
Your security team has the tools. Your licensing probably covers the features. Your organization just needs the decision to prioritize this before attackers make the decision for you.
The cost difference is stark: hours of configuration now, or months of crisis response later.
Don’t wait for the attack that makes you wish you’d acted sooner.
Ready to secure your organization against token theft? Contact me to discuss your specific Microsoft 365 environment and get a practical roadmap for implementation.