Microsoft 365 is everywhere, which is precisely why it draws so much attention from attackers. The shift from password-based attacks to token theft has changed the threat model significantly. A stolen token bypasses multi-factor authentication, looks legitimate to the cloud, and grants the attacker the same access as the original user. Defending against this calls for techniques that are still surprisingly novel to many IT teams.
How Token Theft Actually Works
Modern phishing kits act as transparent proxies between the user and Microsoft. The user enters credentials and approves the MFA prompt. The kit captures the resulting session token and hands it to the attacker. From that point on, the attacker uses the token directly, often from a completely different country, and Microsoft sees an authenticated session with valid credentials. The original user is none the wiser. Detecting the compromise relies on noticing the unusual sign-in characteristics rather than on any failed authentication event.
Conditional Access Policies Are the First Line of Defence
Conditional access blocks or limits sessions that do not match expected conditions: device compliance, location, app type, and so on. Used aggressively, these policies dramatically reduce the value of a stolen token. A token stolen from a phishing victim in a coffee shop is suddenly far less useful if your policy requires sign-in from a managed device. Azure penetration testing that includes Entra ID examines these policies for gaps, exceptions, and misconfigurations. The default policies Microsoft now recommends are a starting point. The fine-tuning is where the protection actually lives.
Expert Commentary
Name: William Fieldhouse
Title: Director of Aardwolf Security Ltd
Comments: I encounter conditional access policies set up years ago and never reviewed since. Exceptions added during a project, legacy authentication carve-outs, IP allow lists with public ranges, all of it stays in place because nobody owns the periodic review. Token theft thrives on exactly these gaps. Tightening this layer is one of the highest-impact pieces of work available.
Continuous Access Evaluation Helps but Is Not Enough
Microsoft has invested heavily in continuous access evaluation, where revocation events propagate to dependent services rapidly rather than waiting for the next token refresh. This shortens the window during which a stolen token works, but only if you actually trigger revocations when something looks wrong. A policy alone does not invoke itself. Detection has to fire, and someone has to act on it, which is where most organisations still fall short.
Watch for Suspicious Sign-In Patterns
Token theft tends to leave specific footprints. Sign-ins from unusual user agents, especially those mimicking older versions of Office, sign-ins from countries the user does not visit, mass downloads from SharePoint after authentication from a strange location, and new mail forwarding rules created within minutes of a successful login are all classic indicators. Build alerts for each of these and triage them properly when they fire. Time matters here. The longer a stolen token sits unused, the more sense any subsequent activity will make.
Hardening the Whole Tenant
Beyond conditional access, lock down legacy authentication, enforce phish-resistant authentication for privileged accounts, restrict consent grants for non-admin users, and review your application registrations regularly. A best penetration testing company that specialises in Microsoft 365 will identify the patterns specific to your tenant and walk through realistic attack chains rather than reading from a generic checklist.
