sysop@hub:~/explainers/device-code-phishing-explained$

device-code-phishing-explained

How device code phishing gets tokens past MFA

The attacker starts a sign-in for a device without a keyboard and lets the victim finish it on the real Microsoft page. No fake website is involved.

Read the steps as text

Requests a device code. The attacker's script asks Entra ID to start a device sign-in for a well-known Microsoft app. Entra ID answers with a short user code and a hidden device code. Both are valid for about 15 minutes.
Sends the lure. The victim gets a message by mail, Teams or a messenger: a meeting invitation or a document, with the instruction to open microsoft.com/devicelogin and enter the code.
Enters the code on the real page. The victim opens the genuine Microsoft address and types the code. The address bar is correct, the certificate is correct, there is nothing to spot.
Sign-in and MFA. Entra ID asks the victim to sign in. Password, authenticator prompt, even a passkey: everything is real and everything succeeds. The page names the app, not the person who started the request.
Asks whether the code was used. Meanwhile the attacker's script asks the token endpoint every few seconds, using the hidden device code.
Tokens issued. As soon as the victim has finished, Entra ID hands an access token and a refresh token for the victim's account to whoever holds the device code. This is the moment the attacker wins. The sign-in happened on the real site, so phishing-resistant MFA did not help. The refresh token keeps working for weeks.
Reads mail and files. The attacker uses the tokens against Exchange, SharePoint and Graph, and trades the refresh token for tokens to other services. A password reset alone does not end this.

How to defend

Block the device code flow with Conditional Access: under Conditions, Authentication flows, select Device code flow and block it for all users. Most organisations never use it.
If something needs it, such as meeting room devices or a command-line tool on a server, allow it only for those accounts and from your own locations.
A policy that requires a compliant or hybrid joined device also stops the attack, because this flow carries no device identity.
Teach one rule: never enter a code that someone else sent you. A real device code is shown on a device you are holding.
Hunt for it: in the sign-in logs the authentication protocol is "deviceCode". Any hit for a normal office user deserves a look.
If it happened: revoke the user's sessions, then reset the password, then review what the mailbox did. Revoking is the step that kills the refresh token.

Find it in the sign-in logs (KQL)

SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, ResultType
| order by TimeGenerated desc

Why this works when AiTM phishing does not

	AiTM phishing	Device code phishing
Where the victim signs in	On a look-alike site that relays to Microsoft	On the real Microsoft page
What the attacker gets	The session cookie	Access and refresh tokens
Stopped by passkeys and FIDO2	Yes, the key refuses the wrong domain	No, the domain is right
Stopped by requiring a compliant device	Yes	Yes
Most direct defence	Phishing-resistant MFA	Block the device code flow