A sales contact finished every step Microsoft asked for, including MFA, on the real sign-in page. Seconds later, someone else held the OAuth access and refresh tokens, registered devices under that identity, and started reading mail. According to eSentire TRU on 15 September 2026, the GhostCode device-code phishing campaign never needed a stolen password or a captured one-time code. Attackers controlled the OAuth 2.0 device authorization grant, fed the victim a user code, and collected the tokens the legitimate authentication produced.
Public reporting does not name a specific victim organization. What eSentire TRU documented is the kit, the lure chain, and the post-auth abuse pattern against Microsoft accounts in a late-August 2026 wave.
The social engineering started upstream of any login box. Actors posed as a BJ's Wholesale Club procurement contact. BJ's was the impersonated brand, not a disclosed breach victim. Outreach hit a sales team through a Salesforce form, then moved to a WeTransfer link. That link delivered a password-gated HTML lure. The page was built for evasion: junk padding, character-level comments, and an AES-256-GCM encrypted redirect derived from the password the victim typed into the lure. Residential proxies and geo-matching kept the path looking local. Compromised legitimate sites hosted phishing subdomains. In August 2026, operators registered more than 30 lookalike domains aimed at US distributors, manufacturers, and warehousing brands. One example eSentire cited was bjssourcing[.]com, registered 17 August 2026.
None of that HTML needed to capture a password for Microsoft. The payload’s job was to put the victim into a device-code ceremony the attackers already owned.
An OAuth 2.0 device authorization grant is the flow meant for input-constrained devices. One side starts the grant and polls for tokens. The other side shows the user a short code and sends them to Microsoft’s legitimate sign-in experience to enter that code and authenticate. GhostCode abused that split. The kit initiated the grant (reporting ties the client path to the Microsoft Authentication Broker device-code flow), showed or supplied the user code, and kept polling. The victim opened Microsoft’s real sign-in page, entered the attacker-supplied user code, and completed full authentication, including MFA.
eSentire TRU put the mechanism cleanly: "Device code phishing kits abuse the OAuth 2.0 device authorization grant flow to gain access to Microsoft accounts." After sign-in and MFA, "the threat actors obtained authentication tokens and delivered a decoy NDA document." The password stayed with the user. The OTP or push, whatever factor the account used, succeeded for a real ceremony. Public reporting does not establish which MFA method the victim used, and after a successful grant it barely matters. The asset that moved was the token pair issued to the polling client the attackers controlled.
| Stage | What the victim did | What the attackers held |
|---|---|---|
| Lure | Opened WeTransfer HTML, entered lure password | Redirect into device-code UX |
| Code entry | Typed attacker user code on real Microsoft page | Active device-grant session |
| MFA | Completed legitimate MFA | Still only the grant they started |
| After success | Saw decoy BJ's NDA PDF | Access token, refresh token |
That is not credential replay at a fake password form. It is authorization of someone else’s device grant on the real IdP.
What the attackers did with tokens in the first seconds
Timing is the tell. According to eSentire TRU, once tokens arrived, operators moved within seconds. They registered several devices under the victim’s identity, acquired longer-lived tokens, and harvested email. The decoy BJ's NDA PDF closed the social story so the victim had a document to explain the whole dance.
Bearer access tokens and refresh tokens are post-authentication proof. Mail APIs and device registration endpoints accept them without asking the human to approve another prompt. Device registration in particular turns a short window into durable foothold material: new device identities and longer-lived tokens under the same user. From there, mailbox read is ordinary API use with stolen credentials of a different kind, tokens rather than passwords.
Standard MFA does not sit on that path. MFA already ran. It succeeded. The IdP issued tokens to the client that completed the device grant. No second factor challenge fires when an attacker presents a valid access token to Graph or registers a device with a fresh refresh token. Revocation, continuous access evaluation, anomaly detection on impossible travel or sudden device joins, and aggressive refresh-token lifetime policy are containment problems. They are not the same control as "did the user type an OTP."
Public reporting does not establish how many mailboxes were read, how long access lasted, or whether any ransom followed. The documented outcome class is clear enough: OAuth access and refresh tokens obtained, attacker-controlled device registration, long-lived tokens, email harvest, decoy NDA delivered.
Compare that to the failure modes people usually rehearse after a Microsoft-themed phishing wave. There was no reverse-proxy AiTM page stealing a password and a live OTP in parallel. There was no SIM swap. There was no MFA prompt spam until someone approved a ghost login on a laptop they were not using. GhostCode’s path is colder. The login UI was genuine. The MFA result was genuine. The binding was wrong: the human authorized a grant the attacker initiated and polled.
Why MFA success did not protect the mailbox
Security reviews still ask whether "MFA would have helped." For GhostCode, the honest answer splits by phase, and every phase in public reporting is token abuse after authentication.
Initial access stole tokens, not a password database and not an OTP seed. The victim’s interactive authentication completed on Microsoft’s real page. The attackers’ win condition was possession of the device-code grant’s issued access and refresh tokens. Persistence was device registration and longer-lived tokens using those same secrets. Data access was email harvest with bearer tokens. In each phase, authentication had already happened. There was no login left for a stronger second factor to interrupt.
That is why naming this "MFA failure" in the casual sense misleads operators. The factor did its job inside the ceremony Microsoft presented. The protocol feature under abuse was device authorization coupled to a human who had been coached to enter a code. Any MFA method that only gates interactive sign-in leaves the post-issuance token story untouched. Public reporting does not claim the campaign disabled device-code flows tenant-wide or that a default MFA upgrade turns the grant off. Those are separate conditional-access and application-governance decisions.
Defenders who only hunt for password-spraying or obvious fake login domains will under-weight this kit class. The domains and WeTransfer stage still matter for early detection. The decisive artifact after click-through is device-code initiation plus a user who is willing to complete microsoft.com device login for a procurement story. Token use within seconds, sudden device registration, and mail access from odd infrastructure (residential proxy pools showed up in the reporting) are the post-auth signals.
Closing phishable password and OTP paths still matters for the large set of attacks that steal transferable secrets before a session exists. GhostCode is the other branch: the session material is born already in the wrong hands because the grant was theirs from the first poll. Fooling a user into finishing a real sign-in for an attacker-owned device code is one problem. Planting malware on a machine that already holds a legitimate session is another. GhostCode lived in the first problem’s token-shaped outcome.
If you want to skip the attack details and go straight to what can and cannot stop this class of OAuth device-code token theft, read the related article on mfa2point0.com: why MFA does not undo OAuth tokens after a successful device-code sign-in.
FAQ
Did GhostCode steal the victim’s Microsoft password or MFA code?
No. According to eSentire TRU’s GhostCode analysis, no password or OTP needed to be stolen. The victim entered an attacker-supplied device code on Microsoft’s legitimate sign-in page, completed real MFA, and the attackers collected the OAuth access and refresh tokens issued to the device-authorization grant they were already polling.
Was BJ's Wholesale Club the breached company in the GhostCode campaign?
Public reporting does not establish BJ's Wholesale Club as a breached organization in this campaign. eSentire TRU described actors posing as BJ's procurement via a Salesforce form and a decoy BJ's NDA PDF. BJ's was the impersonated brand in the lure, not a named victim tenant.
Why didn’t finishing MFA stop GhostCode from reading email?
Finishing MFA authenticated the user for the OAuth 2.0 device authorization grant. GhostCode’s operators controlled initiation and polling for that grant, so the tokens landed with them. Mailbox harvest used those bearer tokens after authentication. MFA does not re-challenge every API call once a valid access token is presented, and it cannot revoke tokens it already helped issue to the attacker’s client.
How fast did post-login abuse start in the GhostCode kit?
According to eSentire TRU, after the victim signed in and completed MFA, threat actors obtained authentication tokens and, in the same operational breath, registered several devices, acquired long-living tokens, harvested emails, and delivered a decoy NDA. Token use began within seconds of issuance.
Is device-code phishing the same as AiTM cookie theft on a fake login page?
Not in the way GhostCode was documented. AiTM kits proxy a fake or mirrored login and steal secrets or cookies during a phished ceremony. GhostCode abused the legitimate device authorization grant: the Microsoft sign-in page was real, MFA succeeded for real, and the wrong party held the polling side that received the OAuth token pair. Both end in usable session material. The path to that material differs.
