OAuth Device Code Phishing: How Attackers Steal Tokens Without Passwords

Understanding the attack requires understanding the legitimate flow first.

Legitimate device authorization flow:

1. A device (smart TV, CLI tool, IoT device) that cannot display a browser requests authorization from an OAuth provider. It sends a request to the device authorization endpoint.
2. The OAuth provider returns: a device_code (server-side), a user_code (human-readable, e.g., ABCD-EFGH), a verification_uri (e.g., microsoft.com/devicelogin), and an expiry (typically 15 minutes).
3. The device displays: Visit microsoft.com/devicelogin and enter code ABCD-EFGH
4. The user opens the URL on another device (phone or computer), enters the code, and completes authentication including MFA.
5. The device polls the token endpoint and, once the user completes authentication, receives the access token and refresh token.

How attackers abuse this flow:

1. The attacker, not a device, initiates the device authorization request. They register an Azure AD application or use an existing Microsoft first-party application client ID (which has broad default permissions).
2. The attacker receives the user_code and verification_uri and sends these to the victim via phishing email, Teams message, WhatsApp, or SMS. Common lures: Your Microsoft Teams session has expired. Go to microsoft.com/devicelogin and enter ABCD-EFGH to reconnect.
3. The victim, seeing a legitimate Microsoft URL, opens it on their work device, enters the code, and completes MFA as prompted.
4. The attacker's polling request receives the access token and refresh token. From this point, the attacker has authenticated access to the victim's account without ever touching the victim's password or device.

Why MFA does not help: The victim completes MFA successfully as part of the device code flow. MFA proves that the person entering the code is who they claim to be. It does not validate who initiated the device authorization request. The attacker receives the tokens because they initiated the flow, not because they bypassed MFA.

Why this is worse than credential phishing: Traditional credential phishing captures a password and an MFA code (if using legacy MFA). Organizations can detect and respond by resetting the password. Device code phishing produces refresh tokens valid for up to 90 days in Entra ID default configuration. Even after the victim changes their password, the refresh token remains valid until it expires or is explicitly revoked. The attacker maintains persistent access.

Device code phishing moved from proof-of-concept to active exploitation by well-resourced threat actors between 2024 and 2026.

STORM-2372 (Microsoft designation, 2025): Microsoft identified this threat group, assessed with moderate confidence to have ties to Russian state interests, conducting widespread device code phishing campaigns against government agencies, NGOs, and enterprises across Europe, North America, and Asia. The group sent phishing messages via Microsoft Teams, WhatsApp, and email impersonating Microsoft support. Targets were instructed to visit the legitimate microsoft.com/devicelogin URL and enter attacker-supplied codes. The group obtained access to Microsoft 365 email, Teams messages, SharePoint documents, and OneDrive content.

Cozy Bear / APT29 variations: APT29 has used device code phishing variants targeting government and diplomatic targets, as documented by Volexity and multiple national CERTs. The group combined device code phishing with Microsoft 365 API access to silently exfiltrate emails matching specific keywords without triggering traditional inbox rule alerts.

Financially motivated BEC campaigns: Device code phishing has been adopted by business email compromise (BEC) groups as a more persistent alternative to password spraying. After obtaining tokens, attackers access the victim's email, identify financial approval workflows, and insert themselves into wire transfer conversations. The 90-day refresh token window gives BEC actors weeks to execute the fraud without triggering re-authentication.

Expansion beyond Microsoft: The same technique applies to any OAuth provider that implements the Device Authorization Grant, including Google Workspace. Attacks against Google accounts have been documented targeting organizations that use Google Workspace for email and collaboration.

Device code phishing leaves specific signals in Entra ID sign-in logs that differ from normal interactive authentication. The following Microsoft Sentinel KQL queries identify suspicious patterns.

Query 1: Device code sign-ins from unusual locations

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0
| summarize
    SignInCount = count(),
    Locations = make_set(Location),
    IPAddresses = make_set(IPAddress)
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Locations) > 1
    or SignInCount > 3

This detects accounts completing device code authentication from multiple geographic locations within an hour, or with unusually high frequency.

Query 2: Device code sign-in followed by API-based mail access

SigninLogs
| where AuthenticationProtocol == "deviceCode" and ResultType == 0
| join kind=inner (
    OfficeActivity
    | where Operation in ("MailItemsAccessed", "SearchQueryInitiated")
    | where ClientInfoString has "REST"
) on $left.UserPrincipalName == $right.UserId
| where OfficeActivity.TimeGenerated between (
    SigninLogs.TimeGenerated .. SigninLogs.TimeGenerated + 1h
)
| project UserPrincipalName, SignInTime=TimeGenerated,
    MailAccessTime=OfficeActivity.TimeGenerated,
    Operation, IPAddress

This correlates device code authentication with programmatic REST API mail access in the following hour, a common post-exploitation pattern.

Query 3: Impossible travel following device code authentication

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| order by UserPrincipalName, TimeGenerated asc
| extend PrevLocation = prev(Location),
         PrevTime = prev(TimeGenerated),
         PrevUser = prev(UserPrincipalName)
| where UserPrincipalName == PrevUser
| where Location != PrevLocation
| where datetime_diff('hour', TimeGenerated, PrevTime) < 6

Alert on device code authentication for high-value accounts: For privileged accounts (Global Admin, Security Admin, Exchange Admin, Privileged Role Administrator), alert on any device code authentication attempt, successful or failed. Legitimate device code usage by privileged accounts is rare and should always be investigated.

Several controls in Entra ID and Microsoft 365 directly reduce device code phishing risk. Implement them in order of effectiveness.

If you detect a device code phishing compromise, the response must address token persistence, not just account credentials.

Step 1: Revoke all refresh tokens for the affected account. In Entra ID: Revoke-AzureADUserAllRefreshTokens -UserId user@domain.com or via the Microsoft 365 admin portal: Users > Select user > Sign out. This invalidates all refresh tokens immediately, ending the attacker's session. Note: this also signs the legitimate user out of all sessions.

Step 2: Review and revoke OAuth application consents. In Entra ID admin portal, navigate to the affected user's account and review App registrations and consented permissions. Revoke consent for any applications the user did not intentionally authorize. Look for applications registered in external tenants.

Step 3: Review mail access and exfiltration. Pull Unified Audit Log entries for the affected account for the period from the device code sign-in to revocation. Look for MailItemsAccessed events with REST client strings, SearchQueryInitiated events (indicating keyword searches of the mailbox), and unusual file access in SharePoint or OneDrive.

Step 4: Check for inbox rules and forwarding. Attackers frequently create inbox rules to forward emails or hide their activity. Review mail forwarding rules and inbox rules for the compromised account. Also check for new applications with delegated permissions to the account.

Step 5: Assess blast radius. If the compromised account had access to sensitive data (financial systems, HR data, M&A documents, executive communications), assess what was accessed and notify legal and privacy teams for potential breach notification obligations.