The user opens a real Microsoft page, usually microsoft.com/devicelogin, types a real code, and finishes MFA. Nothing on that screen looks wrong. The attacker who generated the code then receives the access and refresh tokens. That is device code flow used as phishing, and Conditional Access can block the flow itself.
Why MFA does not catch this
Device code flow exists for TVs, kiosks, and other machines that cannot show a browser. The user authenticates on a second device, and Entra hands tokens to the first one. A phisher just becomes that first device. They send a Teams-looking meeting invite (or a WhatsApp/Signal chat) that includes a code they already requested. The victim types it into the genuine Microsoft prompt.
Microsoft Threat Intelligence documented this at scale as Storm-2372, active since August 2024, targeting governments, NGOs, IT, defense, telecom, health, education, and energy. A July 31, 2026 update reassessed Storm-2372 as an initial-access sub-cluster of Midnight Blizzard. The tokens are standard OAuth. There is no Microsoft code bug here, which is why the page looks legitimate.
In February 2025 the same cluster started using the Microsoft Authentication Broker client ID so the stolen refresh token could register an attacker-controlled device and request a Primary Refresh Token. From there they searched mail via Graph for words like password, admin, credentials, and gov, then exfiltrated the hits. Revoking the password later does not help if the refresh token is still valid.
The policy
Microsoft’s guidance is to get as close as you can to a unilateral block. In Entra ID > Conditional Access > Policies:
Users: all users, exclude break-glass. Target resources: All resources. Conditions > Authentication flows > Configure = Yes > Device code flow. Grant: Block access. Create it in Report-only first. Watch sign-in logs for a week, then flip it On.
Filter Entra sign-in logs with Authentication protocol = Device code to see who still uses the flow. Conference-room Android, some digital signage, and a few older CLI tools are the usual legitimate leftovers. If you must keep it, scope an allow to that device platform and a named network, and block it everywhere else.
Two exclusions that bite
If the policy targets All resources, also exclude Device Registration Service (client ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) unless you have confirmed nobody registers devices with device code. Microsoft started enforcing authentication-flow policies on that resource in September 2024. Skip the exclusion and Autopilot / device join can fail in ways that look unrelated.
Protocol tracking is the other surprise. Once a session starts on device code, later refreshes stay tagged even if the next request is a normal flow. A block can then fire on Exchange or some other app in the same session. Sign-in logs show this as Original transfer method = Device code flow. Error AADSTS530036 means the refresh token is burned for as long as the policy applies to all apps. Delete it; do not keep retrying.
If you already got hit
Call revokeSignInSessions on the user, then force reauthentication with Conditional Access. Look for unexpected device registrations and for Graph mail access that does not match the user’s normal clients. The phish used a real Microsoft login, so mailbox rules and inbox-forwarding checks are still worth doing, but start with the tokens.
This is one policy. Report-only this week, on next week, unless a named kiosk or meeting-room fleet still needs the flow.
