Seconds after a clean Microsoft MFA success, the operators already held usable OAuth access and refresh tokens. 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. Victims entered an attacker-supplied user code on Microsoft’s real sign-in page, finished full authentication including MFA, and thereby authorized a device grant the kit was already polling. Mailbox harvest and device registration followed from those bearer tokens, not from a second login challenge.
Public reporting does not name a specific victim organization. Public reporting does not establish affected record counts. The prevention question practitioners actually search is sharper: does MFA stop OAuth device code phishing token theft? For GhostCode, the honest answer is no once the IdP has already issued tokens to the attacker’s client.
What GhostCode actually took after MFA succeeded
GhostCode is a late-August 2026 kit wave documented by eSentire TRU. Actors posed as BJ's Wholesale Club procurement. BJ's was the impersonated brand in the lure, not a disclosed breached tenant. Outreach reached a sales contact through a Salesforce form, then a WeTransfer link to a password-gated HTML lure. That lure used junk padding, character-level comments, and an AES-256-GCM encrypted redirect derived from the lure password. Residential proxies and geo-matching kept the path looking local. In August 2026, operators registered more than 30 lookalike domains aimed at US distributors, manufacturers, and warehousing brands, including bjssourcing[.]com on 17 August 2026.
None of that stage needed to steal a Microsoft password. The payload’s job was to walk the human into an OAuth 2.0 device authorization grant the attackers already owned. eSentire TRU stated the mechanism directly: "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." They then registered several devices, acquired long-living tokens, and harvested emails.
An OAuth 2.0 device authorization grant splits the ceremony. One side starts the grant and polls. The other side shows a short user code and sends the person to the real identity provider to authenticate. GhostCode kept the start-and-poll side. The victim kept the human side on Microsoft’s legitimate page. Reporting ties the client path to the Microsoft Authentication Broker device-code flow. When MFA succeeded, tokens were issued to the polling client, not to a browser session the victim still controlled.
If you want more detailed information about this attack, read the related post on legacymfa.sucks: how GhostCode walked victims through a real Microsoft login.
Why a successful MFA ceremony still left the mailbox open
Judge each phase by the asset that moved, not by a slogan about MFA failure. GhostCode’s public chain is token theft after authentication in every phase eSentire TRU described.
Initial access. The stolen asset was the OAuth access and refresh token pair from the device-code grant. The victim completed full legitimate authentication on the real Microsoft page. No password database was emptied. No OTP seed was copied. Public reporting does not establish which MFA method the account used, and after a successful grant that detail barely matters. The factor approved a real ceremony. The binding was wrong: the human authorized a grant someone else initiated and polled.
Persistence. Within seconds of issuance, operators registered devices under the victim’s identity and acquired longer-lived tokens. That work used already-issued secrets against device registration and token endpoints. No fresh interactive MFA prompt sits on that path when a valid refresh token is presented.
Data access. Email harvest used bearer tokens against mail APIs. Resource servers accept a live access token without asking the human to approve another prompt. The decoy BJ's NDA PDF closed the social story so the victim had a document that explained the dance.
| Phase | Asset taken | Did MFA still have a login to gate? |
|---|---|---|
| Initial access | OAuth access + refresh tokens | No, auth had just completed |
| Persistence | Device joins, longer-lived tokens | No, token replay and registration |
| Data access | Mailbox API reads | No, bearer token access |
This is not reverse-proxy AiTM capture of a password and a live OTP. It is not push fatigue. It is not SIM swap. Calling it MFA failure in the casual sense misleads operators. The second factor did what interactive MFA is built to do inside the page Microsoft presented. Standard MFA cannot revoke or block tokens the IdP already issued to the attacker’s polling session. MFA type after success is irrelevant for that residual problem.
Closing phishable password and OTP paths still stops a large class of attacks that steal transferable secrets before any session exists. GhostCode is the other branch. 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.
What device-bound MFA 2.0 changes, and what it does not
MFA 2.0 is phishing-proof across registration, device onboarding, authorization, authentication, and decommissioning when the attack still depends on a transferable factor. GhostCode’s documented win condition was not a typed secret or a fatigued push. It was possession of tokens issued after a successful legitimate sign-in bound to an attacker-controlled device grant.
Authentication had already completed successfully on the IdP. No redesign of interactive factors, including phishing-proof device-bound keys, revokes or blocks tokens that were already legitimately issued to the attacker’s polling session. Device registration and long-lived token acquisition are post-authentication token abuse. Mailbox read is API access with stolen bearer credentials of a different kind. Claiming a stronger login factor would have stopped GhostCode overclaims the phase public reporting can defend.
What stronger authentication still buys you is narrower and still real. It removes the parallel universe of kits that need a password, OTP, SMS code, or push approval the attacker can relay or social-engineer before any token exists. GhostCode simply did not live in that universe. The residual path after a clean interactive success is grant governance, application control on which clients may use device authorization, rapid revoke of refresh tokens, continuous access evaluation on sudden device joins, and detection of mail access from odd infrastructure such as residential proxy pools.
| Control | Against typed-secret phishing | Against GhostCode-style device grant |
|---|---|---|
| Password + OTP / push | Often defeated in real time | Irrelevant after success |
| Phishing-resistant passkeys at login | Hardens the login act | Still authorizes if user completes device code |
| Phishing-proof full-lifecycle MFA | Removes phishable factors end to end | Does not un-issue tokens already granted |
| Device-code CA + client restrictions | N/A to passwords | Directly shrinks the abused protocol path |
| Refresh revoke + device join alerts | Containment after theft | Required once tokens exist |
Prevention for this class is therefore not a better prompt on the same ceremony. It is refusing to let untrusted device-code clients complete high-value grants, binding proof more tightly to the endpoint the human actually holds, and treating post-issuance token life as a first-class control plane. The prevention model that rejects detection-first MFA still holds for phishable-login breaches. GhostCode forces the complementary sentence: when the login was real and the grant was hostile, revoke and grant policy are the work, not another factor challenge.
Secure Explicit Sign-On is the architectural answer when the blast radius is a shared SSO cookie across many apps. Public reporting does not frame GhostCode as classic multi-app SSO cookie replay from a single federation cookie. The skeleton key here was the OAuth token pair and the devices registered with it. Same operational pain, different protocol seam.
Passkeys and FIDO2 against a real device-code page
Passkeys and FIDO2 are phishing-resistant at the login act: a device-held key pair signs an origin-bound challenge, and the private key never leaves hardware. On a generic enterprise IdP that only accepts those hardware-bound signatures for interactive sign-in, a fake lookalike origin cannot complete the ceremony the way a password form can.
GhostCode did not need a fake Microsoft origin. The sign-in page was real. If the tenant required a passkey and the user still entered the attacker-supplied device code and approved the grant, the IdP would still issue tokens to the polling client that started the device authorization. Phishing-resistant login hardens credential entry. It does not redefine who owns the device-code poller after a successful authorization.
The enrollment gap was not GhostCode’s hinge
FIDO2 and passkeys remain phishing-resistant at login only. Enrollment, recovery, and re-onboarding can still allow phishable fallback secrets unless the deployment forbids that. Full-lifecycle phishing-proof coverage requires that no phishable factor appears at any stage, including enrolment.
Public reporting does not show GhostCode abusing helpdesk TAP issuance, recovery codes, or coached re-enrollment. The hinge was post-auth OAuth token issuance on a legitimate device grant. Tightening enrollment still matters for helpdesk social-engineering paths. It is not the control that unwrites tokens GhostCode already held.
Key takeaways for defenders
- Restrict or condition OAuth 2.0 device authorization grants and high-risk public clients (including broker-style device-code paths) instead of assuming MFA on interactive sign-in covers them.
- Alert on device registration and long-lived token acquisition within seconds of a new interactive success, especially from residential proxy infrastructure.
- Treat refresh-token revoke, continuous access evaluation, and mailbox API anomaly response as mandatory containment for post-auth token theft, not as optional extras.
- Train sales and procurement-facing staff that a "type this code on the real Microsoft page" request is authorization of someone else’s grant, not a harmless document preview.
- Keep phishing-proof authentication for the large set of pre-session secret thefts, and do not market it as a revoke engine for tokens already issued.
The industry keeps asking whether MFA would have helped. GhostCode answers with a phase split. Interactive MFA helped the ceremony complete. It did not choose the client that received the tokens. Authentication design that only celebrates a green MFA tick will keep missing kits that weaponize legitimate grants.
FAQ
Does MFA stop OAuth device code phishing token theft like GhostCode?
No. In the GhostCode campaign documented by eSentire TRU, MFA succeeded on Microsoft’s legitimate sign-in page, and attackers still obtained the OAuth access and refresh tokens for the device authorization grant they controlled. MFA gates interactive authentication. It does not revoke tokens the identity provider has already issued to the attacker’s polling client.
Would MFA 2.0 or passkeys have prevented GhostCode’s mailbox access?
No. Neither MFA 2.0 nor passkeys would undo GhostCode’s post-authentication token theft as eSentire TRU described it. The victim completed a real sign-in, including MFA, and tokens were issued to an attacker-owned device-code grant. Passkeys are phishing-resistant at login; phishing-proof full-lifecycle authentication removes transferable secrets before a session exists. Neither redesign is a token-revoke control once valid access and refresh tokens are already in attacker hands.
Why is GhostCode different from AiTM phishing that steals session cookies on a fake page?
GhostCode abused the legitimate OAuth 2.0 device authorization grant on the real Microsoft sign-in experience. AiTM kits typically proxy or mirror a login to capture secrets or cookies during a phished ceremony. Both can end in usable session material. GhostCode’s path required the victim to authorize an attacker-started grant after real MFA, not to type a password into a hostile origin.
Was BJ's Wholesale Club breached 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 and delivering a decoy BJ's NDA PDF. BJ's was the impersonated brand in the lure chain, not a named victim tenant.
What should security teams control if MFA cannot un-issue GhostCode tokens?
Security teams responding to GhostCode-style OAuth device code phishing should restrict device authorization grants and risky clients, monitor rapid device registration after sign-in, revoke refresh tokens quickly, and hunt mail access from odd proxy infrastructure. Those controls address tokens after issuance. Stronger MFA still matters against pre-session secret theft, but it is not a substitute for grant policy and token hygiene on this vector.
