GhostCode Microsoft 365 phishing does not cryptographically break multifactor authentication. Instead, eSentire says the campaign socially engineers a victim into completing Microsoft’s legitimate device-code authorization flow for an attacker-controlled session. Once that authentication succeeds, the resulting token can carry the victim’s authenticated state into attacker activity.
In the incident investigated by eSentire, activity moved extremely quickly. The Threat Response Unit recorded token use within seconds, a Microsoft Graph sign-in using a Primary Refresh Token at 32 seconds after successful device-code authentication, three attacker-controlled device registrations by 77 seconds, and successful Intune enrollment at 78 seconds.
What GhostCode changes for Microsoft 365 defenders
Device-code phishing itself is not new. Microsoft already treats device code flow as a high-risk authentication flow because a victim can be persuaded to enter a code generated by an attacker while still authenticating on a genuine Microsoft page. GhostCode matters because eSentire documented a named active campaign, a detailed automation chain and rapid attacker-device enrollment after the victim authorized the session.
The practical distinction is important: successful MFA does not prove that the authentication request itself was legitimate. If the user enters an attacker-supplied device code and then completes Microsoft’s normal authentication and MFA steps, the attacker can receive tokens associated with that authorized flow.
What happened in the first 78 seconds
eSentire’s timeline is evidence from one investigated compromise, not a universal stopwatch for every GhostCode attempt. In that case, the first malicious token activity appeared five seconds after successful device-code authentication. At 32 seconds, eSentire observed a Microsoft Graph sign-in using a Primary Refresh Token. By 77 seconds, three attacker-controlled devices had been registered. The final Intune enrollment completed one second later.
Those timings show why response cannot depend solely on waiting for a password-change event or obvious interactive login from a suspicious browser. An attacker can move from user authorization to device-registration activity rapidly after the legitimate authentication flow succeeds.
Why the MFA wording needs care
It is reasonable to describe GhostCode as defeating the protection users expect MFA to provide, but it is inaccurate to say the kit mathematically or cryptographically breaks MFA. The authentication challenge is completed successfully by the victim on Microsoft’s service. The weakness being exploited is the authorization context: the user is approving an attacker-controlled device-code request.
That means the defender’s question is not simply whether MFA was satisfied. It is whether the user intended to authorize that specific authentication flow and whether suspicious token, device-registration or enrollment activity followed.
Why token revocation may not be the whole response
In eSentire’s observed response, the compromised token grant was revoked, credentials were reset and the attacker-enrolled devices were disabled. That sequence matters because revoking tokens does not itself remove an unauthorized device object that has already been registered or enrolled.
This should not be generalized into a claim that token revocation never works or that every enrolled attacker device retains a usable session indefinitely. The safer conclusion is that responders should inspect device-registration and enrollment state as part of containment rather than assuming credential reset and token revocation automatically remove every persistence artifact.
What Microsoft recommends for device-code authentication
Microsoft classifies device code flow as a high-risk authentication flow and recommends blocking it wherever it is not required. Organizations that legitimately depend on device-code authentication should first identify that use and then scope exceptions narrowly rather than allowing the flow broadly.
Microsoft’s current guidance also supports using Conditional Access report-only evaluation and sign-in-log filtering to understand existing device-code use before enforcement. That helps administrators distinguish legitimate workflows from unexpected device-code authentication.
What administrators should check now
Look for successful device-code authentication involving users who do not normally require the flow, especially when the authentication follows an unexpected business document, procurement request or other social-engineering pretext.
Review non-interactive token activity and unusual application or Microsoft Graph access following successful device-code authentication. eSentire observed rapid automated activity in the documented GhostCode case.
Review Microsoft Entra device-registration and Intune enrollment events for devices the user or organization does not recognize. The eSentire incident included three attacker-controlled device registrations.
For a confirmed compromise, follow current Microsoft and organizational incident-response guidance for revoking sessions or grants, resetting credentials and disabling or removing unauthorized registered devices as appropriate.
Use current Microsoft Conditional Access guidance to block device-code authentication where it is not required and narrowly define legitimate exceptions.
Confirm that the authentication was expected by the user and organization. GhostCode relies on the victim legitimately completing authentication for the attacker’s device-code session.
What eSentire found about campaign infrastructure
eSentire identified more than 30 lookalike domains matching the campaign pattern. That is evidence of broader infrastructure, but it is not evidence that more than 30 organizations were successfully compromised. Domain counts, victim counts and confirmed compromises are different measurements and should not be merged.
eSentire also described infrastructure rotation and similarities to other device-code campaigns. The reviewed evidence does not establish that GhostCode is operated by Storm-2372, Tycoon 2FA or another named group, so attribution should remain open.
How defenders can hunt for the pattern
eSentire’s investigation correlated successful device-code authentication with near-immediate non-interactive activity, unusual automation and multiple Device Registration Service calls. It also published hunting logic for identifying that sequence. Administrators should adapt detection to their own tenant baseline rather than treating any single device-code event as proof of GhostCode.
Microsoft sign-in logs and Conditional Access reporting remain the controlling operational surfaces for understanding whether device-code authentication is occurring in a tenant and whether it is permitted by policy.
What remains unknown
eSentire has not established a public total for successful GhostCode victims or compromised organizations. The reviewed evidence also does not establish operator attribution, prove that every related domain was actively weaponized, or show that properly restricted tenants using stronger device-compliance controls were successfully compromised by this exact kit.
Those boundaries matter because the strongest available evidence supports an active campaign and a concrete observed attack chain, but not universal exposure across Microsoft 365.
What happens next
TPS will treat new eSentire research, Microsoft campaign guidance, infrastructure takedowns, confirmed victim expansion, attribution or changes to Entra device-code controls as material updates to this same GhostCode canonical. A separate durable article should be considered later for the broader campaign-independent task of detecting and fully containing Microsoft device-code phishing.