GhostCode: How Device-Code Phishing Is Hijacking Microsoft 365 Accounts

Status: Confirmed — GhostCode identified by eSentire’s threat response unit in late August 2026.
Affected: Microsoft 365 tenants relying on the OAuth 2.0 device authorization grant flow.
Vector: GhostCode phishing kit abusing device-code authentication.
Reference: Microsoft Learn’s OAuth 2.0 device-code documentation and Microsoft’s Storm-2372 security blog.

Microsoft 365 accounts are being taken over through a clever new phishing kit called GhostCode, and the trick exploits a legitimate Microsoft sign-in mechanism that most users never once suspect. According to eSentire’s threat response unit, which identified the campaign in late August 2026, attackers are abusing the OAuth 2.0 device authorization grant flow — the same device-code phishing technique that has been used in prior account-hijacking operations.

What is GhostCode and how does it work?

The device authorization grant flow exists so that devices without a full browser — IoT gadgets, smart TVs, printers, and similar hardware — can authenticate to Microsoft services. Normally, the device shows the user a short code, and the user types that code into a browser on another screen to finish the sign-in.

GhostCode turns that flow against you. It plays the role of the device, gets Microsoft’s OAuth to mint a device code, and then convinces the victim to enter that code on Microsoft’s own authentication page. When you sign in and complete multifactor authentication as usual, you’re actually approving an attacker-controlled device. The resulting tokens are captured and used to register attacker devices, pull more credentials, and establish a foothold in your tenant.

A web contact form on a laptop screen with a subtle 'procurement officer' chat window beside it, soft office-lighting, c — The first touch: a procurement-officer contact form that lures the victim before shifting to the NDA HTML file.

In the eSentire-observed campaign, the setup started with a web contact form where attackers posed as procurement officers. Once the victim engaged, conversations were moved to an NDA-themed HTML file. Opening that file redirected the victim straight to the device-code phishing page.

The attackers layered several evasion techniques to keep security tools away from the lure. They padded and obfuscated the HTML, encrypted their redirects, ran bot-checks, and even used the Cloudflare Turnstile interface to shield the phishing page from automated scanners.

Persistence after authentication

Once access was granted, GhostCode focused on staying inside the Microsoft environment. eSentire recorded nine successful API calls over a 78-second window, touching Microsoft Intune Enrollment, the Device Registration Service, Azure Active Directory, and Microsoft Graph.

Three devices were registered in that window — at 28, 53, and 77 seconds after authentication — a sequence eSentire described as automated. The third device was also enrolled into Intune, Microsoft’s cloud-based device management service. Crucially, that Intune enrollment survived token revocation: the attacker-created device stayed in the tenant until someone explicitly removed it.

Three device icons quietly registering themselves one after another on a dark admin dashboard, cool blue and green glow, — Three attacker devices registered within 78 seconds, including one that survives token revocation in Intune.

Attackers also grabbed a Primary Refresh Token (PRT), which eSentire called “one of the most powerful” credentials in a Microsoft identity environment. “Obtaining a PRT via device code abuse gives the threat actors essentially SSO-equivalent access to the victim’s entire M365 environment for the PRT’s lifetime,” eSentire noted, adding that the token persists 14 days by default. That window stretches even further for any service not explicitly protected by a Conditional Access policy requiring a compliant device.

What defenders can do

eSentire’s researchers recommend restricting Microsoft’s device-code authentication flow through Conditional Access, and disabling it for users who don’t need it. IT admins managing a fleet should monitor the Device Registration Service for multiple device registrations coming from a single non-interactive session, and look for activity tied to the python-requests user agent following device-code authentication.

Auditing Entra ID for devices matching GhostCode’s naming pattern, and correlating a successful device-code sign-in with subsequent Python-based requests, should catch an attack in progress. eSentire also published a list of indicators of compromise related to the campaign to aid detection.

A growing wave of device-code attacks

GhostCode joins a widening list of campaigns abusing Microsoft’s OAuth device-code flow. Recent examples include the “EvilTokens” phishing-as-a-service (PhaaS) kit, a campaign reported by KnowBe4 in February 2026, and December 2026 activity involving multiple clusters that blended financially motivated and state-sponsored actors.

What This Means for You

For everyday users, the takeaway is that a routine sign-in can quietly hand an attacker the keys to your M365 environment. The phishing page looks like Microsoft’s own login, so the “did I just approve two-factor?” moment stops being a red flag and becomes the norm. If you sign in through a device-code flow and don’t recognize it, your tokens may already be in play — and the 14-day PRT window means the session can outlive a hasty password reset.

What You Can Do

Review your tenant’s Conditional Access policies and restrict the device-code flow where it isn’t needed.
Disable device-code authentication for users who don’t require it, per eSentire’s guidance.
Alert on multiple device registrations from a single non-interactive session and on python-requests user agents after device-code sign-ins.
Audit Entra ID for devices matching GhostCode’s naming pattern, and revoke or remove any unrecognized devices.
Watch for a Primary Refresh Token persisting up to 14 days, and rotate credentials for at-risk accounts.

What This Means for You

Source: Computerworld

Over to you: If your admin disables the device-code flow company-wide, would you see it as a welcome restriction or an annoyance for legitimate IoT and smart-TV sign-ins?