Device code phishing is exposing gaps in Microsoft Entra ID controls

At a glance

What this is: This is an analysis of device code phishing and the way it turns legitimate Microsoft Entra ID sign-ins into attacker-held access tokens.

Why it matters: It matters because IAM, NHI, and security teams need controls that detect and constrain token abuse even when the user completes MFA on a real Microsoft page.

By the numbers:

• The EvilTokens PhaaS toolkit runs 10 to 15 distinct campaigns every 24 hours.
• Microsoft attributed an ongoing campaign to STORM-2372, a threat actor assessed with moderate confidence to align with Russian state interests.

👉 Read Silverfort's analysis of device code phishing in Microsoft Entra ID

Context

Device code phishing is an OAuth abuse pattern in which the attacker relies on the real Microsoft device login page rather than a fake sign-in screen. The governance problem is that Entra ID can issue valid tokens even when the person approving the code is not the one who initiated the session, so identity controls built around password capture never see the abuse.

For IAM and NHI teams, this is a protocol trust issue, not just a phishing issue. The victim completes MFA successfully, the attacker receives access and refresh tokens, and standard perimeter tooling often treats the transaction as benign because the only URL involved is a Microsoft domain.

The article shows that a technique once associated with a state-linked actor is now available as commodity tooling. That makes device code flow policy, token response handling, and non-interactive sign-in monitoring part of core identity governance rather than edge-case incident response.

Key questions

Q: How should security teams handle device code phishing when users complete real Microsoft MFA?

A: Treat it as a token abuse incident, not a password compromise. Revoke access, disable the account if needed, remove privileged role assignments, and hunt for non-interactive sign-ins, device registrations, and mailbox rule changes. The key is to cut off the token and the entitlement path together, because the attacker may already have persistent session authority.

Q: Why do device code phishing attacks bypass many standard phishing controls?

A: They use the real Microsoft login page, so there is no fake domain, no malicious payload, and no obvious infrastructure to block. The victim completes MFA willingly, which makes the sign-in look legitimate to many tools. Detection has to move to token issuance, unusual device-code use, and post-authentication behaviour instead of URL reputation alone.

Q: What breaks when device code flow is left enabled for the broad workforce?

A: The organisation creates an unnecessary path for attackers to turn user approval into access tokens without capturing passwords. Because many users almost never need the flow, broad enablement expands attack surface without adding commensurate business value. The control failure is not just exposure, but the absence of a strong exception model.

Q: Who is accountable when stolen tokens are used after a device code phishing incident?

A: Identity, IAM, and security operations all share accountability, because the incident crosses authentication policy, session response, and access governance. Microsoft guidance now supports blocking the flow where it is not needed, and teams should ensure their playbooks address token revocation, role removal, and non-interactive log review as mandatory steps.

Technical breakdown

OAuth device code flow and delegated token issuance

The OAuth 2.0 device authorization grant exists for headless or input-constrained devices. A client requests a device code, the user completes authentication on a separate browser, and the authorization server later returns access tokens to the polling client. The critical design point is that the polling device is not cryptographically bound to the human who approves the flow. That makes the code itself the control point, not the device identity, which is why an attacker can initiate the flow and wait for the user to complete it on a trusted Microsoft page.

Practical implication: block device code flow wherever it is not an explicit business requirement.

Why real Microsoft login pages defeat common phishing controls

This attack skips the fake-page model entirely. The user signs into login.microsoft.com/devicelogin, completes MFA, and sees a normal success path, while the attacker polls the token endpoint from a different machine. Because there is no typo-squatted domain, no payload, and no reverse proxy, email filters, URL scanners, and many EDR or identity signals stay quiet. The result is a legitimate authentication event that produces illegitimate session tokens, which is why traditional phishing detections miss the abuse.

Practical implication: alert on successful device-code sign-ins rather than only on suspicious URLs or payloads.

Token persistence after the initial device code approval

Once the attacker receives tokens, the problem shifts from sign-in to persistence. Revoking refresh tokens can help, but access tokens already issued remain valid until expiry, and the article notes that attackers can establish devices and inbox rules quickly after the first approval. That means remediation has to consider the live session, the assigned roles, and the follow-on Graph activity, not just the original authentication event. In practice, the malicious value comes from what the token enables after issuance.

Practical implication: treat token revocation, role removal, and session hunting as one response sequence.

Threat narrative

Attacker objective: The attacker wants durable Microsoft 365 access that can be used for reconnaissance, persistence, and financial or executive email abuse without stealing a password.

1. Entry occurs when the attacker initiates a legitimate device code flow against Microsoft Entra ID and persuades the victim to approve the code on the real Microsoft login page.
2. Escalation follows when the attacker receives access and refresh tokens, then uses them to register devices, query Microsoft Graph, and expand visibility into the tenant.
3. Impact lands through persistence and mailbox abuse, including hidden inbox rules, targeted email exfiltration, and access that survives ordinary password-reset-only response.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Device code phishing exposes a trust gap in Entra ID sign-in design, not just a phishing weakness. The protocol assumes the entity polling for the code is the same entity the user intended to authorise. That assumption breaks when an attacker initiates the flow and the victim completes MFA on the real login page. The implication is that identity programmes must stop treating successful sign-in as proof of intended access.

Access revocation after token issuance is now a governance problem, not merely an incident-response task. The article makes clear that refresh-token revocation alone does not invalidate already issued access tokens, and that attackers can create persistent devices and inbox rules very quickly. This is a standing privilege exposure window in token form. Practitioners should read this as evidence that session authority can outlive the authentication event that created it.

Device code flow should be treated as a scoped exception, not a default enterprise authentication path. Most enterprise users rarely need it, yet many tenants leave it broadly available because it is supported by first-party Microsoft tooling. That creates unnecessary blast radius across human identity, NHI-adjacent CLI use, and privileged admin workflows. The governance conclusion is simple: if a workflow cannot justify device code use, it should not inherit that trust path.

Token-bound identity controls matter more as phishing shifts from credential theft to session theft. The attack works because MFA is satisfied legitimately while the attacker receives the token on another device. That makes classic password-centric assumptions too narrow for modern identity security. Teams need to think in terms of token provenance, session origin, and non-interactive activity, not just authentication success.

Device code phishing is becoming a named operational pattern, not an isolated tactic. The move from STORM-2372 to EvilTokens shows how quickly an identity abuse method becomes commoditised once the protocol path is reliable. That should push security leaders to reclassify this from niche phishing to a repeatable token-abuse control domain. The practical implication is to govern the protocol surface, not chase individual lures.

From our research:

• From our research: 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• For teams mapping identity risk across secret leakage and runtime abuse, the The 52 NHI breaches Report is the next place to compare patterns and control failures.

What this signals

Identity teams should expect phishing to keep shifting from credential capture to token abuse. Once users can be tricked into approving real flows on real pages, the control point moves to session origin, non-interactive sign-ins, and post-authentication behaviour. The programme signal is clear: harden the sign-in policy layer now, because alerting on bad URLs alone will miss the next wave.

Token provenance is becoming a governance concept in its own right. If a session can be legitimate in form and hostile in intent, then authentication success is no longer enough for trust. That is why identity programmes need a tighter bridge between Conditional Access, token revocation, and entitlement review, anchored in policy rather than reaction.

Teams that already track machine and workload access should apply the same discipline to human sign-in exceptions. The boundary between user identity and NHI-style token authority is narrowing, and the attack surface expands whenever an organisation leaves uncommon authentication paths broadly available.

For practitioners

• Block device code flow for users without a documented business need Use Conditional Access to deny device code authentication for the broad workforce, then create narrow exceptions only for approved CLI, headless, or device-constrained workflows. Review the exception list regularly and tie each allow decision to a named business owner and use case.
• Hunt non-interactive sign-ins after any suspicious device code approval Correlate successful device-code logins with later non-interactive token activity, unusual geography, and first-party client use such as Azure CLI or Microsoft Office. Focus on accounts that do not normally authenticate this way, because those hits often indicate token replay or post-compromise persistence.
• Treat token revocation and role removal as one containment step When device code phishing is suspected, revoke access, disable the account if required, remove role assignments, and review OAuth consents and recent device registrations. Password resets alone do not end the session, so containment has to reach both the token and the entitlement layer.
• Add device code flow to identity policy reviews and exception management Document which applications and teams truly require device code access, then test whether those exceptions still reflect current operations. If a team cannot justify why it needs the flow, remove it from scope and reduce the attack surface before the next campaign lands.

Key takeaways

• Device code phishing works because it abuses a real authentication flow, not a fake login page.
• The scale is moving quickly, from nation-state tradecraft to automated PhaaS in less than a year.
• The effective response is policy-based containment, token revocation, and tighter exception management around device code use.

Key terms

• Device code flow: An OAuth authentication method for devices that cannot present a normal browser sign-in. A user completes authentication on a separate device and the original client receives tokens after approval. In attack scenarios, the code can be initiated by one party and approved by another, which creates a trust gap in the session handoff.
• Non-interactive sign-in: A sign-in event that occurs without a user actively entering credentials in the moment. These events often represent token refresh, background application use, or service activity. In device code phishing investigations, they are a critical place to look for post-approval token replay and persistence activity.
• Token revocation: The process of invalidating issued access or refresh tokens so a session can no longer be used. It is a containment step, not a full cleanup by itself, because already issued access tokens may remain valid until expiry and related entitlements or device registrations can still sustain attacker access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Silverfort: device code phishing and Microsoft Entra ID token abuse. Read the original.