Token Theft Incident Response Playbook for Microsoft 365

Token theft occurs when attackers steal a valid cloud authentication token (for example an OAuth access or refresh token, or a Windows Primary Refresh Token (PRT)) and replay it to access resources. Because the stolen token already reflects a successful MFA event and valid permissions, the attacker gains access without needing credentials or new MFA challenges. In Microsoft 365 (Azure AD/Entra ID) environments, tokens include claims like user ID, IP address, MFA status and privileges. An attacker who possesses such a token can impersonate the user and obtain new access tokens as long as the refresh token remains valid. Essentially token theft is “like stealing the pass from your pocket, making a photocopy, and then putting the original back” – the attacker can reuse the token copy until it expires. Token theft is highly stealthy: the attacker’s session appears fully authenticated, often bypassing MFA protections.

Token Types in Microsoft 365

Microsoft 365 uses several token types. Access tokens are short-lived (typically ~1 hour) tokens presented to applications/APIs. Refresh tokens (valid up to weeks or months) allow the client to get new access tokens without re-prompting the user. A Primary Refresh Token (PRT) is a device-bound refresh token issued to Azure AD-joined or hybrid-joined Windows machines, enabling single-sign-on. PRTs contain extra device claims and are protected by hardware (TPM) on the machine. However, all these tokens can be targets: if malware extracts a refresh token or PRT from memory, the attacker can then continuously obtain new access tokens for APIs or portals on that device or elsewhere. In short, stolen tokens carry the same privileges as the original user’s authenticated session.

Attack Techniques for Token Theft

Attackers use several real-world tactics to steal M365 tokens:

Adversary-in-the-Middle (AiTM) Phishing: In AiTM attacks (e.g. using tools like Evilginx2), a phishing page proxies the Microsoft login. The user enters credentials and MFA on the fake site, which passes them to Azure AD. The infrastructure captures the issued tokens (access and refresh) in real time. The attacker immediately obtains the OAuth tokens without ever seeing the password. These methods “go far beyond credential phishing… by inserting malicious infrastructure between the user and the legitimate application”. Once MFA is completed, the attacker gets a valid token that satisfies Azure AD’s requirements.
OAuth Consent (Malicious App) Attacks: Attackers craft malicious or rogue OAuth applications and trick users into granting them permissions. For example, a user might receive a phishing email prompting them to “allow” an Adobe or DocuSign app that is actually attacker-controlled. Once consent is given, the attacker’s service principal can use the client ID/secret or granted tokens to call Microsoft Graph and other APIs on behalf of the user—effectively stealing data and maintaining access without ever stealing the user’s password. These apps often request minimal scopes (like “profile”, “email”, “openid”) to avoid detection. Because the permissions persist until revoked, this yields long-term persistence. (See “Investigating malicious OAuth applications” for search techniques and audit events related to consent and app creation.)
Token Replay / “Pass-the-Cookie”: If malware or an attacker compromises a machine or browser, they may extract existing session cookies or token caches. For example, a browser session cookie or refresh token stored in memory or disk can be captured by malware. The attacker then “replays” that token from anywhere, gaining the same access. In effect this is like pass-the-hash in AD. Microsoft reports commodity malware (and even stock tools) now include token theft functionality. Any client that does not bind tokens to a device can be abused this way.
Session Hijacking / Proxying: In some cases, tools like proxy servers or compromised corporate Single Sign-On can steal tokens. For instance, if an attacker compromises on-premises ADFS or Azure AD Connect, they may obtain tokens or session keys. Similarly, stolen PRTs (Primary Refresh Tokens) on a Windows device could be harvested by attackers and used to mint new tokens.

Regardless of method, the effect is the same: a valid Azure AD token ends up in the attacker’s hands, allowing them to authenticate as that user without going through normal login.

Why Token Theft Bypasses MFA and Enables Persistence

When a stolen token is used, Azure AD sees a valid, already-authenticated token – so MFA isn’t triggered again. From the cloud’s perspective, all requirements were met. The only signs of malicious use are indirect: unusual sign-in properties or simultaneous sessions. Because refresh tokens can be long-lived (days to months) and access tokens are often one-hour, the attacker can maintain access over time without re-prompting the user. In fact, Identity Protection detections exist specifically for replay: “Anomalous token (offline detection)” flags when a token is used from an unfamiliar location or context. Microsoft detected a 111% year-over-year jump in “token replay” attacks (about 147,000 incidents).

Tokens in Azure AD are not bound by default, meaning a stolen token copy is as good as the original. Microsoft is developing stronger protections (token binding/device-binding) for the future , but in practice today a stolen refresh token lets an attacker mint unlimited access tokens for the user until the refresh token is revoked or expires. Primary Refresh Tokens on Windows are bound to the device (protected by TPM), but attackers may still steal them via tools like Mimikatz or by cloning the machine. Defender for Endpoint can even alert on suspicious access to the PRT resource , underscoring its sensitivity.

The persistence achieved by token theft is critical: attackers essentially have a “backdoor” into the tenant that bypasses MFA. They can remain hidden (access data, email, etc.) until the token or its privileges are invalidated.

Detection Strategies

Azure AD Sign-In Logs and Identity Protection: Monitor Azure AD sign-in logs for anomalies. Look for logins under the user’s identity from unfamiliar IPs or geographies, especially if the user is actively signed in elsewhere. Identity Protection (Azure AD P2) provides risk events tailored to token misuse:

Anomalous Token (Offline Replay): Indicates a token used outside expected parameters (possibly replay).
Unfamiliar Sign-in Properties: Flags a sign-in that doesn’t match historical patterns (e.g. new device type).
Non-Interactive (Service) Sign-ins: A “sign-in” where no UI is involved may mean an API token is used. Treat these with extra scrutiny.
Attacker-in-the-Middle (AiTM) Risk: Azure AD can label a sign-in as AiTM (often seen when malicious proxies like Evilginx attempt logins). Azure AD Identity Protection may elevate the user’s risk score to High for token replay, allowing automated actions. For example, if an attacker tries to replay a stolen refresh token, Identity Protection may mark the sign-in as high risk and force re-auth (or block) to deny access.

Microsoft Defender for Cloud Apps (MCAS): Use MCAS (Cloud App Security) to monitor and enforce session controls. Configure it to use Conditional Access App Control on unmanaged or risky sign-ins. MCAS can generate alerts for impossible travel or simultaneous logins from distant locations, and for logins via risky OAuth apps. The Defender XDR ecosystem has specific detections – for example, MCAS can flag a “Stolen session cookie was used” or “Possible AiTM phishing attempt” when connectors for O365/Azure detect replayed session tokens. Set up alerts or policies in Defender for Cloud Apps for suspicious OAuth app consent or excessive scope requests.

Unified Audit Logs: Search the Microsoft 365 Unified Audit Log for forensic evidence of token-theft campaigns. Key events include:

App Registrations / Service Principals: “Add application” or “Add service principal” events in the audit log indicate new enterprise apps. Malicious actors often register a new app or service principal in the tenant for persistence.
OAuth Consent Events: Look for “Consent to application” events, which indicate a user or admin granted permissions to an app. Unfamiliar app names (especially ones cloaked as known brands) should be investigated.
Update Application: If an app’s credentials or permissions were modified, the audit log will show “Update application – Certificates and secrets management.” Attackers often update their malicious app after creation.
Mailbox and Exchange Events: Check Exchange Online audit logs for illicit activity. Look for New-InboxRule (mail forwarding or hide rules) created by the compromised user. Also check for Set-Mailbox events that enable auto-forwarding to external addresses.
Azure AD Audit Logs: In the Azure AD portal, review audit logs for the compromised user or related accounts. Look for added/removed directory roles, group changes, or device registrations.
Integrated SIEM/Logs: Ingest sign-in and audit logs into a SIEM (Azure Sentinel, Splunk, etc.). Use KQL or similar searches for anomalies (e.g. a sign-in from an IP not seen before, or a refresh token event).

In practice, correlate unusual sign-in alerts with these logs. For example, a flagged “anomalous token” sign-in from IP X should prompt checking if any malicious OAuth app was authorized around that time, or if mailbox rules were created immediately afterward.

Token Revocation and Sign-Out

Revoke User Refresh Tokens: Once a token theft compromise is confirmed, immediately revoke all refresh tokens for the affected account(s). In Azure AD, an administrator can do this via the Azure portal or via PowerShell/Graph. For example, use Revoke-AzureADUserAllRefreshToken or the Microsoft Graph invalidateAllRefreshTokens action for the user. This ensures any future attempt to use an old refresh token will fail. Azure AD Portal also offers a “Revoke sessions” or “Sign-out everywhere” button on the user’s profile.

Reset Password: Reset the user’s Azure AD password. This action forces a sign-in re-authentication and also invalidates refresh tokens. In practice, do both: revoke tokens and reset the password to cut off existing tokens.

Note Access Tokens Delay: Remember that revoking refresh tokens does not immediately kill existing access tokens. By default, access tokens live about 1 hour. During that window, the attacker could still use the (soon-to-expire) access token to hit APIs. To minimize this risk, ensure Continuous Access Evaluation (CAE) is enabled for Microsoft 365 apps like Exchange, SharePoint, and Teams. CAE allows immediate revocation on “critical events.” With CAE, when you revoke tokens or raise risk, the client is forced to re-auth sooner, rather than waiting the full token lifetime.

Remove Malicious Consents: If the breach involved a malicious OAuth app, disable or delete that service principal in Azure AD. Remove any consent grants for that app (via Azure AD > Enterprise applications or the Azure Portal > Tokens screen). This cuts off the attacker’s ability to mint new tokens for that app. If only one user consented, remove it at the user’s account or revoke the grant via PowerShell/Graph.

Logout Sessions: Use Intune/MEM or Windows sign-in logs to identify active sessions. Consider having the user sign out of all devices (often done by changing password/terminating sessions). For critical accounts, use Conditional Access “sign-in frequency” controls to force a fresh login.

Mitigation & Containment

Block Attacker IP/Accounts: Identify any suspicious IP addresses used by the attacker and block them. In Azure AD, you can create a Conditional Access rule (or use Defender for Cloud Apps) to block sign-ins from those IPs. If possible, block them at the network or firewall layer. Also consider blocking the compromised user account temporarily in Azure AD until remediation is complete (this can be done via a “Block sign-in” toggle on the user, or marking the account as compromised in Identity Protection).
Enforce Phishing-Resistant MFA: While this applies more to prevention, tightening MFA immediately helps. Ensure the user’s MFA methods are secure. For example, remove any unknown phone numbers/authenticator registrations added by the attacker (Microsoft DART has seen cases where attackers add their own MFA method to accounts). Enable FIDO2 security keys or Windows Hello for Business for high-risk accounts. Especially enforce strong MFA on all admin or highly privileged accounts to prevent repeat logins.
Conditional Access (CA) Policies: Update or apply Conditional Access rules to contain the compromise:
- Require device compliance or domain-joined devices for access to sensitive apps (Exchange, Teams, Admin portals).
- Block or limit legacy authentication protocols (which bypass CA and cannot do modern risk detection).
- For high-risk users or risky sign-ins, require reauthentication or block access. Azure AD Identity Protection risk policies can automate this.
- Use Conditional Access App Control (via Defender for Cloud Apps) for sessions from untrusted devices or locations.
- Implement strict session controls (e.g. sign-in frequency = every time) for sensitive roles, so tokens are frequently reissued and observed.
Continuous Access Evaluation (CAE): Ensure CAE is enabled for all supported cloud apps. CAE allows tokens to be revoked in near real-time on sign-out or risk, rather than waiting an hour. As Microsoft notes, with CAE enabled, “access tokens [are] revoked in near real time following a ‘critical event’… significantly reduc[ing] the up to one hour delay between refresh token revocation and access token expiry”. Use CAE to accelerate cutting off stolen tokens.
Isolate/Remediate Devices: If the token theft likely originated from a compromised endpoint, isolate and sanitize that device. For a stolen PRT or local token cache, disconnect the device, run antimalware scans, and ensure Credential Guard/TPM are enabled. If you’re using Microsoft Defender for Endpoint, investigate alerts like “suspicious PRT access” and consider quarantining the device.
Review OAuth Applications: Audit all registered enterprise applications in Azure AD. Remove any unknown or stale apps. Configure governance – for instance, set “Users can consent to apps” to “No” or use CA for consent. Enable Microsoft Defender for Cloud Apps’ App Governance features if available, which can quarantine or block user-consented apps automatically.
Monitor for Related Alerts: Keep an eye on any “high severity” alerts in Azure AD or Microsoft 365 Defender. For example, if the compromised account triggers multiple alerts in quick succession (risky sign-in, new mailbox rule, etc.), treat it as a likely compromise. Use SIEM or Sentinel to correlate anomalies.
Protect Other Users: Token theft often comes from lateral movement or supply chain (e.g. compromised partner apps). Check other users for similar signs. Ensure all users use MFA, and consider temporarily tightening CA across the tenant (for example, require MFA for all interactive sign-ins until the threat is fully contained).

Post-Incident Remediation and Hardening

Investigate Scope and Cleanup: Conduct a thorough investigation of what the attacker accessed. Use the Unified Audit Log and MCAS to find data exfiltration or mail forwarding. In Exchange Online and SharePoint logs, look for suspicious file downloads or shares. Check if any Service Principals or Secrets were created by the attacker. Remove all malicious mailbox rules, forwarding addresses, and any unauthorized admin accounts or roles. Microsoft DART specifically recommends checking for hidden inbox rules (forwarding to archive/external), global mail forwarding, new MFA methods, or devices enrolled under the attacker’s control.
Revoke Tokens for All Affected Accounts: Beyond the initial user, revoke refresh tokens for any potentially affected service accounts or admins. If there’s any doubt, run Revoke-AzureADUserAllRefreshToken for the broader group of users or even mass revoke (in a worst-case scenario, you may require everyone to re-authenticate).
Rotate Credentials: For any compromised application or service principal, delete and recreate client secrets or certificates. Roll keys or secrets used by internal apps if they were exposed.
Harden MFA and Accounts: Ensure all administrators use separate cloud-only admin accounts (per DART guidance) that have no mailbox and are used only for management tasks. Enforce phishing-resistant authentication (FIDO2 keys, certs) on these accounts. Remove any cloud identity sync from on-prem where possible, to reduce federation-based loopholes.
Strengthen Conditional Access: Based on what you learned, tighten CA policies long-term. For example, require compliant (Intune-enrolled) devices for any access to Microsoft 365. Use Conditional Access: Token protection (Preview) to bind tokens to user devices, making stolen tokens unusable elsewhere. Impose sign-in frequency controls on particularly sensitive apps. Limit OAuth app consent to admins or only allow Microsoft-verified apps.
User Training and Phishing Defenses: Inform users about the incident (as appropriate) and remind them of phishing best practices. Since AiTM phishing and malicious OAuth consent often start with a convincing email, strengthen email security: use Defender for Office 365 to block known phishing links, and monitor for suspicious click-throughs.
Continuous Monitoring: Enable logging and alerts for the future. For example, set up Azure AD Identity Protection to automatically block or reset passwords on high-risk events. Configure Defender for Cloud Apps anomaly detection (impossible travel, infrequent country) for ongoing vigilance.

In all steps, collaborate with stakeholders (IT admins, SOC analysts, legal/compliance) and document actions. The playbook should be integrated into your incident response procedures. By detecting token misuse quickly, revoking stolen tokens, and applying strict controls (Conditional Access, CAE, etc.), you can cut off the attacker’s access and restore a secure state. Regularly review and test these controls, because as Microsoft notes, token theft attacks are evolving and were found in roughly 5% of identity compromises. Staying ahead requires both preventive hardening and a robust IR plan as outlined above.