A device-code lure never asks for a password. It asks an employee to copy a short code, paste it into Microsoft's real sign-in page, and finish MFA as usual. That approval authorizes a session the attacker started, and the access and refresh tokens land on the attacker's polling client. Because the login happens on the genuine origin, no MFA product, phishing-proof MFA 2.0 included, can refuse the approval or take the tokens back. The control that stops device-code phishing is blocking the OAuth device code flow in Conditional Access wherever the business does not need it, then revoking tokens and attacker-registered devices fast.
This rolling hub covers the device authorization grant class. Individual cases are listed as one-sentence entries in the Updates section at the bottom of this page. Consent phishing, where a user grants a malicious app standing permissions, is an authorization problem no MFA addresses, and it stays out of this hub. Coached helpdesk resets live on the workforce vishing hub.
Why a genuine Microsoft sign-in still hands over the tokens
The OAuth 2.0 device authorization grant exists for smart TVs, printers, Teams devices, and conferencing devices that cannot run a full browser sign-in, according to Microsoft Threat Intelligence. The device shows a short code. The user enters it in a browser on a separate device and signs in. Microsoft states the tradeoff plainly: because authentication finishes on a separate device, the session that started the request is not strongly bound to the user's original context.
Device-code phishing puts the attacker in the device's seat. eSentire TRU watched GhostCode's server request a code from Microsoft under the Microsoft Authentication Broker app ID, inject the user code into a lure page, and poll for completion. The victim entered the code on the legitimate page and completed the normal sign-in, including MFA. Token use began five seconds later.
Push, TOTP, and SMS did what they were built to do here. They confirmed a real person on the real origin. The weak point was never the factor. It was a still-enabled grant that let one party approve a session another party would receive. eSentire's verdict is blunt: "MFA does not protect against device code phishing. The token carries the MFA claim forward." All nine of the attacker's follow-on sign-in events passed MFA checks without re-authentication. Microsoft adds that a user who is already signed in only pastes the code and confirms, which instantly authenticates the attacker's session.
| What the attacker held | Where it came from | Could another MFA prompt stop it? |
|---|---|---|
| Device code and polling client | Requested from Microsoft by the kit | No; no user involved yet |
| Access and refresh tokens | Issued after a real sign-in | No; MFA already succeeded |
| Registered devices, PRT | Registration calls with the token | No; non-interactive |
| Mailbox and Graph access | Bearer tokens against APIs | No; no login to gate |
This is the line between device-code phishing and AiTM. An AiTM kit finishes the login on a hostile origin, which origin-bound signatures refuse, as the AiTM hub covers. A device-code lure sends the employee to the right origin on purpose. Public reporting does not establish which MFA methods GTG-20006's targets used, and it does not need to. The method approved a genuine ceremony either way.
Shorter token lifetime does not prevent the first approval, and it does not undo what the attacker built while the token was live. eSentire notes that Intune enrollment outlives token revocation. Microsoft observed some EvilTokens operators registering new devices within 10 minutes to generate a Primary Refresh Token.
What closes the device-code path, and what phishing-proof MFA adds
Microsoft recommends blocking device code flow wherever possible and, where Teams devices need it, scoping the exception to specific Teams device resource accounts. eSentire recommends a Conditional Access policy that blocks device code authentication for all users except genuine needs such as specific Azure DevOps service accounts and IoT provisioning workflows. According to eSecurity Planet, Microsoft Security Defaults have blocked device-code flow for new Entra tenants since 1 July 2026. That default covers new tenants, so older tenants should confirm their own policy.
Containment after an approval has to go beyond the password. Microsoft says standard session revocation often invalidates only refresh tokens, leaving access tokens active for up to an hour, and hands-on operators use that window. Its advice is to temporarily disable the compromised account. Disable attacker-registered devices too: Microsoft notes that disabling the device stops PRTs from working, and eSentire's responders disabled all three GhostCode devices.
Phishing-proof MFA 2.0 removes phishable factors at registration, device onboarding, authorisation, authentication, and decommissioning. It does not decide which client receives tokens from a grant the tenant still allows, and it cannot retract tokens after a real approval. Two parts of the design still shrink the aftermath.
First, the enrollment gap. Passkeys and FIDO2 are phishing-resistant at login, and on a device-code lure the passkey still signs, because the origin is real. None of the cases on this hub documents an attacker adding an authenticator; the persistence on record is device registration, a Primary Refresh Token, and Intune enrollment. Where adding an authenticator requires an already-enrolled device, a stolen session cannot add its own factor. Entra device registration with the stolen token is a separate tenant control and needs its own policy.
Second, blast radius. eSentire describes a PRT as single sign-on to any resource in the tenant, persisting for up to 14 days by default. Secure Explicit Sign-On keeps one-tap UX while each application that federates to it receives its own fresh, device-bound signature. That limits what one sign-in reaches across those applications. It does not narrow tokens Entra has already issued for Microsoft 365, which stay valid for the resources they cover until they are revoked. On this path, prevention, not detection means refusing the grant in Conditional Access, because detection only starts after tokens exist.
| Control | Against the approval | Against issued tokens |
|---|---|---|
| Push, TOTP, or SMS | User still approves | No effect |
| Passkeys at login | User still approves | No effect |
| Conditional Access block | Grant refused | Nothing issued |
| Revoke, disable account and devices | Not applicable | Primary containment |
| Locked authenticator enrollment | Not applicable | No durable attacker factor |
| Per-app device-bound sign-on | Not applicable | Smaller reach for federated apps only |
Key takeaways for defenders
- Block the OAuth device code flow in Conditional Access for everyone without a documented need, and inventory the exceptions.
- A stronger factor does not fix this path, because device-code victims finish MFA on Microsoft's real page.
- Treat a suspected approval as a token incident: revoke, temporarily disable the account, and disable every device registered in the window.
- Require an already-enrolled device to add any authenticator, so a stolen session cannot add its own factor.
- Where applications federate to per-app device-bound sign-on, one sign-in does not carry across all of them; tokens Entra already issued still need revocation.
FAQ
Does phishing-proof MFA 2.0 stop device-code phishing?
No. No MFA product stops device-code phishing, phishing-proof designs included, because the victim authenticates on Microsoft's genuine sign-in page and approves a grant the tenant still allows. eSentire's GhostCode investigation and Microsoft's EvilTokens disclosure both describe tokens issued to the attacker's client after a real sign-in. Blocking the device code flow in Conditional Access is what removes the path.
What should security teams configure first against device-code phishing in Microsoft 365?
Security teams should first block the OAuth device code flow in Entra Conditional Access for every user who does not need it. Microsoft recommends blocking it wherever possible and scoping any Teams device exception to specific Teams device resource accounts. eSentire gives specific Azure DevOps service accounts and IoT provisioning workflows as examples of genuine needs. Then rehearse token revocation, account disable, and device cleanup.
Are passkeys enough to stop device-code phishing?
Passkeys are not enough to stop device-code phishing on their own. Passkeys are phishing-resistant at login because signatures are bound to the real origin, and a device-code lure sends the employee to the real Microsoft origin on purpose. eSecurity Planet's guidance on the N0va kit keeps device-code restrictions in place because phishing-resistant authentication alone does not prevent malicious authorization requests.
Why is revoking refresh tokens not enough after a device-code approval?
Revoking refresh tokens is not enough because Microsoft observed that standard session revocation often leaves existing access tokens active for up to an hour, and hands-on EvilTokens operators used that window. Microsoft recommends temporarily disabling the compromised account. Attacker-registered devices also need disabling: eSentire found Intune enrollment outlives token revocation in the GhostCode case.
How is device-code phishing different from AiTM phishing?
Device-code phishing completes the login on Microsoft's real sign-in page, while AiTM phishing completes it on a hostile proxy. Origin-bound, device-bound signatures refuse the AiTM relay. They cannot refuse a device-code approval, because the origin is genuine and the tenant still allows the grant. That is why the fix for device-code phishing is Conditional Access, not a stronger factor.
Updates
2026-09-22: Vendor disruption
Microsoft attributed the EvilTokens device code phishing kit to Storm-2992, counted more than 12,000 compromised inboxes in over 10,000 organizations, and said its Digital Crimes Unit facilitated a coordinated disruption of the service's infrastructure.
Source: Microsoft Security Blog, Unmasking EvilTokens · Full analysis: mfa2point0.com
2026-09-15: Incident response write-up
eSentire TRU documented a GhostCode victim who entered an attacker-supplied code on Microsoft's legitimate sign-in page and completed MFA, after which the attackers registered three devices and obtained a Primary Refresh Token within 78 seconds.
Source: eSentire, GhostCode device code phishing kit · Full analysis: mfa2point0.com
2026-09-11: Kit disclosure
eSecurity Planet reported ANY.RUN's disclosure of the N0va kit, which can obtain access and refresh tokens after victims complete MFA, and noted that Microsoft documented the same weakness in a separate April 2026 campaign.
Source: eSecurity Planet, N0va phishkit targets North America and Europe
2026-09-10: Threat intelligence report
Anthropic reported that GTG-20006, whose attribution it calls consistent with public reporting on Midnight Blizzard, used a device code phishing framework called Embassy Kit in a Microsoft 365 token theft campaign that exfiltrated mail records from at least eight organizations.
Source: Anthropic, Countering misuse of AI: September 2026 · Full analysis: mfa2point0.com
The attack-side companion hub is on legacymfa.sucks: how device-code phishing steals tokens after real MFA.
