OAuth device code phishing has become one of the more insidious identity attack techniques in active use. The reason it works so well: it abuses a completely legitimate authentication flow, produces no malicious URL for a victim to assess, and results in a valid, MFA-satisfied access token that the attacker can use indefinitely — or until it’s revoked.

The technique rose to prominence after Microsoft Threat Intelligence attributed its use to the Russian state-sponsored actor tracked as Storm-2372, targeting government agencies, NGOs, and defence contractors. It’s since been picked up more broadly. If your environment uses Microsoft 365, Azure, or any service that supports OAuth 2.0 device code flow, understanding this attack and building detection coverage for it should be on your detection backlog.

How Device Code Flow Works (and How Attackers Abuse It)

OAuth device code flow was designed for input-constrained devices — smart TVs, printers, IoT devices — that can’t easily display or interact with a browser. The flow works like this:

  1. An application requests a device code from the identity provider (e.g., https://login.microsoftonline.com/common/oauth2/v2.0/devicecode)
  2. The identity provider returns a short code (e.g., BHXZ-TVKQ) and a verification URL (https://microsoft.com/devicelogin)
  3. The user navigates to the verification URL on any device, enters the code, and authenticates including MFA
  4. The original application polls the token endpoint and receives the access token once the user completes authentication

The attack variant: the attacker initiates step 1, extracting the device code and the user-facing URL. They then social-engineer the victim — via email, Teams message, or even a phone call — into visiting the real Microsoft sign-in page and entering the attacker-provided code. The victim authenticates normally, including completing MFA. The attacker’s polling request retrieves a fully authenticated access token without ever touching the victim’s device.

The sophistication is in the legitimacy. The URL the victim visits is microsoft.com/devicelogin — not a lookalike. The authentication flow is genuine. No credential was stolen. No malware was deployed. The victim may not realise anything unusual happened.

What You’re Looking For

Detection must span two planes: identity provider logs (Entra ID sign-in logs, Unified Audit Log) and, where available, endpoint telemetry if the attacker has any stage where they browse or make network requests from a managed device.

Key behavioural signals:

  • Device code flow authentications from unfamiliar locations or ASNs: Legitimate device code auth in your org is typically from office printers, conference room displays, or managed IoT. Auth from Vultr/Linode/residential proxy ASNs is a red flag.
  • Token issuance for high-value resources via device code: First-party Microsoft apps (Office 365 Exchange Online, Azure Management, Microsoft Graph) being accessed via device code flow is unusual in most environments.
  • Subsequent token use from different location than the authenticating device: The victim authenticated from London; the token is being used from Amsterdam 30 seconds later.
  • Rapid email rule creation or forwarding setup post-auth: A common post-exploitation action after gaining Exchange access via stolen device code token.

Sigma Rule: Entra ID Device Code Authentication from Suspicious ASN

title: Azure AD Device Code Flow Authentication from Suspicious Infrastructure
id: 7f4b3a1e-9c2d-4f8a-b5e6-0d1c7f3a9b2e
status: experimental
description: Detects OAuth device code flow sign-ins from known hosting/VPN ASNs, indicating possible device code phishing
references:
    - https://www.microsoft.com/en-us/security/blog/2025/02/13/microsoft-threat-intelligence-storm-2372
    - https://attack.mitre.org/techniques/T1078/004/
author: SOC Analyst Hub
date: 2026-05-30
tags:
    - attack.initial_access
    - attack.t1078.004
    - attack.credential_access
logsource:
    product: azure
    service: signinlogs
detection:
    selection:
        AuthenticationProtocol: 'deviceCode'
        ResultType: '0'  # Success
    filter_legitimate:
        # Allowlist your known device code clients
        AppDisplayName|contains:
            - 'WindowsDefenderATP'
            - 'Microsoft Intune'
    filter_trusted_asn:
        # Add your corporate ASN ranges
        NetworkLocationDetails|contains:
            - 'compliantNetwork'
            - 'trustedNamedLocation'
    condition: selection and not 1 of filter_*
falsepositives:
    - Legitimate use of device code flow from home networks or travel
    - New devices not yet classified as trusted
level: medium

Tune this rule by adding your corporate IP ranges and known device-code-using applications to the allowlist. The goal is isolating auth events where device code was used from infrastructure you don’t recognise.

KQL: Hunting for Device Code Auth with Subsequent Impossible Travel

// Step 1: Find device code authentications
let DeviceCodeAuths = SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0
| project
    UserId,
    UserPrincipalName,
    AuthTime = TimeGenerated,
    AuthLocation = Location,
    AuthIPAddress = IPAddress,
    AppDisplayName,
    ResourceDisplayName;

// Step 2: Find subsequent token use within 5 minutes from a different location
SigninLogs
| where TimeGenerated > ago(7d)
| join kind=inner DeviceCodeAuths on UserId
| where TimeGenerated between (AuthTime .. AuthTime + 5m)
| where IPAddress != AuthIPAddress
| where Location != AuthLocation
| project
    UserPrincipalName,
    AuthTime,
    AuthLocation,
    AuthIPAddress,
    SubsequentLocation = Location,
    SubsequentIPAddress = IPAddress,
    AppDisplayName,
    ResourceDisplayName
| where SubsequentLocation !contains AuthLocation

This query is expensive on large tenants — scope it to a rolling 7-day window and consider scheduling it as a scheduled analytics rule rather than a continuous query.

KQL: Post-Auth Exchange Inbox Rule Creation

Immediate inbox rule creation after device code auth is a strong indicator of post-exploitation mail collection:

let SuspiciousDeviceCodeUsers = SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0
| where TimeGenerated > ago(24h)
| distinct UserPrincipalName;

OfficeActivity
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| where UserId in (SuspiciousDeviceCodeUsers)
| where TimeGenerated > ago(24h)
| project TimeGenerated, UserId, Operation, Parameters, ClientIP

Hunting Approach

If you’re running a focused hunt rather than continuous detection, the most efficient path is:

  1. Pull all device code flow authentications from the past 30 days
  2. Cross-reference authenticating IP addresses against known infrastructure ASNs (Vultr, Linode, DigitalOcean, Hetzner, M247, residential proxy ranges)
  3. For flagged accounts, review subsequent access to Exchange, SharePoint, and Graph API
  4. Look for OAuth app consent grants in the audit log following device code auth — attackers sometimes use the access to register persistent OAuth apps

The Entra ID sign-in log field is AuthenticationProtocol = "deviceCode". In the Unified Audit Log the relevant operation is UserLoggedIn with AuthenticationMethod: DeviceCode.

Countermeasures and Hardening

Detection is important, but this attack class has viable preventive controls:

  • Conditional Access: block device code flow for user accounts — this is the most effective control. In Entra ID, Conditional Access policy can block the device code authentication flow entirely for accounts that don’t require it. Most enterprise users do not need device code auth.
  • Restrict device code flow to Intune-compliant devices only — if you use device code for legitimate purposes, require device compliance as a condition.
  • User awareness: if employees know that Microsoft will never ask them to enter a code someone gave them in an email or Teams message, the social engineering vector is weakened.
  • Monitor OAuth app consent: new app consent grants following device code authentication are a signal worth reviewing.

Device code phishing is likely to continue as a primary initial access vector for identity-focused threat actors as long as it remains more reliable than traditional phishing for high-value MFA-protected accounts. Coverage gaps are common — most environments have never audited their device code flow exposure.