Device code phishing: stealing tokens without a fake login page

Device code phishing is hard to catch because there is nothing fake to catch. The victim signs in on the real Microsoft page, completes real MFA, and still hands the attacker working tokens.

How the attack works

The OAuth device authorization grant exists for input-constrained devices like TVs and CLI tools. The attacker starts a device-code flow and receives a genuine Microsoft user code. They send the victim a real prompt: go to microsoft.com/devicelogin and enter this code. The victim authenticates on the legitimate Microsoft page, MFA included, and the attacker, who is polling the flow, receives the access and refresh tokens. No spoofed domain, no fake login, and MFA is satisfied by the real user. The refresh token gives the attacker persistent access. In ATT&CK terms this maps to T1566 paired with T1528.

Why it evades the usual defenses

Phishing training tells people to check the domain. Here the domain is correct. The login is real. MFA is genuinely completed. The only thing wrong is that the user is entering a code the attacker generated.

How to detect it

Watch the Entra sign-in logs for device-code authentications, especially for users and applications that never legitimately use that flow. A device-code grant for an office worker on a managed laptop is a red flag worth alerting on.

How to shut it down

Block the device code flow with a Conditional Access policy for users and apps that do not need it, which is most of them. Teach users one rule: never enter a sign-in code you did not start yourself. On suspicion, revoke the user’s refresh tokens, because the tokens, not the password, are what the attacker holds. Phishing-resistant MFA raises the bar generally, but the decisive control here is removing the device-code grant where it is not needed.

Practice it

We built a device-code phishing scenario in GraphLattice Range so teams learn to spot the flow in the logs and close it before tokens are abused.