Nobody stole a password hash. Nobody proxied a fake login page. According to Anthropic’s September 2026 threat-intelligence report, GTG-20006 (linked to Midnight Blizzard) 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 entered an attacker-supplied device code on real login.microsoftonline.com, completed their own Entra/Microsoft 365 sign-in including MFA, and the IdP issued access and refresh tokens straight to the attacker-controlled client. Operators then bulk-exported mailboxes from at least eight organizations and kept cloud-email access that survived password resets until tokens were explicitly revoked.
How a real Microsoft sign-in still fed the wrong client
Device-code phishing abuses a legitimate OAuth pattern meant for input-constrained devices. The attacker starts an OAuth device-authorization request and gets a user code plus a verification URI. Social engineering does the rest: a helpdesk-style message, a “secure viewer” story, or another live coach pushes the victim to open the real Microsoft verification page and type that code.
The critical detail is where authentication happens. The password prompt and the MFA challenge run on genuine Microsoft infrastructure for the victim’s tenant. Whatever second factor that tenant required (push, TOTP, SMS, or something stronger) can succeed exactly as designed. Public reporting does not enumerate MFA methods per tenant. It does establish that MFA completion on the real IdP was not the barrier the operators needed to clear.
After that ceremony, Microsoft issues tokens to the OAuth client that started the device-code request. That client is the attacker’s. The victim never pastes a password into a lookalike domain. There is no AiTM reverse proxy in the middle of this path. The grant itself binds a finished, MFA-complete session to hardware and software the user does not control.
Anthropic’s disclosure states the actor kept developing a cloud email espionage platform that in part used “Embassy Kit,” the framework for managing device-code phishing and the Microsoft 365 token theft campaign. That is industrial process, not a one-off trick: code issuance, coaching, token harvest, then mailbox work at scale.
| Control surface | What reporting shows here | Why it did not stop token issue |
|---|---|---|
| Password at real IdP | Victim authenticated legitimately | Password was never the stolen object |
| MFA at real IdP | MFA completed for the victim | Tokens still went to attacker client |
| OAuth device-code grant | Left available for targeted users | Grant authorized the wrong party’s app |
| Password reset later | Access continued until revoke | Refresh tokens outlived the password |
Public reporting does not establish exact victim ministry or embassy names, full mailbox inventories, or complete OAuth access and refresh token lifetime values. It does establish the shape of the failure: authorization to the attacker client after a successful human login.
What stolen OAuth tokens unlocked without another login
Once access and refresh tokens sat with GTG-20006, interactive MFA was already in the past. Mailbox Graph and export APIs accept bearer tokens. No fresh push prompt appears because the caller is not starting a new interactive sign-in. Bulk Microsoft 365 mailbox export against at least eight organizations is the documented payoff for this path.
Persistence followed the same logic. Password resets change the secret used at the next interactive login. They do not, by themselves, invalidate every refresh token already minted to an attacker OAuth client. Operators retained cloud-email access until defenders explicitly revoked those tokens and shut down the abusive grant path. That is why “we reset the password” is a weak closing move after device-code abuse: the skeleton key is the token set, not the password string.
SSO blast radius makes the same tokens worse. A Microsoft 365 cloud session is not “just email” in a federated estate. Mail is the reported collection target here, but the identity plane that issued those tokens is the same 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 idea the moment a replayable cloud token exists outside the intended device.
This is not the same initial-access story as an Evilginx-style reverse proxy that steals cookies mid-login, and it is not helpdesk TAP re-enrollment. Related M365 session theft on this site, including BigBear 2.0’s Evilginx2 cookie harvest, still hinged on completing or capturing a login ceremony through a hostile path. GTG-20006’s device-code path completed the ceremony on the real origin and simply mis-bound the resulting tokens.
Adjacent GTG-20006 activity is not the same login failure
Anthropic’s September 2026 report places device-code phishing inside a wider GTG-20006 portfolio through August 2026, with AI-assisted operational automation around the edges. Two neighboring threads matter for defenders who only skim headlines.
CaptiveCrunch-style hotel Wi-Fi DNS hijacking, publicly described by Microsoft Threat Intelligence in July 2026 and tied into the same actor reporting wave, abused compromised hospitality vendor admin credentials to hijack guest DNS, inspect traffic, and stage ClickFix-style malware lures against Ukraine-linked travelers. That is network and endpoint delivery. It is not the Microsoft 365 device-code token mechanism.
Separately, the same actor stole VPN appliance credentials, took over a North African government technology authority’s central account server, and exfiltrated more than 300,000 national identity records plus commercial registry data for more than half a million companies. That is credential-database theft after appliance access. It is not OAuth device-code phishing against Entra users.
Treat those as same-actor context, not as proof that every GTG-20006 mailbox came from hotel DNS or a national ID dump. The workforce identity failure that minted M365 OAuth tokens was the device-authorization grant plus social engineering on the real sign-in page.
Defenders who want a control that actually matches this path should start with Conditional Access policies that block the device-code flow for almost everyone, tight OAuth app consent governance, rapid token revocation playbooks, and continuous access evaluation. Those are authorization and session-hygiene moves. They are not “run MFA again” moves. Authentication already succeeded for the wrong party’s client.
If you want the prevention-side reading on why post-auth OAuth token possession is outside what phishing-proof login cryptography can undo, and what device-code blocks address instead, read the related article on mfa2point0.com: Why MFA 2.0 does not undo M365 device-code OAuth theft.
FAQ
Did Midnight Blizzard steal passwords or MFA codes in the GTG-20006 Microsoft 365 campaign?
No. In the GTG-20006 Midnight Blizzard device-code campaign described by Anthropic, victims completed legitimate authentication including MFA on real Microsoft sign-in infrastructure. Attackers did not need primary password or OTP theft. They needed the victim to enter an attacker-supplied device code so OAuth access and refresh tokens issued to the attacker-controlled client.
Why didn’t Entra MFA stop GTG-20006’s mailbox access?
Entra MFA did not stop GTG-20006 mailbox access because MFA had already succeeded on the legitimate IdP before tokens were issued to the wrong OAuth client. Later MFA prompts do not invalidate bearer tokens already held by that client. Mailbox export APIs accepted the stolen tokens without a fresh interactive login.
How many organizations did GTG-20006 hit with device-code phishing?
According to Anthropic’s September 2026 threat-intelligence report, GTG-20006 targeted more than 20 distinct organizations (government, defense, embassy, and think-tank focus, primarily Ukraine and Europe). Bulk Microsoft 365 mailbox exports are documented against at least eight organizations. Public reporting does not establish a full named victim list or a total mailbox count beyond those floors.
Would resetting passwords have kicked GTG-20006 out of Microsoft 365?
Password resets alone would not reliably have removed GTG-20006 from Microsoft 365 after device-code token theft. Anthropic’s reporting describes persistent cloud-email access via stolen OAuth tokens that survived password resets until tokens were explicitly revoked. Defenders needed token revoke, device-code flow restrictions, and app/session hygiene, not only a new password.
Is CaptiveCrunch hotel DNS hijacking the same attack as the M365 device-code path?
No. CaptiveCrunch hotel Wi-Fi DNS hijacking is adjacent GTG-20006 activity in the same Anthropic reporting wave and Microsoft’s July 2026 naming of the hotel method. It relies on compromised hospitality admin credentials, DNS hijack, guest traffic capture, and malware staging. It is a different initial-access path from OAuth device-authorization grant phishing that issues Microsoft 365 tokens after a real Entra sign-in.
