In a previous post, I walked you through an incident response playbook for Token Theft via AiTM. This playbook can be leveraged for BEC incidents as well. Today’s deep dive is going to look at proactive protections you can put into place to PREVENT these attacks altogether. We will be focusing on Conditional Access Policies you can implement. In future post, I will walk through the protections across the entire kill chain of a AiTM/BEC attack that goes beyond Conditional Access.
Free Token Theft Webinar
I will be hosting an in-depth webinar on this topic on June 25, 2025.
My Top Policy Recommendations
The policies we are going to look at focus in on preventing both the initial token harvesting as well as the token replay. It’s fair to say that every one of these policies carries some significant end-user impact if some of the pre-requisites are not in place. We will be walking through each of those considerations in this blog.
Understanding Token Theft vs Token Replay
- Initial Token Harvesting can be performed many different ways but we are focusing on one of the most common with Adversary in the Middle (AiTM) attacks
- If a token is harvested another way such as XSS, malware on a device, a malicious browser extension, etc., we also want to look at how we can prevent replay on another device
- EX: Enforcing a compliance policy for managed devices prevents token harvesting via AiTM BUT this does not prevent the replay if an attacker got the session token via other methods described in the second bullet.
Simulating Token Theft
The short snippet shows me leveraging Evilginx to generate a malicious AiTM page that harvest session tokens from a user logging in.
- The simulation is meant to interpret a user clicking on a link in an email that takes them to a fake Microsoft login page
- In this example, the user has passwordless sign-in setup but normally the password would be harvested as well
- I was able to create the Microsoft 365 phishlet and fake webpage with a domain I registered years ago. (apollocyber.io)
Protections
1. Require a Managed Device
Prerequisites:
- Devices are Entra Joined, Hybrid Joined, or Entra Registered
Conditional Access Policy Settings
- Users> Include All Users
- Users>Exclude Break Glass account + Guest or external users > Service provider users
- Target Resources > All
- Conditions > Device Platforms > Windows
If Hybrid:
- Grant> Grant Access > Require Microsoft Entra hybrid joined device
If Cloud Only:
- Conditions > Filter for Devices > Exclude>Trust Type>Entra Joined
- Grant > Block
Token Theft Experience:
Pros and Cons:
- Pros
- Achievable for many organizations given the prereq is a managed device
- Prevents initial token harvesting via AiTM
- Cons
- Does not prevent token replay
- User password still harvested if not set up for passwordless
2. Require a Compliant Device
Prerequisites:
- Devices are managed and enrolled into Intune
- Compliance policies are configured for every supported device platform
Conditional Access Policy Settings
- Users> Include All Users
- Users>Exclude Break Glass account + Guest or external users > Service provider users
- Target Resources > All
- Grant> Grant Access > Require device to be marked as compliant
Token Theft Experience:
**Same as managed device.**
Pros and Cons:
- Pros
- More flexibility for device types (i.e. Byod) as long as they are enrolled and compliant
- Prevents initial token harvesting via AiTM*
- Cons
- There is a working exploit: Bypassing Intune Conditional Access: TokenSmith Detection & Response
- User password still harvested if not set up for passwordless
- More overhead to set up and support (i.e. Devices falling outside of compliance)
- Does not prevent token replay
3. Require Phishing-Resistant MFA
Prerequisites:
- Authentication Strengths have been configured to support phishing-resistant methods (i.e. FIDO2, Passkeys, etc.)
- Users have registered a phishing-resistant method
Conditional Access Policy Settings
- Users> Include All Users
- Users>Exclude Break Glass account + Guest or external users > Service provider users
- Target Resources > All
- Grant> Grant Access > Require authentication strength > Require Phishing-Resistant MFA
Token Theft Experience:
Pros and Cons:
- Pros
- One of the strongest forms of MFA
- Passwordless (no password harvested)
- Prevents initial token harvesting via AiTM
- Cons
- Hard to garner end-user adoption
- More overhead to set up and support (i.e. more helpdesk calls, money for FIDO2 keys, etc.)
- Does not prevent token replay
4. Require Trusted Location
Prerequisites:
- Named locations have been set up for trusted IPs
Conditional Access Policy Settings
- Users> Include All Users
- Users>Exclude Break Glass account + Guest or external users > Service provider users
- Target Resources > All
- Network> Include>Any Network Location
- Network > Exclude>Selected Network and locations>Include Named Location (OR All Trusted Locations)
- Grant> Block Access
Token Theft Experience:
Token Replay:
Pros and Cons:
- Pros
- Prevents initial token harvesting via AiTM
- Prevents Token Replay
- Cons
- Hard to implement (limited flexibility for end-users)
- More overhead support (i.e. mobile devices, travel, etc.)
5. Require a Device-Bound Token
Prerequisites:
- Devices are Entra Joined, Hybrid Joined, or Entra Registered
Conditional Access Policy Settings
- Users> Include All Users
- Users>Exclude Break Glass account + Guest or external users > Service provider users
- Target Resources > Include > Office 365 Exchange and Office 365 SharePoint Online
- Conditions>Device platforms>include>Windows
- Conditions>Client Apps>Mobile Apps and Desktop Clients
- Grant > (No Selection)
- Session>Require token protection for sign-in sessions (Preview)
Pros and Cons:
- Pros
- Prevents Token Replay*
- Low End-User Friction
- Cons
- Does not prevent token harvesting via AiTM
- Requires P2 Licensing
- Only support desktop clients (not browser)
- Only supports limited apps
Full Breakdown: Breaking Down Token Protection In Conditional Access –
6. Require Global Secure Access
Prerequisites:
- GSA settings configured in Entra (needs at least P1 licensing)
- GSA client deployed on workstations
Conditional Access Policy Settings
- Users> Include All Users
- Users>Exclude Break Glass account + Guest or external users > Service provider users
- Network>Include>Any Network Location
- Network>Exclude>All Compliant Network Locations
- Grant > Block access
User experience with GSA on and off:
Token Theft Experience:
Pros and Cons:
- Pros
- Prevents Token Replay and Token Harvesting via AiTM
- Provides more flexibility (SASE, ZTINA vs traditional firewall, trusted IP, VPN)
- Cons
- Overhead to managed and deploy (client needs to be installed on workstations)
- Early in lifecycle (still has some limitations in preview like not working on Arm/Copilot PCs)
- Full capabilities outside of just Microsoft traffic requires add-on license.
Full Breakdown: What is Global Secure Access? – Global Secure Access | Microsoft Learn
Conclusion
I hope this provided more insight into some token protection policies you can put into place. Some final thoughts on best practice:
- Evaluate the best policy based on the client specific dynamics
- Always turn policies in report-only first and perform proper testing
- Institue a phased rollout in customer environments