There’s a class of phishing attack gaining serious momentum right now that most security teams aren’t prepared for. It doesn’t steal passwords. It doesn’t clone login pages. It routes victims through Microsoft’s real authentication infrastructure, lets them complete their own MFA challenge, and hands the attacker a set of tokens that persist even after a password reset.
It’s called device code phishing, and in 2026 it’s gone from a niche technique used by state-sponsored actors to a fully commoditized attack available to anyone with a Telegram account and a few hundred dollars.
The Numbers#
Push Security has been tracking the growth of this technique throughout 2026. By early March, they’d observed a 15x increase in device code phishing pages compared to the start of the year. By early April, that figure reached 37.5x.
The scale is significant. Huntress identified a single campaign that hit over 340 Microsoft 365 organizations across the United States, Canada, Australia, New Zealand, and Germany. Sectors targeted include construction, nonprofits, real estate, manufacturing, financial services, healthcare, legal, and government. This isn’t targeted espionage. It’s broad, opportunistic, and automated.
At least 11 distinct phishing kits now offer device code phishing capabilities. The most prominent is EvilTokens, a phishing-as-a-service (PhaaS) platform that launched on Telegram in mid-February 2026 and has been the primary driver of the technique’s mainstream adoption.
How the Attack Works#
To understand why this attack is effective, you need to understand what it’s abusing.
The OAuth 2.0 Device Authorization Grant (RFC 8628) was designed for devices with limited input capabilities: smart TVs, IoT devices, printers, and conference room systems that can’t easily display a full browser login page. The flow works like this:
- The device requests a short alphanumeric code from Microsoft’s authorization endpoint
- The user opens a browser on a separate device (phone, laptop) and navigates to
microsoft.com/devicelogin - The user enters the code and completes normal authentication, including MFA
- Microsoft issues an access token and refresh token to the original device
The critical design feature here is the separation between the device requesting authorization and the user performing authentication. That separation is exactly what attackers exploit.
In a device code phishing attack, the attacker plays the role of the “device.” They initiate a legitimate device authorization request to Microsoft using a valid client ID (typically a first-party Microsoft application like Microsoft Office), receive a user code, and then deliver that code to the victim through social engineering.
The victim navigates to Microsoft’s real login page, enters the code, completes their MFA challenge, and unknowingly authorizes the attacker’s session. The attacker then receives valid OAuth access and refresh tokens without ever touching a password or intercepting a second factor.
What the Attacker Gets#
A successful device code phishing attack gives the attacker two things:
An access token (valid for 60 to 90 minutes) that provides immediate access to the victim’s Microsoft 365 resources: email via Exchange Online, documents from SharePoint and OneDrive, and conversation history in Teams.
A refresh token (rolling 90-day validity) that allows the attacker to silently request new access tokens indefinitely, as long as the token is renewed before expiration and isn’t revoked. This is persistent access with no further authentication required.
In more advanced post-compromise scenarios, the attacker can use the refresh token to register a new device in Entra ID, then request a Primary Refresh Token (PRT). A PRT enables single sign-on across the victim’s entire Microsoft 365 environment, including lateral movement to services and resources beyond the original target, with no password prompts and no MFA challenges.
Why MFA Doesn’t Help#
This is the point that matters most for practitioners building defense strategies around strong authentication.
In a traditional phishing attack, MFA is a backstop. Even if the attacker captures a password, the second factor prevents account access. The entire value proposition of MFA depends on the assumption that the attacker is the one trying to authenticate.
Device code phishing breaks that assumption. The victim completes the MFA challenge themselves, on behalf of the attacker, on Microsoft’s legitimate infrastructure. The attacker never needs the password. They never need the second factor. They simply wait for the victim to authorize their session and collect the tokens.
This isn’t a theoretical weakness. It’s an architectural one. The Device Authorization Grant flow was designed to delegate authentication to a trusted user. The attack works precisely because the protocol is functioning as intended.
The EvilTokens Kit and the PhaaS Market#
The commoditization of this technique is what’s driving the surge.
EvilTokens appeared on Telegram in mid-February 2026 and was quickly adopted by cybercriminals specializing in adversary-in-the-middle phishing and business email compromise. Sekoia’s Threat Detection and Research team published a detailed analysis of the kit in late March, and their findings explain why adoption has been so rapid.
The kit provides affiliates with self-hosted phishing page templates impersonating Adobe Acrobat Sign, DocuSign, SharePoint, OneDrive, and several other trusted services. Each template includes a decoy page with a verification code, instructions for the victim, and a “Continue to Microsoft” button that opens the legitimate device login page in a popup. The phishing page HTML is delivered as an encrypted payload using AES-GCM decryption via the Web Crypto API, which makes it harder for security tools to inspect the content before it renders.
Beyond the phishing pages, EvilTokens includes post-compromise tooling: email harvesting, reconnaissance capabilities, a built-in webmail interface, and AI-powered automation for prioritizing high-value mailbox content (finance-related emails, wire transfer requests, executive communications). This is a complete BEC platform, not just a phishing kit.
By late March 2026, researchers tracked over 1,000 domains hosting EvilTokens phishing pages. The kit’s operator has stated plans to extend support to Gmail and Okta, which would expand the attack surface well beyond Microsoft 365.
EvilTokens isn’t alone. Push Security is tracking at least 10 additional kits offering device code phishing:
- VENOM: A closed-source PhaaS offering both device code phishing and AiTM capabilities
- SHAREFILE: Themed around Citrix ShareFile document transfers
- CLURE: Uses rotating API endpoints and SharePoint-themed lures
- LINKID: Leverages Cloudflare challenge pages with Microsoft Teams and Adobe lures
- DOCUPOLL: Mimics DocuSign workflows with injected replicas of real pages
The variety of kits and lure themes means defenders can’t rely on signature-based detection for a single kit. The attack pattern itself is the common thread.
Who’s Using It#
The adoption curve for device code phishing tracks a familiar pattern: state-sponsored actors pioneer the technique, then commodity kits make it accessible to financially motivated criminals.
Proofpoint has tracked multiple state-aligned threat clusters using device code phishing since at least September 2025, with the technique most widely adopted by state-aligned actors. A threat cluster designated UNK_AcademicFlare has been targeting government, academic, and transportation sectors in the US and Europe using compromised email accounts and spoofed OneDrive links.
On the financially motivated side, Proofpoint identified a high-volume credential phishing actor tracked as TA2723 adopting the technique in October 2025. ShinyHunters, the data extortion group, has also been linked to device code phishing campaigns.
The social engineering lures are tailored to specific industries. Construction firms receive fake bid solicitations. HR departments get salary adjustment notifications. Finance teams see DocuSign requests for contract signatures. The lures are contextually appropriate and, combined with the legitimate Microsoft authentication flow, create a high-success-rate attack chain.
The PCI DSS Connection#
For organizations with Microsoft 365 in scope for PCI DSS, device code phishing creates specific compliance considerations.
Requirement 8.3.1 requires MFA for all non-console administrative access to the cardholder data environment. If an attacker compromises an administrator’s Microsoft 365 account via device code phishing and that account has any access to CDE-connected systems, the MFA control has been bypassed entirely. The requirement is met on paper (MFA is configured), but the control provides no protection against this attack vector.
Requirement 8.6 addresses authentication for application and system accounts. If Microsoft 365 service accounts or application registrations use the Device Authorization Grant flow, those flows should be evaluated as part of the authentication control assessment.
Requirement 12.10.1 requires an incident response plan that addresses specific types of incidents. Device code phishing compromises require a different remediation workflow than traditional credential theft. If your IR plan says “force password reset” as the primary remediation for account compromise, it’s incomplete for this attack class. Refresh token revocation and session invalidation must be explicit steps.
What to Do About It#
The defensive playbook, in priority order:
Disable the Device Authorization Grant flow where it’s not needed. This is the most effective mitigation. In Microsoft Entra ID, create a Conditional Access policy that blocks the device code authentication flow for all users except those who explicitly require it (IoT device administrators, kiosk deployments). Microsoft provides an authentication flow control in Conditional Access specifically for this purpose.
Monitor for device code authentication events in sign-in logs. Look for sign-ins using the “Device code” grant type, particularly from unexpected IP addresses, geolocations, or user agents. These events should be rare in most environments. If you see them and you haven’t deployed IoT devices recently, investigate immediately.
Train users on what device code authentication actually is. Most users have never encountered the microsoft.com/devicelogin page and don’t understand what entering a code there authorizes. Security awareness training should specifically cover this scenario, including the fact that completing the flow grants full account access to whatever device initiated the request.
Update your incident response playbook. If an account compromise is suspected, don’t stop at a password reset. Revoke all refresh tokens and active sessions in Entra ID. Check for newly registered devices. Review the sign-in logs for device code grant events. If a PRT was issued, the attacker may have SSO access across the entire Microsoft 365 environment.
Deploy token protection policies. Microsoft’s token protection feature (in preview as of early 2026) binds tokens to the device that requested them, which would prevent an attacker from using tokens obtained through device code phishing on a different machine. This is worth evaluating if your Entra ID licensing supports it.
Inspect phishing lures for device code patterns. The common indicators are: an alphanumeric code displayed on a page, instructions to visit microsoft.com/devicelogin, and a “Continue to Microsoft” button that opens a popup to the legitimate Microsoft login page. If your email security gateway or phishing simulation platform doesn’t test for this pattern, it should.
The Bigger Picture#
Device code phishing is a structural problem, not a configuration oversight. The OAuth 2.0 Device Authorization Grant was designed for a world where the device requesting access and the user performing authentication are separate. That separation is a feature for smart TVs and IoT devices. It’s a vulnerability when an attacker can position themselves as the “device.”
The 37x surge in 2026 reflects the natural consequence of commoditization. When a technique goes from state-sponsored tradecraft to a Telegram bot with 24/7 customer support and AI-powered BEC automation, the volume follows.
The uncomfortable truth is that MFA, deployed as most organizations deploy it today, doesn’t protect against this attack. That doesn’t mean MFA is useless. It means the threat model that treats MFA as a sufficient control for account security needs updating.
For security teams and compliance professionals, the action items are clear: disable what you don’t need, monitor what you can’t disable, and update your incident response procedures to account for token-based persistence that survives a password reset.
The attackers have already adapted. The question is whether your defenses have.
