detecting-oauth-token-theft（detecting OAuth token theft 安全）

Detecting OAuth Token Theft

When to Use

• Investigating alerts for impossible travel or anomalous token usage in Microsoft Entra ID
• Responding to a suspected session hijacking or pass-the-cookie attack
• Configuring proactive defenses against OAuth token theft in an Azure/M365 environment
• Detecting OAuth device code phishing campaigns that bypass MFA
• Analyzing sign-in logs for token replay indicators
• Implementing Token Protection conditional access policies to bind tokens to devices

Do not use for on-premises Kerberos ticket attacks (pass-the-ticket, golden ticket); use Active Directory-specific investigation techniques for those scenarios.

Prerequisites

• Microsoft Entra ID P2 license (required for Identity Protection risk detections and conditional access)
• Global Administrator or Security Administrator role in the Entra admin center
• Microsoft Defender for Cloud Apps (MDCA) license for session anomaly detection
• Access to Entra ID Sign-in Logs and Audit Logs (requires Diagnostic Settings configured to Log Analytics or Sentinel)
• Familiarity with OAuth 2.0 authorization flows (authorization code, device code, client credentials)
• Microsoft Sentinel or equivalent SIEM ingesting Entra ID sign-in and audit logs

Workflow

Step 1: Understand the Token Theft Attack Surface

Identify which token types are at risk and how they are stolen:

Token Type            | Lifetime     | Theft Vector                    | Impact
----------------------|-------------|----------------------------------|------------------
Access Token          | 60-90 min   | Memory dump, proxy interception  | API access for token lifetime
Refresh Token         | Up to 90 days| Browser cookie theft, malware   | Persistent access, new access tokens
Primary Refresh Token | Session-based| Mimikatz, AADInternals, malware | Full SSO to all M365/Azure apps
Session Cookie        | Varies      | XSS, browser exploit, AitM proxy | Full session hijacking
Device Code Token     | 15 min auth | Phishing (device code flow abuse)| Attacker gets refresh token via social engineering

Common attack techniques:

• AitM Phishing (Adversary-in-the-Middle): Attacker proxies the legitimate login page via tools like Evilginx2, capturing session cookies and tokens after the user completes MFA
• Device Code Phishing: Attacker generates a device code, sends it to the victim via email/Teams, victim authenticates, attacker receives the token
• PRT Extraction: Attacker with local admin on a device extracts the Primary Refresh Token using Mimikatz (sekurlsa::cloudap) or AADInternals
• Browser Cookie Theft: Malware or infostealer exfiltrates browser cookies containing session tokens

Step 2: Configure Entra ID Sign-in Risk Detection

Enable Identity Protection to flag anomalous token usage:

Entra Admin Center > Protection > Identity Protection > Risk Detections

Key risk detections for token theft:
- Anomalous Token        : Token has unusual characteristics (claim anomalies)
- Token Issuer Anomaly   : Token issued by an unusual token issuer
- Unfamiliar Sign-in     : Sign-in from a location not seen before for the user
- Impossible Travel      : Sign-ins from geographically distant locations in impossible time
- Malicious IP Address   : Sign-in from a known malicious IP
- Suspicious Browser     : Sign-in from a suspicious or attacker-controlled browser

Configure risk-based conditional access:

Entra Admin Center > Protection > Conditional Access > New Policy

Policy Name: "Block High-Risk Sign-ins - Token Theft Protection"
Assignments:
  Users: All users (exclude break-glass accounts)
  Cloud Apps: All cloud apps
Conditions:
  Sign-in Risk: High
Grant:
  Block access

Policy Name: "Require MFA for Medium-Risk Sign-ins"
Assignments:
  Users: All users
  Cloud Apps: All cloud apps
Conditions:
  Sign-in Risk: Medium
Grant:
  Require multifactor authentication
  Require password change

Step 3: Enable Token Protection (Preview)

Configure Token Protection to bind sign-in session tokens to the device:

Entra Admin Center > Protection > Conditional Access > New Policy

Policy Name: "Enforce Token Protection for Desktop Sessions"
Assignments:
  Users: All users (start with a pilot group)
  Cloud Apps: Office 365 Exchange Online, Office 365 SharePoint Online
  Conditions:
    Device Platforms: Windows
Session:
  Require token protection for sign-in sessions (Preview): Enabled
Grant:
  Require device to be marked as compliant
  OR Require Hybrid Azure AD joined device

Token Protection ensures that access tokens are cryptographically bound to the device's Trusted Platform Module (TPM). If an attacker steals a token and replays it from a different device, the token is rejected because the proof-of-possession key does not match.

Step 4: Detect Token Replay in Sign-in Logs

Query Entra sign-in logs for indicators of token theft:

// KQL query for Microsoft Sentinel or Log Analytics
// Detect sign-ins where the token was issued in one location and used in another
SigninLogs
| where TimeGenerated > ago(7d)
| where RiskDetail contains "token" or RiskEventTypes_V2 has "anomalousToken"
| project TimeGenerated, UserPrincipalName, IPAddress, Location,
          RiskDetail, RiskLevelDuringSignIn, AppDisplayName,
          DeviceDetail, ClientAppUsed, TokenIssuerType
| sort by TimeGenerated desc

// Detect impossible travel with token reuse
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0  // Successful sign-ins only
| summarize Locations=make_set(Location), IPs=make_set(IPAddress),
            Count=count() by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Locations) > 1
| sort by TimeGenerated desc

// Detect device code flow abuse (often used in phishing)
SigninLogs
| where TimeGenerated > ago(7d)
| where AuthenticationProtocol == "deviceCode"
| project TimeGenerated, UserPrincipalName, IPAddress, Location,
          AppDisplayName, DeviceDetail, ResultType
| sort by TimeGenerated desc

// Detect token replay: same token used from multiple IPs
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize IPs=make_set(IPAddress), IPCount=dcount(IPAddress)
            by UserPrincipalName, CorrelationId
| where IPCount > 1
| sort by IPCount desc

Step 5: Investigate and Respond to Token Theft

When a token theft event is detected, follow this response procedure:

# Step 5a: Revoke all refresh tokens for the compromised user
# Microsoft Graph PowerShell
Connect-MgGraph -Scopes "User.ReadWrite.All"
Revoke-MgUserSignInSession -UserId "user@contoso.com"

# Step 5b: Force password reset
Update-MgUser -UserId "user@contoso.com" -PasswordProfile @{
    ForceChangePasswordNextSignIn = $true
}

# Step 5c: Review and revoke OAuth app consent grants
# Check for malicious app consent (common post-compromise persistence)
Get-MgUserOauth2PermissionGrant -UserId "user@contoso.com" |
    Select-Object ClientId, ConsentType, Scope

# Remove suspicious OAuth grants
Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "<grant-id>"

# Step 5d: Review enterprise app registrations for rogue apps
Get-MgServicePrincipal -Filter "displayName eq 'Suspicious App'" |
    Select-Object AppId, DisplayName, SignInAudience

# Step 5e: Check for mail forwarding rules (common post-compromise action)
Get-MgUserMailFolderRule -UserId "user@contoso.com" -MailFolderId "Inbox" |
    Where-Object { $_.Actions.ForwardTo -ne $null -or $_.Actions.RedirectTo -ne $null }

Step 6: Implement Continuous Access Evaluation (CAE)

Enable CAE to revoke tokens in near-real-time when conditions change:

Entra Admin Center > Protection > Conditional Access > Continuous Access Evaluation

Settings:
  Strictly enforce location policies: Enabled

CAE ensures that when you revoke a user's session or change their
risk level, the enforcement happens within minutes rather than waiting
for the access token to naturally expire (60-90 minutes).

Critical events that trigger immediate token revocation with CAE:
- User account disabled or deleted
- Password changed or reset
- MFA enabled for the user
- Admin explicitly revokes refresh tokens
- Azure AD Identity Protection detects elevated user risk
- Network location change violates conditional access policy

Step 7: Configure Defender for Cloud Apps Session Policies

Set up real-time session monitoring to detect and block suspicious token usage:

Microsoft Defender for Cloud Apps > Policies > Session Policies

Policy: "Block download from unmanaged device with stolen token"
  Session Control Type: Monitor and block activities
  Activity Source: App = Office 365, SharePoint Online
  Activity Filter: Device tag does not equal "Compliant"
  Activity Type: Download
  Action: Block

Policy: "Alert on mass file download (exfiltration via stolen token)"
  Session Control Type: Monitor only
  Activity Source: App = Office 365
  Activity Filter: Repeated activity > 10 downloads in 5 minutes
  Action: Alert administrators

Key Concepts

Verification

• Identity Protection risk detections are enabled and generating alerts for anomalous token activity
• Conditional access policies block high-risk sign-ins and require MFA for medium-risk
• Token Protection policy is applied to pilot group and confirmed working (test from unregistered device fails)
• KQL queries in Sentinel return results when tested against synthetic token anomaly events
• Continuous Access Evaluation is enabled and verified (revoke session, confirm access blocked within minutes)
• Defender for Cloud Apps session policies are active and monitoring download activity
• Device code flow is restricted via conditional access (block or require compliant device)
• Incident response runbook includes token revocation, password reset, and OAuth consent review steps
• Mail forwarding rules and OAuth app grants are audited for compromised accounts