Device code phishing pages rose 37.5x in 2026, according to Push Security, which had measured a 15x rise at the start of March before the figure climbed further. This is not a credential-harvesting trick that a strong password or a hardware key defeats. The victim signs in on the genuine Microsoft page, completes multi-factor authentication for real, and the resulting session tokens land on an attacker's device. Authentication is not bypassed. It is completed successfully, just not by the person who owns the account.
Three forces turned a niche technique into a 2026 identity crisis. Huntress tracked a 1,380% spike in device code phishing between the second half of 2025 and early 2026, and watched a single wave of the EvilTokens phishing-as-a-service kit hit 344 organizations across five countries. Barracuda detected over 7 million device code phishing attacks in a single four-week window. And SpyCloud recaptured 8.6 billion stolen session cookies from 2025 alone, confirming that attackers have shifted from stealing passwords to stealing the authenticated session that sits behind them. This is written for CISOs, identity and security engineers, incident responders, and the security buyers who have to answer the board question: "We rolled out passkeys, so why is this still possible?"
This post is the Stingrai research team's canonical 2026 reference for device code phishing and ClickFix. It carries 15 attributed statistics drawn from eight primary publishers: Push Security, Huntress, Microsoft Security, Sekoia, Proofpoint, Barracuda, the Cloud Security Alliance, and SpyCloud. Lead detection and campaign data is 2026 telemetry, the freshest available; the foundational Storm-2372 attribution is Microsoft's February 2025 disclosure. Every stat carries its source, publisher, and date so any claim can be audited inline, and every figure links back to the primary publisher.
TL;DR: the numbers that matter
Device code phishing page surge (2026): 37.5x rise, up from a 15x rise at the start of March (Push Security, Rise in device code phishing 2026).
Volume spike (H2 2025 vs early 2026): 1,380% increase in device code phishing (Huntress, EvilTokens report).
Attacks in four weeks (April 2026): more than 7 million device code phishing attempts detected (Barracuda, Threat Spotlight).
Single-wave blast radius: 344 organizations across the US, Canada, Australia, New Zealand, and Germany hit by one EvilTokens wave (Huntress).
Commoditization: EvilTokens, the first turnkey device-code phishing-as-a-service kit, launched mid-February 2026 and is sold through Telegram bots (Sekoia, EvilTokens Part 1).
Distinct kits in the wild: 14 or more device code phishing kits identified (Push Security).
State-sponsored origin: Storm-2372, assessed by Microsoft as aligned with Russian interests, has run this technique since August 2024 (Microsoft Security, Storm-2372).
Criminal adoption: financially motivated actor TA4903 replaced its business email compromise operations with device code phishing in March 2026 (Proofpoint).
Stolen session artifacts (2025): 8.6 billion session cookies recaptured from 13.2 million infostealer infections (SpyCloud, 2026 Identity Exposure Report).
Endpoint controls are not enough: 40% of those infostealer infections occurred on endpoints running EDR or antivirus (SpyCloud).
Key takeaways
Device code phishing is not an MFA bypass in the usual sense. It rides a completed authentication. The victim performs the sign-in and the MFA challenge on the real Microsoft page, and the tokens are issued to the attacker's polling script. Because the login genuinely succeeds, no authenticator, one-time code, push prompt, or FIDO2 passkey blocks it (Push Security).
Passkeys defend the login layer. This attack targets the authorization layer that sits behind it. Passkeys make the sign-in itself unphishable, and they are still worth deploying. But the device code grant is a post-authentication authorization step, so a valid passkey login is exactly what the attacker needs the victim to complete (Push Security).
ClickFix is what makes it work at scale. Copy a code, click continue, sign in: the pattern reads as a routine security step rather than an attack, which is why it converts. ClickFix-style social engineering dominated malware-loader activity in 2026 and now fronts device code lures (Lindensec).
The technique has commoditized from nation-state tradecraft to a Telegram subscription. What Microsoft first attributed to Russia-aligned Storm-2372 in 2024 is now a turnkey, AI-assisted kit that let one EvilTokens wave reach 344 organizations (Cloud Security Alliance, Huntress).
The fix is structural, not another authentication factor. Blocking or tightly scoping the OAuth device code flow in Conditional Access, applying token protection, and shrinking token lifetimes remove the capability rather than trying to out-authenticate it (Microsoft Security).
Methodology
This explainer draws on primary sources published between February 2025 and June 2026, with a research cutoff of July 1, 2026. The sources and their data windows: Microsoft Security's Storm-2372 disclosure (February 2025) and its AI-enabled device code phishing analysis (April 2026); Push Security's 2026 measurement of device code phishing pages (April 2026); Huntress's EvilTokens report (June 2026); Sekoia's EvilTokens kit analysis (March 2026); Proofpoint's identity-takeover threat insight (May 2026); Barracuda's threat spotlight (April 2026); the Cloud Security Alliance research note on the EvilTokens campaign (March 2026); and SpyCloud's 2026 Annual Identity Exposure Report, covering full-year 2025 recapture data (March 2026).
Every numeric claim was verified against the named primary publisher during the research pass. Figures that could not be confirmed against a primary source on at least one verification pass were dropped rather than estimated or hedged. Attribution is inline throughout the body and consolidated in the References section.
What device code phishing actually is
Microsoft's OAuth 2.0 device authorization grant exists for a good reason. Smart TVs, CLI tools, IoT sensors, and other devices with no keyboard or browser cannot run a normal interactive login. So the device shows a short code and asks you to visit a URL on your phone or laptop, enter the code, and approve. The device then receives tokens without ever handling your password.
That convenience is the whole attack surface. The initial request to generate a device code is unauthenticated across all providers (Push Security). Anyone can ask Microsoft for a valid device code. The attacker's job is simply to convince a real user to approve that code on the real Microsoft page. When they do, Microsoft issues tokens to whatever session initiated the request, which is the attacker's script, not the victim's browser.
As Microsoft explains in its AI-enabled campaign analysis, the design assumption breaks here: "because authentication is completed on a separate device, the session initiating the request is not strongly bound to the user's original context," which lets attackers "bypass more traditional MFA protections by decoupling authentication from the originating session" (Microsoft Security).
How the attack chain works, step by step
The device code plus ClickFix chain has six moving parts. The reconstruction below follows the sequence documented by Lindensec and Microsoft.
The attacker requests a device code. A script sends an unauthenticated request to Microsoft's device code endpoint and receives a genuine code, valid for roughly 15 minutes. No credentials are needed to get it.
The attacker delivers a ClickFix lure. The victim receives a phishing email or message pointing to a page that spoofs a familiar service, commonly SharePoint, OneDrive, or Teams, with an "access shared document" pretext. The page uses the ClickFix pattern: copy the code, click continue, sign in.
The victim copies the "verification code." The lure frames the device code as a normal verification step, so the victim copies it exactly as instructed. Nothing about the page asks for a password, which is what makes it feel safe.
The victim pastes it into the real Microsoft page. The victim goes to the genuine endpoint,
login.microsoftonline.com/common/oauth2/deviceauth, enters the code, selects their account, and completes full authentication, including MFA. Every certificate, domain, and prompt is authentically Microsoft, so browser warnings and passkey checks all pass.The attacker polls the token endpoint. While the victim authenticates, the attacker's script is polling Microsoft's token endpoint. The moment the victim approves, Microsoft returns an access token and a refresh token to the attacker.
The attacker inherits the session. The refresh token can remain valid for up to 90 days and carries the completed MFA claim, so the attacker holds authenticated access without ever possessing the password or the second factor. As Lindensec puts it, "the victim does the MFA for the attacker."
Newer kits close the one weakness in this chain, the 15-minute code expiry. Microsoft observed operators using "dynamic generation," shifting code creation to the final stage of the redirect chain so the countdown "only begins the moment the victim clicks the phishing link" (Microsoft Security).
Why MFA, and even passkeys, do not stop it
Most MFA advice assumes the attacker is trying to answer the authentication challenge. Device code phishing does not try. It gets the victim to answer it.
Push Security states the mechanism plainly: "Device code authorization is effectively performed post-authentication. If you already have an active session in your browser, entering the device code and selecting your account from a drop-down menu is all that's needed. No password or MFA required" (Push Security).
That single design fact defeats every MFA type in the same way:
SMS, TOTP, and push MFA: the victim satisfies these on the real Microsoft page. The attacker never sees or needs the code.
Number-matching and app-based approval: the victim approves their own legitimate-looking sign-in, so the prompt is answered honestly.
FIDO2 passkeys and other phishing-resistant MFA: passkeys make the login itself unphishable, but the device code grant is an authorization step that happens after a successful login. A valid passkey sign-in is precisely what the attacker needs, so the passkey does its job perfectly and the attacker still wins.
This is a different failure mode from adversary-in-the-middle (AitM) phishing, where a reverse proxy such as an Evilginx-style kit relays a fake login page and captures the session cookie mid-flow. AitM at least presents a lookalike domain that a passkey or a sharp-eyed user can reject. Device code phishing presents the real Microsoft domain, so there is no lookalike to catch. It also overlaps with consent phishing, where a victim grants a malicious OAuth app broad permissions, and with the broader shift toward stealing authenticated sessions rather than passwords.
That broader shift is the real story. SpyCloud recaptured 8.6 billion stolen session cookies from 13.2 million infostealer infections in 2025, and found that 40% of those infections happened on endpoints protected by EDR or antivirus (SpyCloud). Attackers have learned that the session is the prize. Device code phishing is simply the cleanest way to obtain one straight from the source, with the victim's own hands completing the MFA.
Who is running these campaigns
Storm-2372 (state-sponsored). Microsoft first disclosed device code phishing at scale in February 2025, attributing it to Storm-2372, an actor it assesses "with moderate confidence" aligns with Russian interests. The campaign has been active since August 2024 and has hit government, NGOs, IT, defense, telecom, health, higher education, and energy across Europe, North America, Africa, and the Middle East, using lures that "resemble messaging app experiences including WhatsApp, Signal, and Microsoft Teams" (Microsoft Security).
TA4903 (financially motivated). Proofpoint documented a financially motivated actor, TA4903, that "began using device code phishing to steal credentials in March 2026" and "replaced their business email compromise activities" with it. TA4903 has a history of high-volume credential campaigns using salary and benefits themed lures (Proofpoint).
EvilTokens (the commoditizer). The technique jumped from bespoke tradecraft to a product with EvilTokens, which Sekoia calls "the first PhaaS to offer turnkey Microsoft device code phishing pages." It has circulated since mid-February 2026, operates through "fully featured bots on Telegram," and bundles AI-powered automation, email harvesting, and reconnaissance that queries the Microsoft Graph API for organization, user, group, and directory-role data (Sekoia). The Cloud Security Alliance summarized the trajectory: "What began as a state-sponsored Russian intelligence technique in mid-2024 has commoditized into a Phishing-as-a-Service offering," with the EvilTokens platform compromising "340+ organizations across five countries within weeks" (Cloud Security Alliance).
The AI angle raises the ceiling further. Huntress found that across 344 victim organizations in a single wave, "no two phishing lures were identical," with generative AI crafting a personalized email per target based on job function and context (Huntress). Microsoft observed the same, with AI generating lures themed around RFPs, invoices, and manufacturing workflows (Microsoft Security).
How to detect and defend against device code phishing
Because the authentication succeeds legitimately, detection and prevention live in the authorization and monitoring layers, not the MFA settings. Prioritize the structural controls first.
Block or tightly scope the device code flow
Most organizations do not need interactive device code sign-in for their general workforce. Microsoft's own guidance is to "block device code flow wherever possible" (Microsoft Security). In Entra ID, a Conditional Access policy targeting the device code flow lets you deny it broadly and allow it only for the specific user groups and trusted networks that genuinely rely on input-constrained devices. This is the single highest-leverage control because it removes the capability rather than trying to detect its abuse.
Apply token protection and shrink token lifetimes
Token protection (token binding) ties a refresh token to the device it was issued on, so a token replayed from an attacker's machine fails. Combine it with Conditional Access session controls and shorter sign-in frequency so a stolen refresh token has a smaller window and a harder time being reused off-device.
Hunt for the tell-tale sign-in pattern
Device code sign-ins produce a distinctive signature: an authentication where the code was issued to one context and redeemed by a user in another, often followed quickly by token activity from an unfamiliar IP, autonomous system, or geography. Alert on device code authentications for users or apps that never use them, on device code sign-ins from new locations, and on refresh-token redemption that diverges from the user's normal pattern. On compromise, Microsoft's response guidance is direct: revoke the user's refresh tokens and temporarily disable the affected account (Microsoft Security).
Train people against the specific ClickFix pattern
Generic phishing training does not inoculate users against "copy this code and paste it on the real Microsoft page," because the destination really is Microsoft. Teach the specific rule: legitimate document sharing and sign-ins never ask you to copy a code from one page and enter it on a Microsoft device-login screen. If a workflow tells you to do that, it is an attack. Reinforce it with simulations that use the actual ClickFix and device-code lure patterns rather than stale password-harvesting templates.
Keep deploying passkeys, but do not treat them as complete
Passkeys remain the strongest defense against classic credential phishing and AitM proxying, and they should be rolled out. Just size expectations correctly: they harden the login, and device code phishing attacks the authorization step that comes after it. Layer the device-code-specific controls above on top of your passkey program.
How Stingrai helps
The uncomfortable truth about device code phishing is that no control is truly proven until an adversary tries it against your people and your tenant. A Conditional Access policy that looks correct in the portal can still leave a service account or a legacy app path exposed, and a workforce that passed last year's phishing test can still paste a code onto a real Microsoft page.
Stingrai is an offensive security and PTaaS firm founded in 2021, headquartered in Toronto with a London office, and a firm-level CREST-accredited penetration testing service provider. Our social engineering and phishing simulation work tests exactly this: whether your users recognize a ClickFix lure, whether your Entra Conditional Access actually blocks the device code flow where it should, and whether your detection and response teams catch the anomalous sign-in and token activity before an attacker pivots to business email compromise. Our adversary simulation and red team engagements go further, chaining an initial identity foothold into the lateral movement and data access a real operator would attempt, so you see the full blast radius, not just the click rate.
The output is evidence you can act on and evidence your auditors accept. Stingrai's penetration testing and social engineering assessments support your SOC 2, ISO 27001, PCI DSS, and HIPAA compliance programs by demonstrating that your identity controls hold under realistic attack. For engagement scoping and pricing, see the Stingrai pricing page.
Frequently asked questions
What is device code phishing and how does it bypass MFA in 2026?
Device code phishing abuses Microsoft's OAuth 2.0 device authorization grant. An attacker generates a legitimate device code, tricks a victim into entering it on the real Microsoft page, and the victim completes sign-in and MFA there while the attacker's script collects the resulting tokens. It bypasses MFA because the authentication genuinely succeeds; the victim performs it, and no factor, including passkeys, blocks a legitimate login (Push Security). Push Security measured a 37.5x rise in these attacks in 2026.
Can passkeys stop device code phishing?
No. Passkeys make the login itself phishing-resistant, but device code authorization happens after a successful login, on the authorization layer rather than the login layer. A valid passkey sign-in is exactly what the attacker needs the victim to complete, so the passkey works as designed and the attack still succeeds (Push Security). Passkeys are still worth deploying against classic and adversary-in-the-middle phishing; they just do not cover this specific flow.
What is ClickFix and how does it relate to device code phishing?
ClickFix is a social-engineering pattern that instructs the victim to copy a code or command and paste it somewhere, framed as a routine verification or fix. In device code phishing, a spoofed SharePoint, OneDrive, or Teams page tells the victim to copy a "verification code," then paste it into the real Microsoft device-login page. Because the destination really is Microsoft, the step feels legitimate and no lookalike domain warning fires (Lindensec).
Who is behind device code phishing attacks?
The technique started as state-sponsored tradecraft. Microsoft attributes early campaigns to Storm-2372, an actor it assesses aligns with Russian interests, active since August 2024 (Microsoft Security). It has since commoditized: financially motivated actor TA4903 adopted it in March 2026 (Proofpoint), and the EvilTokens phishing-as-a-service kit sells turnkey device code phishing pages through Telegram (Sekoia).
How do I detect and prevent device code phishing?
Prevention is structural. Block or tightly scope the OAuth device code flow with an Entra Conditional Access policy, since Microsoft recommends blocking it wherever possible (Microsoft Security). Add token protection and shorter token lifetimes, and hunt for device code sign-ins from users or apps that never use them and for refresh-token activity from unfamiliar locations. On compromise, revoke refresh tokens and disable the account immediately.
How is device code phishing different from adversary-in-the-middle phishing?
Adversary-in-the-middle (AitM) phishing relays a fake login page through a reverse proxy and captures the session cookie as it passes, which means the victim sees a lookalike domain that a passkey or careful user can reject. Device code phishing uses the real Microsoft domain and has the victim complete a genuine login, so there is no lookalike to catch and passkeys pass normally. Both end in a stolen authenticated session, part of the wider shift SpyCloud measured with 8.6 billion session cookies recaptured in 2025 (SpyCloud).
References
Push Security. Analyzing the rise in device code phishing attacks in 2026. April 2026. https://pushsecurity.com/blog/device-code-phishing/. Browser-telemetry measurement of device code phishing pages, kit counts, and why the attack bypasses MFA and passkeys.
Huntress. EvilTokens and the Rise of AI-Powered Phishing. June 2026. https://www.huntress.com/resources/eviltokens-ai-powered-phishing-report. Analysis of the EvilTokens PhaaS kit, the 1,380% device code phishing spike, and a 344-organization campaign wave with AI-personalized lures.
Microsoft Security. Storm-2372 conducts device code phishing campaign. February 2025. https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/. Attribution of early device code phishing to a Russia-aligned actor, active since August 2024, with messaging-app lures.
Microsoft Security. Inside an AI-enabled device code phishing campaign. April 2026. https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/. AI-generated lures, dynamic device-code generation, and defensive guidance including blocking the device code flow and revoking refresh tokens.
Sekoia. New widespread EvilTokens kit: device code phishing as-a-service (Part 1). March 2026. https://www.sekoia.com/blog/new-widespread-eviltokens-kit-device-code-phishing-as-a-service-part-1. Technical breakdown of the first turnkey device-code PhaaS kit, its Telegram distribution, AI automation, and Graph API reconnaissance.
Proofpoint. Device Code Phishing is an Evolution in Identity Takeover. May 2026. https://www.proofpoint.com/us/blog/threat-insight/device-code-phishing-evolution-identity-takeover. Documentation of financially motivated actor TA4903 replacing business email compromise with device code phishing in March 2026.
Barracuda. Threat Spotlight: Device code phishing is on the rise with 7 million attacks in four weeks. April 2026. https://blog.barracuda.com/2026/04/23/threat-spotlight-device-code-phishing. Volume telemetry showing more than 7 million device code phishing attacks in a four-week window, largely powered by EvilTokens.
Cloud Security Alliance. Research Note: OAuth Device Code Phishing Hits 340+ Microsoft 365 Organizations. March 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-oauth-device-code-phishing-m365-20260325-c/. Campaign analysis of the EvilTokens platform compromising 340+ organizations across five countries in weeks.
SpyCloud. 2026 Annual Identity Exposure Report. March 2026. https://spycloud.com/blog/2026-annual-identity-exposure-report/. Full-year 2025 recapture data on stolen session cookies, infostealer infections, and the shift toward authenticated-session theft.
Lindensec. Device Code Phishing Meets ClickFix: How Attackers Hijack Your Microsoft 365 Identity. March 2025. https://www.lindensec.com/post/device-code-phishing-meets-clickfix-how-attackers-hijack-your-microsoft-365-identity. Step-by-step reconstruction of the device code plus ClickFix chain, including the real device-auth endpoint and refresh-token lifetime.
