Device code phishing

How it works

OAuth's device code flow exists for input-constrained hardware: a smart TV or a console that cannot easily accept a password shows a short code and a URL, the user opens that URL on a phone or laptop, signs in, and enters the code to link the two devices. The design deliberately separates the device requesting access from the device approving it.

An attacker starts that flow themselves, gets a real code from the real identity provider, and sends it to the victim inside a lure, often disguised as a document share, a Teams meeting invite, or a SharePoint link. The victim clicks through to the genuine Microsoft device login page, enters the code, and signs in with their own credentials and their own MFA. Nothing about the page is fake. When the victim approves, the identity provider issues access and refresh tokens to the session the attacker started, not to the victim's own browser.

Why it works

The flow was built to solve a real usability problem and never anticipated that the "second device" doing the requesting could belong to someone other than the user. There is no verification that the person approving the code is the same person who will use the resulting tokens, and no visual difference between a legitimate device pairing and an attacker's. The login page, the domain, and the MFA prompt are all authentic, so the phishing tells that user training covers (misspelled domains, fake login forms) simply do not exist here.

The tokens issued are also often long-lived. A refresh token obtained this way can be used well after the interaction ends, and because the sign-in event itself was a normal, successful authentication, it does not stand out from routine device pairings unless a defender is specifically watching for the grant type.

How to detect it

• Sign-ins using the device code grant type from clients or user agents that do not normally use it in your tenant.
• A device-code authentication followed immediately by API activity (mail, files, Graph calls) from an IP or ASN unrelated to the user's usual pattern.
• A spike in device-code grants clustered in a short window across otherwise unrelated users, which suggests a lure sent to many targets at once.

Be honest about the limits: some organizations legitimately use device code flow for shared kiosks, meeting-room hardware, or CLI tools, so a blanket alert on the grant type alone will generate noise. The signal is the combination of an unexpected client plus follow-on activity, not the grant type in isolation.

How to stop it

• Disable the device code flow entirely for tenants that have no input-constrained hardware needing it. Most organizations do not.
• Scope it tightly where it must stay enabled, restricting which applications and identities can request it.
• Require a compliant or managed device in conditional access for token issuance, which a device-code grant approved by the victim on their own device can still satisfy, so pair it with client and location checks.
• Alert specifically on device-code grants rather than relying on generic sign-in anomaly detection, since the grant type itself is the distinguishing signal.
• Move privileged accounts to phishing-resistant MFA, which does not remove this technique on its own but closes the related paths attackers pivot to when device-code flow is locked down.

Seen in the wild

• Kali365 phishes Microsoft's own device login page for durable Microsoft 365 tokens, with ANY.RUN telemetry showing more than 80 public sessions a week
• Three Russian clusters move from password phishing to OAuth token theft, including device-code phishing against Microsoft and WhatsApp accounts

Sources

• MITRE ATT&CK T1528: Steal Application Access Token
• MITRE ATT&CK T1566.002: Phishing: Spearphishing Link
• RFC 8628: OAuth 2.0 Device Authorization Grant