When most people think about phishing, they picture a fake login page harvesting credentials. Device code phishing doesn’t work that way. There’s no spoofed domain. No credential harvesting. No malware. The victim authenticates against real Microsoft infrastructure, completes their MFA challenge, and hands an attacker a fully valid Bearer token — all without knowing anything unusual happened.
This technique has been active since mid-2024 and has accelerated significantly. What started as a nation-state tool is now available as a PhaaS kit. If your organization uses Microsoft 365 and hasn’t blocked Device Code Flow via Conditional Access, you’re exposed.
What Device Code Flow Is
OAuth 2.0 Device Authorization Grant (RFC 8628) was designed for input-constrained devices — smart TVs, printers, IoT hardware, CLI tools — that can’t run a browser or handle a redirect callback. The flow decouples authentication from the device requesting access.
Here’s how it works legitimately:
- A device POSTs to the Device Authorization Endpoint and receives a short
user_code, averification_uri, and adevice_codewith a ~15-minute TTL. - The device displays the code and URL (sometimes as a QR code) and tells the user to visit the URL on another device.
- The user opens the URL on their phone or laptop, enters the code, and completes their normal sign-in — including MFA.
- The requesting device polls the Token Endpoint in the background until it gets a success response.
- On completion, the device receives a Bearer access token and a refresh token.
This is entirely legitimate when your smart TV asks you to visit a URL to link your account. The problem is that any party can initiate this flow — including an attacker.
The Attack
The attacker doesn’t need to compromise anything to start. They initiate the Device Code Flow themselves against Microsoft Entra ID, receive a fresh user_code and verification_uri, then start polling.
They have roughly 15 minutes to get a victim to use that code.
The lure is typically a phishing email: a fake shared document, a salary report, an IT security re-verification notice. The message includes the user_code and a link to microsoft.com/devicelogin — the real Microsoft URL. The victim, already signed into their Microsoft account in their browser, visits the page, enters the code, and approves the request. Their browser shows a success screen. Everything looks normal.
Meanwhile, the attacker’s polling loop collects the valid Bearer token and refresh token for that account.
No credentials were stolen. No fake login page was involved. The authentication event in Entra ID logs shows a successful, user-initiated sign-in.
Why MFA Does Not Help
This is the part that matters most for defenders.
MFA is an authentication control. It verifies that the person logging in is who they say they are. In a device code phishing attack, the victim is who they say they are — they complete MFA as part of their normal session. The authentication is legitimate.
The attack happens in the authorization layer, after authentication has already succeeded. The victim is granting an OAuth application access to their account. By the time they enter the code, MFA is already done.
This holds for phishing-resistant MFA too. FIDO2 hardware keys, passkeys, certificate-based authentication — none of these prevent a user from visiting microsoft.com/devicelogin and entering a code they were socially engineered into entering. The binding is to the authentication event, not the authorization decision.
Who Is Using This
The technique has a clear trajectory: nation-state origin, criminal mass-market within 18 months.
Storm-2372 (Russia-aligned) ran the first documented large-scale campaigns starting August 2024, targeting government agencies, NGOs, energy companies, defense contractors, and IT firms. Their lures impersonated Microsoft Teams meeting invitations and WhatsApp messages from known contacts.
UNK_AcademicFlare (suspected Russia-aligned) began targeting academic institutions and transportation sector organizations in September 2025 across the US and Europe.
TA2723, a financially motivated criminal actor, entered in October 2025 with broader targeting and salary/file sharing lures — lower sophistication, higher volume.
EvilTokens, a PhaaS (Phishing-as-a-Service) kit, appeared in February 2026 built on Railway.com infrastructure. It automates the full attack chain — generating device codes, building lure emails, managing polling, and delivering tokens to buyers. Low skill required.
By March 2026, researchers reported 340+ affected Microsoft 365 organizations across five countries. Underground toolkits including SquarePhish2 and Graphish are actively sold and maintained.
What Actually Stops It
| Control | Priority | Notes |
|---|---|---|
| Conditional Access — block Device Code Flow | Highest | Microsoft added an Authentication Flows condition specifically for this. If you don’t need Device Code Flow, block it entirely. |
| Named Locations allowlist if flow is required | High | Scope to trusted IPs and approved users only. Eliminates the bulk of attack surface. |
SIEM alerting on deviceCode auth events | High | Hunt for privileged accounts, first-party app client IDs, cross-geo token reuse, and refresh token activity. |
| Token revocation runbook | Medium | Know how to revoke tokens and force re-auth before you need to. Test it. |
| User awareness | Ongoing | The message is simple: any code prompt you didn’t initiate is suspicious — report it immediately. |
The Conditional Access block is the decisive control. Everything else is defense-in-depth. If your tenant allows Device Code Flow with no restrictions, a single phished user hands an attacker persistent access via refresh token — which survives password resets unless explicitly revoked.
Detection
If you’re hunting rather than blocking, the sign-in logs will show:
- Authentication method:
deviceCode - Client app: often a first-party Microsoft app ID (pre-trusted, no consent prompt)
- Token issuance to an IP not associated with the user’s normal geography
First-party app IDs — like Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) — are pre-consented in every Entra tenant. This suppresses the consent prompt the user would otherwise see, removing one of the few visual signals that something unusual is happening.
Write SIEM rules for deviceCode in your auth logs, prioritize privileged accounts and service accounts, and alert on refresh token use from new locations or devices.
From the Trenches
What makes this technique particularly effective against well-defended organizations is that it exploits the trust users have built with Microsoft’s own infrastructure. There’s no suspicious domain to flag, no certificate warning to dismiss, no login page that looks slightly off. The victim visits microsoft.com. Everything checks out.
The social engineering has also matured. Early campaigns used generic lures. Storm-2372 specifically crafted messages that appeared to come from known contacts within the target organization — names pulled from LinkedIn or prior reconnaissance. That’s a different threat model than bulk phishing.
The PhaaS shift is the real inflection point. When a technique moves from nation-state-only to commodity tooling available to low-skill actors, the volume increases by orders of magnitude and the targeting becomes less discriminating. Any organization running M365 without Device Code Flow restrictions should treat this as a current, active risk — not a future concern.
The Conditional Access policy takes about five minutes to configure. Block it, or scope it tightly, and verify it’s enforced.
Risk Register
The four risk entries below cover the primary exposure areas from device code phishing in a Microsoft 365 environment. Use this as a starting template — adjust likelihood and impact scores to your organization’s context.
Likelihood × Impact Reference
| Low Impact | Medium Impact | High Impact | Critical Impact | |
|---|---|---|---|---|
| High Likelihood | Medium | High | Critical | Critical |
| Medium Likelihood | Low | Medium | High | Critical |
| Low Likelihood | Low | Low | Medium | High |
| Very Low Likelihood | Low | Low | Low | Medium |
IAM-001 — Device Code Flow Abuse / OAuth Token Hijacking
Description: An attacker initiates OAuth 2.0 Device Authorization Flow against the organization’s identity provider, socially engineers a user into entering the resulting user_code, and collects a valid Bearer token and refresh token without stealing credentials or bypassing MFA.
Likelihood: High — technique is commodity-level, available via PhaaS kits, active against M365 tenants globally.
Impact: Critical — full account access, persistent via refresh token, survives password resets without explicit revocation.
Inherent Risk: Critical
Current Controls: MFA enforced, Conditional Access policies in place (general).
Residual Risk: High — standard MFA does not address post-authentication authorization abuse. Device Code Flow not explicitly restricted.
Treatment:
- T-01: Configure Conditional Access Authentication Flows policy to block Device Code Flow tenant-wide.
- T-02: If Device Code Flow is required for specific use cases, restrict to Named Locations (trusted IPs) and approved user groups.
- T-03: Add user awareness module — “any code prompt you didn’t initiate is suspicious.”
NIST CSF 2.0 Mapping: GV.RM-01, ID.RA-01, PR.AA-05, DE.CM-01, RS.MI-02
IAM-002 — Refresh Token Persistence
Description: Following a successful device code phishing attack, the attacker possesses a long-lived refresh token that provides persistent access to the compromised account. Standard remediation steps (password reset, MFA reset) do not invalidate refresh tokens unless explicitly revoked.
Likelihood: Medium — contingent on successful IAM-001 exploitation.
Impact: High — persistent access survives remediation steps that defenders commonly rely on, extending dwell time.
Inherent Risk: High
Current Controls: Account monitoring, periodic access reviews.
Residual Risk: Medium — token revocation procedures exist in Entra ID but are not always included in incident response runbooks.
Treatment:
- T-01: Document and test token revocation procedure: Entra ID → Users → Revoke Sessions + invalidate refresh tokens via
revokeSignInSessionsAPI. - T-02: Include token revocation as a mandatory step in the identity compromise IR runbook.
- T-03: Alert on refresh token use from new device or geography post-revocation.
NIST CSF 2.0 Mapping: PR.AA-05, DE.CM-09, RS.MI-02, RC.RP-01
IAM-003 — Privileged Account Takeover via First-Party App Abuse
Description: Attackers specifically target administrative or privileged accounts using first-party Microsoft application Client IDs (e.g., Microsoft Authentication Broker). These apps are pre-trusted in every Entra tenant and suppress the OAuth consent prompt, removing a key visual indicator for the victim.
Likelihood: Medium — requires targeted reconnaissance but nation-state and financially motivated actors both demonstrate this capability.
Impact: Critical — privileged account compromise enables lateral movement, data exfiltration, and persistent backdoor creation.
Inherent Risk: Critical
Current Controls: Privileged Identity Management (PIM), MFA on admin accounts, limited standing admin access.
Residual Risk: High — PIM and MFA do not prevent Device Code Flow abuse. First-party app pre-trust cannot be removed without breaking legitimate Microsoft functionality.
Treatment:
- T-01: Apply Conditional Access Device Code Flow block specifically scoped to privileged/admin roles as highest priority.
- T-02: Monitor Entra ID sign-in logs for Device Code authentication events on admin accounts — alert immediately.
- T-03: Conduct table-top exercise simulating privileged account compromise via this vector.
NIST CSF 2.0 Mapping: GV.RM-02, ID.RA-04, PR.AA-02, PR.AA-05, DE.CM-01, RS.CO-02
SEC-011 — Insufficient Detection Coverage for OAuth Abuse Patterns
Description: Existing SIEM rules and monitoring are tuned for credential-based attacks (failed logins, password spraying, brute force). OAuth token abuse — including Device Code Flow, token replay, and refresh token persistence — may not generate alerts under current detection logic.
Likelihood: High — detection gap is common; most orgs tune for credential attacks, not authorization-layer abuse.
Impact: High — undetected compromise enables extended dwell time and secondary objectives before discovery.
Inherent Risk: High
Current Controls: SIEM deployed, general sign-in alerting configured.
Residual Risk: Medium — gap is closeable with targeted rule development.
Treatment:
- T-01: Write SIEM detection rule for
deviceCodeauthentication method in Entra ID sign-in logs. - T-02: Alert on
deviceCodeauth events for privileged accounts — treat as critical priority. - T-03: Alert on refresh token use from new device fingerprint or geographic location.
- T-04: Review first-party app authentication events for anomalous patterns (client IDs, token issuance times, IP correlation).
- T-05: Accept residual risk for low-privilege accounts with Device Code Flow blocked via Conditional Access (risk reduced to low).
NIST CSF 2.0 Mapping: ID.RA-01, DE.CM-01, DE.CM-09, DE.AE-02, RS.AN-03
References
- Microsoft Security Blog — Storm-2372 Device Code Phishing Campaign (Feb 2025)
- Proofpoint Threat Research — Access Granted: Phishing with Device Code Authorization (Dec 2025)
- Push Security — Analyzing the rise in device code phishing attacks in 2026 (May 2026)
- Huntress — Railway.com PaaS as M365 Token Attack Infrastructure (Mar 2026)
- RFC 8628 — OAuth 2.0 Device Authorization Grant
- Microsoft Docs — Entra ID Device Code Flow
Stay patched, stay vigilant.