I'm curious. Victims typed an attacker device code on real login.microsoftonline.com, finished MFA, and GTG-20006 still walked away with the mailbox tokens.
According to Anthropic's September 2026 threat-intelligence report, GTG-20006 socially engineered workforce users at more than 20 government, defense, embassy, and think-tank targets into the legitimate OAuth 2.0 device-authorization grant. Victims typed an attacker-supplied device code on real login.microsoftonline.com, completed their own Microsoft 365 authentication including MFA, and access plus refresh tokens issued straight to the attacker-controlled client. Operators then bulk-exported mailboxes from at least eight organizations.
Phishing-proof MFA 2.0 does not undo tokens already minted after that ceremony. The controls that match this path are device-code blocks, token revoke, and shrinking classic SSO blast radius. Login cryptography is the wrong primary fix once the grant already bound a finished session to the wrong client.
Why a completed Entra sign-in still fed the wrong OAuth client
Public reporting frames this as cloud-email espionage, not password-database theft. Anthropic states attribution is consistent with public reporting linking the actor to Midnight Blizzard, and that the actor kept developing a cloud email espionage platform that in part used "Embassy Kit," its framework for managing device-code phishing and the Microsoft 365 token theft campaign. The identity event is narrow and ugly: social engineering pushed a user to open Microsoft's real verification page, enter the attacker's user code, and finish the tenant's normal sign-in.
No reverse proxy sat between the victim and the IdP on this path. No primary password or OTP had to be captured off a lookalike form. The password prompt and the MFA challenge ran on genuine Microsoft infrastructure for the victim's tenant. Public reporting does not enumerate MFA methods per tenant. It does establish that MFA completion on the real IdP was not the barrier operators needed to clear. After the ceremony, Microsoft issued tokens to the OAuth client that started the device-code request. That client belonged to the attacker.
Initial access stole tokens, not a reusable password secret from a phished form. The victim authenticated successfully, including whatever second factor the tenant required, on the legitimate IdP. The failure surface was the OAuth 2.0 device-authorization grant left available to targeted users, plus live coaching that bound a completed human session to an attacker-controlled client. Calling the outcome an "MFA bypass" misstates the sequence. Authentication had already happened for the wrong party's app.
Persistence stayed in token space. Stolen access and refresh tokens powered ongoing Microsoft 365 mail access managed in part through Embassy Kit. Password resets change the secret used at the next interactive login. They do not, by themselves, invalidate every refresh token already issued to an attacker OAuth client. Operators retained access until tokens were explicitly revoked and the abusive grant path was shut down.
Data access used the same bearer tokens against mailbox and Graph-style export paths. Bulk export against at least eight organizations required no fresh interactive MFA prompt, because the caller was not starting a new human sign-in. Accepted OAuth tokens authorized the APIs. No login control that only sits on interactive authentication gates API calls that already hold a valid bearer token.
| Phase | What was abused | Did another MFA prompt stop it? |
|---|---|---|
| Initial access | Device-code grant after real sign-in | No; MFA had already succeeded |
| Persistence | Access and refresh token possession | No; tokens outlived password resets |
| Mail export | Bearer token to mailbox APIs | No; APIs trusted the token holder |
Documented impact stays within what Anthropic published. More than 20 distinct organizations were targeted, with a Ukraine and Europe focus across government, defense, embassy, and think-tank environments. Bulk mailbox exports hit at least eight organizations. Public reporting does not establish exact victim ministry or embassy names, full mailbox inventories, or complete OAuth access and refresh token lifetime values.
SSO and federation amplify the same mistake. A Microsoft 365 cloud session is rarely "just email" in a federated estate. Mail was the reported collection target here, but the identity plane that issued those tokens is the plane many agencies wire to files, chat, and line-of-business apps. One successful device-code ceremony can become multi-app reach without a second human login. Classic SSO auto-login fails the never-trust, always-verify requirement the moment a replayable cloud token exists outside the intended device.
This is also not the same story as Evilginx-style cookie harvest mid-login. An adversary-in-the-middle kit that completes a proxied login is still a credential-phase failure at a hostile origin. GTG-20006 completed the ceremony on the real origin and mis-bound the resulting tokens. Different mechanism. Same painful outcome class: attacker-held cloud session material.
Adjacent GTG-20006 threads in the same disclosure are not this login failure. CaptiveCrunch-style hotel Wi-Fi DNS hijacking, named by Microsoft Threat Intelligence in July 2026 and tied into the same actor wave, abused hospitality admin credentials and guest DNS. A separate North African government technology authority intrusion used VPN appliance credentials and exfiltrated more than 300,000 national identity records plus commercial registry data for more than half a million companies. Same actor portfolio. Different initial-access mechanics than Microsoft 365 device-code OAuth token phishing.
If you want the full attack-chain narrative, read the related post on legacymfa.sucks: how Midnight Blizzard device-code phishing stole M365 OAuth tokens after real Entra MFA.
What phishing-proof MFA changes on this path (and what it does not)
MFA 2.0 is phishing-proof across registration, device onboarding, authorisation, authentication, and decommissioning when no phishable factor exists at any stage. That full-lifecycle design stops remote kits that need a transferable secret or a coached fake origin. It does not reach into an OAuth token store and erase access and refresh tokens that Microsoft already issued to an attacker client after a legitimate, MFA-complete sign-in on real infrastructure. For GTG-20006's device-code path, login cryptography is not the control that undoes issuance after the fact.
What does change the defender's position is matching the actual failure surface. Entra Conditional Access policies that block the device-code flow for almost everyone remove the grant path operators abused. Tight OAuth app consent governance reduces who can start hostile device-authorization requests that users will be coached to finish. Rapid token revocation playbooks and continuous access evaluation treat stolen bearer material as the incident object, not the user's password string. Anthropic's reporting and the intake facts both point at device-code restriction as the cited primary control for this technique.
Prevention still beats late revoke when you can choose architecture up front. Closing a phishable interactive login stops AiTM-class harvest before a session exists. Device-code abuse is adjacent but not identical: the interactive login is real, and the mis-binding is the OAuth client. The prevention claim here is "do not leave device-code available to the workforce population attackers coach," not "a stronger second factor would have refused tokens after success." Fooling a user into finishing a real grant is still social engineering. It is not the same leftover problem as planting malware on an already-logged-in PC, and it is not solved by asking interactive MFA to invalidate tokens it never gated.
When cloud SSO multiplies blast radius, prefer per-app proof over one shared federation cookie. Secure Explicit Sign-On keeps the one-tap user experience while authenticating each application with its own fresh, device-bound signature so no single replayable SSO token becomes a skeleton key across mail, files, and chat. That is an authorization-architecture answer for federated estates that already learned how far one M365 token set can travel. Pair it with prevention rather than detection as the design goal for interactive identity, and keep revoke as mandatory hygiene once any bearer token may be attacker-held.
Phishing-proof device-bound credentials harden human authentication ceremonies. They do not claim to stop every post-authentication API call authenticated by tokens already issued through a legitimate protocol path defenders left enabled.
Passkeys harden login; device-code still mis-binds the client
Passkeys and FIDO2 are phishing-resistant at the login act. A device-held key pair signs an origin-bound challenge; the private key never leaves hardware, and a lookalike domain cannot complete that signature. On a generic enterprise IdP that offers only hardware-bound signatures, that hardens the interactive ceremony attackers usually try to proxy or relay. Device-code phishing in this campaign did not need a hostile origin. The victim finished a real-origin ceremony, which can include a passkey assertion, and the OAuth client that received tokens was still the attacker's. Phishing-resistant login helps against fake pages. It does not rewrite which OAuth client is entitled to tokens after a successful real sign-in if device-code remains allowed.
FIDO2 and passkeys remain phishing-resistant at login only; enrollment, recovery, and helpdesk re-onboarding can still reintroduce OTPs, magic links, or temporary secrets unless policy forbids that. Full-lifecycle phishing-proof coverage closes those stages when no phishable factor appears anywhere. GTG-20006's documented Microsoft 365 path did not turn on helpdesk TAP handoff or attacker-driven re-enrollment as the initial access story. Public reporting centers the device-authorization grant after users completed existing tenant authentication. Closing enrollment gaps still matters for other Midnight Blizzard-class playbooks. It is not the primary lever against tokens already issued through device-code to an attacker client.
Key Takeaways for Defenders
- Block OAuth device-code flow in Entra Conditional Access for nearly all users; allow only tightly justified exceptions.
- Treat stolen access and refresh tokens as the incident object: revoke sessions and refresh tokens, do not stop at password reset.
- Govern OAuth app consent and monitor device-authorization starts that do not match known hardware patterns.
- Shrink classic SSO blast radius with per-app, device-bound proof so one M365 token set is not a multi-app skeleton key.
- Keep CaptiveCrunch hotel DNS and separate credential-database theft in the same actor briefing, but do not confuse them with the device-code grant failure.
Map every workforce grant that can mint cloud tokens without the user's enrolled device being the token recipient, then disable the ones you cannot justify. Authentication theater after tokens already exist is not a strategy. Block the grant. Revoke what left. Then decide whether classic SSO still earns its blast radius.
FAQ
Does phishing-resistant MFA stop Microsoft 365 device-code OAuth token phishing like GTG-20006?
No. Phishing-resistant MFA such as FIDO2 or passkeys hardens the interactive login act on the real IdP, and victims in the GTG-20006 Midnight Blizzard campaign still completed legitimate Microsoft sign-in including MFA. Device-code phishing issued access and refresh tokens to the attacker-controlled OAuth client after that success. Stopping this path requires blocking device-code flow, revoking tokens, and tightening OAuth consent, not expecting login MFA to un-issue bearer tokens.
Would MFA 2.0 have prevented Midnight Blizzard from receiving the OAuth tokens?
No. MFA 2.0 is phishing-proof across the identity lifecycle for interactive authentication when no phishable factor exists at any stage, but GTG-20006's tokens were issued after a completed real Entra or Microsoft 365 sign-in to the wrong OAuth client. Phishing-proof login cryptography does not undo post-authentication token possession. Conditional Access device-code blocks and explicit revoke address the grant and the stolen material.
Why is classic SSO a problem after Microsoft 365 device-code token theft?
Classic SSO is a problem after Microsoft 365 device-code token theft because one stolen access or refresh token can unlock every integrated app that trusts the same cloud session without a fresh human login. That auto-login pattern conflicts with zero trust's never-trust, always-verify requirement. Deployments that use Secure Explicit Sign-On keep one-tap UX while authenticating each app with its own fresh device-bound signature, so no shared federation cookie becomes a multi-app skeleton key.
What should defenders do first after suspected device-code phishing against Entra ID?
Defenders should first revoke OAuth access and refresh tokens for affected accounts and applications, then block device-code flow via Entra Conditional Access for most users. Password resets alone do not reliably end GTG-20006-style cloud-email access. Add consent governance, continuous access evaluation, and hunting for bulk mailbox export behavior while the grant path stays disabled.
How does phishing-proof MFA 2.0 differ from phishing-resistant passkeys on this breach?
MFA 2.0 is phishing-proof across registration, device onboarding, authorisation, authentication, and decommissioning when no phishable factor is used at any stage. Passkeys and FIDO2 are correctly called phishing-resistant for the login act; enrollment and recovery can still reintroduce phishable secrets unless policy forbids that. For GTG-20006, even a phishing-proof interactive login would not have erased tokens already issued through device-code after a real sign-in, which is why grant controls remain mandatory.
