Skip to content
Start with Identity
Join free
SWI-T002 · Authentication

Device code phishing

The victim enters a code on Microsoft's own login page and approves a real prompt. The attacker requested that code from a second device and walks away with access and refresh tokens.

WidespreadHard to detect
First observed: 2019ATT&CK T1528 ↗ATT&CK T1566.002 ↗

How it works

OAuth's device code flow, the device authorization grant in RFC 8628, exists for input-constrained hardware: a smart TV, a console, or a command-line tool that cannot easily host a browser login. The protocol has three steps.

  1. The device sends its client ID to the authorization server's device authorization endpoint and receives a device_code, a short human-readable user_code, a verification_uri, an expiry and a polling interval.
  2. The device shows the user code and URL. The user opens that URL on a phone or laptop, signs in with their normal credentials and MFA, and types the code.
  3. Meanwhile the device polls the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:device_code. It gets authorization_pending until the user finishes, then receives an access token and usually a refresh token.

The design deliberately separates the device requesting access from the device approving it. An attacker starts the flow themselves, from their own machine, using the client ID of a legitimate public client such as Microsoft Office or the Microsoft Authentication Broker. They get a real code from the real identity provider and send it to the victim in a lure: a Teams or Signal meeting invite, a document share, a "secure chat" request. The victim opens the genuine sign-in page (for Microsoft, microsoft.com/devicelogin), enters the code, and signs in with their own credentials and their own MFA, including a passkey if they have one. Nothing about the page is fake. When the victim approves, the identity provider issues tokens to the polling session the attacker started.

Codes are short-lived. Volexity notes Microsoft device codes are valid for 15 minutes, which is why targeted campaigns pair the code with real-time messaging so the victim acts quickly. Commodity kits such as Kali365 and the more than 25 others Push Security tracks automate the rest. What the attacker does next depends on the client ID they chose. Microsoft reported in February 2025 that Storm-2372 switched to the Microsoft Authentication Broker client ID so its refresh token could request a token for the device registration service, register an attacker-controlled device in Microsoft Entra ID, and obtain a Primary Refresh Token.

The same flow exists outside Microsoft. Christophe Tafani-Dereeper showed in 2021 that AWS IAM Identity Center's device authorization, used by aws sso login, can be phished the same way, and OpenSourceMalware documented a 2026 phish that completed a GitHub OAuth device flow for repo and workflow scopes.

Why it works

RFC 8628 anticipated this. Its Section 5.4, "Remote Phishing", warns that the flow can be initiated on a device in an attacker's possession and recommends that the authorization server tell the user they are authorizing a device and confirm it is in their possession. That confirmation is a sentence on a screen, and the control assumption that fails is that a user will read it and understand it. A user who was told to "enter this code to join the meeting" has no reason to think about which device is on the other end.

There is no binding between the person approving the code and the device that receives the tokens. The login page, the domain, the TLS certificate and the MFA prompt are all authentic, so the phishing tells that training covers (misspelled domains, fake login forms) do not exist. Phishing-resistant MFA does not help either, because the origin check passes: the victim really is on the identity provider's own page. The fraud is in the grant, not the authentication. The tokens issued are also long-lived. A refresh token obtained this way keeps working after the interaction ends, survives a password reset unless sessions are revoked, and comes from a sign-in that looks like a routine device pairing.

How to detect it

  • Entra sign-in logs. Device code sign-ins carry AuthenticationProtocol = deviceCode in SigninLogs. Follow-on token requests in the same session carry the original transfer method (OriginalTransferMethod, value deviceCodeFlow in Microsoft Graph), so you can trace a device-code session into AADNonInteractiveUserSignInLogs. Build a baseline of which users, AppId values and locations legitimately use the flow, then alert on everything outside it.
  • Location mismatch inside one sign-in. The victim authenticates from their usual IP, but the polling client, and every subsequent token redemption, comes from an unrelated IPAddress or AutonomousSystemNumber, often a hosting provider or a regionally matched proxy.
  • Persistence after the grant. A "Register device" event in Entra audit logs, or new security info registered, shortly after a device-code sign-in. Huntress found 48 rogue Entra devices named DESKTOP- plus eight hex characters in its 2026 replay campaign.
  • Mailbox and Graph activity. Keyword searches and bulk mail access through Microsoft Graph from the new session, and new inbox rules.
  • Bursts across users. A cluster of device-code grants across otherwise unrelated users in a short window suggests one lure sent to many targets.

Be honest about the limits: some organizations legitimately use device code flow for meeting-room hardware, shared kiosks, and CLI tools such as the Azure CLI, so a blanket alert on the protocol alone is noisy. Attackers choose common first-party client IDs precisely so the app name looks normal. The useful signal is the combination of an unexpected user or location with follow-on activity, not the grant type in isolation, and by the time that combination appears the tokens have already been issued.

How to stop it

  • Block the device code flow with a Conditional Access authentication flows policy. Microsoft describes device code flow as a high-risk authentication method and recommends blocking it wherever possible. Most organizations have no devices that need it.
  • Scope it tightly where it must stay. Allow it only for named users, specific apps, or managed devices in specific network locations, and review the exception list.
  • Revoke and clean up after any suspected grant. Revoke sessions and refresh tokens with revokeSignInSessions, then separately delete unrecognized devices and MFA methods, since neither is removed by a password reset.
  • Require step-up for device registration and MFA changes, so a phished refresh token cannot be converted into a registered device and a Primary Refresh Token.
  • Bind tokens to devices with Entra Token Protection where supported, so tokens issued to an unregistered attacker machine are refused by protected resources.
  • Teach the specific lure. No legitimate meeting or document requires typing a code into microsoft.com/devicelogin. Phishing-resistant MFA is still worth deploying because it closes the AiTM path attackers pivot to when this flow is blocked, but it does not stop this technique on its own.

Seen in the wild

Device-code phishing fits the Identity Breach Report 2026 definition of a talk-past attack: the victim approves access, so authentication is satisfied rather than broken. The report's talk-past share of human-account breaches rose to 38.2% in 2025-2026, from 23.3% in 2023-2024, and its tenth control, governing OAuth apps and user consent, points to this technique.

Sources

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.