What is device code phishing?

Device code phishing exploits Microsoft's legitimate device authorization flow (RFC 8628) — designed for devices without browsers like smart TVs. Attackers generate a device code, trick the victim into entering it at Microsoft's real login page, and harvest the resulting OAuth tokens. The victim completes MFA themselves, so MFA provides zero protection against this technique.

How did the EvilTokens campaign bypass MFA?

The victim enters the device code on Microsoft's actual login portal and completes their normal MFA challenge. The attacker never sees the password or MFA prompt — they simply poll Microsoft's token endpoint and receive valid access and refresh tokens once the victim authenticates. The tokens are valid for up to 90 days.

Which CIS M365 controls prevent device code phishing?

Block the device code authentication flow via Conditional Access (allow only for identities that genuinely need it). Require compliant/managed devices for M365 access. Enable Continuous Access Evaluation to reduce token revocation latency. Restrict authentication to known network locations for administrative accounts.

Were MSPs specifically targeted in this campaign?

Yes. Over 100 MSPs were affected across the United States, Canada, Australia, New Zealand, and Germany. Sectors hit include construction, law firms, nonprofits, real estate, healthcare, government, and finance. The campaign used AI-generated phishing lures personalized per victim, making pattern-based email filtering ineffective.

Device Code Phishing Just Hit 344 Organizations — Here Are the CIS Controls That Stop It

On February 19, 2026, a Huntress analyst noticed anomalous Microsoft 365 authentication events in a client tenant. By March 23, the campaign had confirmed compromises across 344 organizations, including over 100 MSPs, in five countries. The technique bypassed MFA entirely — not by breaking it, but by making the victim complete it for the attacker.

This was not a novel vulnerability. It exploited a legitimate Microsoft authentication flow that has been available for years, running on infrastructure hosted on a mainstream cloud platform. Every organization hit had MFA enabled. It did not matter.

The controls that would have stopped this attack are in the CIS M365 Foundations Benchmark. Most of the organizations hit had not enabled them.

How Device Code Phishing Works

Microsoft’s device authorization grant (RFC 8628) was designed for devices without browsers — smart TVs, IoT hardware, CLI tools. The flow works like this: the device displays a short code, the user opens a browser on another device, navigates to microsoft.com/devicelogin, enters the code, and authenticates normally. The original device then receives OAuth tokens.

The EvilTokens phishing campaign weaponized this flow:

The victim receives a phishing email — a construction bid, DocuSign notification, voicemail alert, or shared file link. Each lure was AI-generated and unique, defeating pattern-based email filters.
The link passes through legitimate security vendor redirect services (Cisco, Trend Micro, Mimecast) to bypass URL reputation scanning, then through Cloudflare Workers and Vercel intermediaries.
The landing page presents an 8-character device code and instructs the victim to enter it at Microsoft’s real login portal.
The victim navigates to microsoft.com/devicelogin, enters the code, and completes their normal authentication — including MFA.
The attacker’s backend, hosted on Railway.com, polls Microsoft’s token endpoint and receives a valid access token and a refresh token valid for up to 90 days.

The critical detail: MFA is satisfied by the victim themselves. The attacker never intercepts a password, never sees an MFA prompt, never needs to bypass anything. The victim authenticates on Microsoft’s legitimate portal and hands the attacker a fully authenticated session.

What Happened After the Tokens Were Harvested

Token theft was the beginning, not the end. The research from Huntress and corroborating analysis from Arctic Wolf and Sekoia documented the full post-compromise chain:

Immediate enumeration. The attacker used Microsoft Graph API to access the victim’s mailbox, download OneDrive files, harvest contacts, and read calendar entries — all within minutes of token acquisition.

Persistence establishment. Using the refresh token, the attacker registered an attacker-controlled device in the victim’s Entra ID tenant, obtaining a Primary Refresh Token (PRT). A PRT survives standard token revocation. Revoking the user’s sessions does not invalidate a PRT — the attacker maintains access even after the organization responds.

Lateral movement. The attacker sent internal phishing emails from the compromised account to other employees and external contacts. These emails came from a trusted internal address, bypassing external email filtering entirely.

BEC setup. Inbox rules were created to forward sensitive emails to external addresses and hide evidence of the compromise. This is the standard business email compromise playbook — the attacker positions themselves for wire fraud, data exfiltration, or both.

The Scale

This was not a targeted operation against a single organization. EvilTokens is a Phishing-as-a-Service (PhaaS) platform first advertised on the NOIRLEGACY GROUP Telegram channel on February 16, 2026. It sells access to affiliates who run their own campaigns using the shared infrastructure.

The numbers, as of Huntress’s March 23 disclosure:

344 confirmed compromises
100+ MSPs affected
113 additional attempts blocked by Huntress after initial discovery
5 countries: United States, Canada, Australia, New Zealand, Germany
8+ sectors: Construction, law firms, nonprofits, real estate, manufacturing, finance, healthcare, government

The campaign used Railway.com — a legitimate Platform-as-a-Service provider — to host its token polling infrastructure. The primary IP ranges were 162.220.232.0/22 and 162.220.234.0/22, with three specific IPs responsible for approximately 84% of authentication polling traffic.

In response, Huntress pushed a Conditional Access policy update to 60,000 Microsoft cloud tenants it manages, blocking authentication from Railway-associated IP ranges — an unprecedented defensive action at MSP scale.

The CIS Controls That Were Already Available

Every step of this attack chain maps to a CIS M365 Benchmark control that was available before the campaign began. None of them require additional licensing. None of them are difficult to implement. And a formal CIS assessment would have flagged every one as a gap.

Block Device Code Authentication Flow

The device code flow is enabled by default in every M365 tenant. Most organizations have zero legitimate use for it — their users authenticate through browsers and mobile apps, not smart TVs.

The CIS Benchmark recommends restricting the device code flow through Conditional Access. Create a policy that blocks the “Device code flow” grant type for all users, with exceptions only for specific service accounts or device types that genuinely require it. If no one in the organization needs it, block it entirely.

This single control eliminates the entire attack chain. If the device code flow is blocked, the phishing lure has nowhere to go. The victim can enter the code at microsoft.com/devicelogin and nothing happens.

Require Compliant Devices

Even if the device code flow is permitted for specific use cases, Conditional Access can require that the authenticating device be Intune-enrolled and compliant. Device code authentication cannot satisfy device compliance requirements — the flow is inherently designed for devices that cannot run a compliance agent.

This creates a structural barrier: the legitimate use case (a smart TV) can be handled through a narrow exception, while any attempt to use the flow from a browser or unmanaged device is blocked.

Enable Continuous Access Evaluation

Standard OAuth token lifetime in M365 is approximately one hour, with refresh tokens valid up to 90 days. Continuous Access Evaluation (CAE) reduces the revocation latency from up to one hour to near real-time. When a security event occurs — password change, account disable, network location change — CAE propagates the revocation to active sessions within minutes.

In the EvilTokens campaign, the 90-day refresh token window gave attackers persistent access even after initial detection. With CAE enabled, revoking the compromised session would take effect almost immediately instead of waiting for the token to expire.

Restrict Authentication by Network Location

Conditional Access named locations allow organizations to define trusted IP ranges and block or challenge authentication from outside those ranges. For administrative accounts, this should be mandatory — admin access should only originate from known, managed networks.

The EvilTokens attackers authenticated from Railway.com infrastructure (162.220.232.0/22). Any Conditional Access policy blocking admin authentication from non-corporate IPs would have stopped the attack at the login step.

Why This Should Change the MSP Security Conversation

The existing coverage of this campaign — from Huntress, Arctic Wolf, BleepingComputer, The Hacker News, and the Cloud Security Alliance — focuses on the attack mechanics and the immediate incident response. That coverage is excellent and necessary.

What it does not address is the structural question: why were 344 organizations running with a default authentication flow enabled that none of their users needed?

The answer is the same one behind the Stryker wiper attack three weeks earlier — also conducted using legitimate platform capabilities, also preventable with controls that were already available. Organizations do not systematically audit their M365 tenants against the current CIS Benchmark. They configure the environment at deployment, enable the security features they know about at the time, and rarely revisit the configuration unless an incident forces them to.

The CIS M365 Foundations Benchmark exists specifically to close this gap. It tracks the evolving set of security controls available in the platform and provides a measurable standard for evaluating whether they are enabled. A formal assessment against the current benchmark — not a Secure Score export, not a checklist from two years ago — surfaces exactly the kind of default-on, never-reviewed settings that made 344 organizations vulnerable to a phishing kit that any affiliate could purchase on Telegram.

For MSPs managing multiple client tenants, the math is straightforward. If Huntress had to push emergency Conditional Access updates to 60,000 tenants after the campaign was already underway, that means 60,000 tenants did not have those policies in place proactively. A CIS assessment conducted before the campaign would have identified every one of those gaps — and the remediation would have been a configuration change, not an incident response.

What to Check in Your Client Tenants Today

If you manage M365 environments, these are the immediate actions:

Audit device code flow status. In Entra ID, check Conditional Access policies for any policy blocking or restricting the device code authentication flow. If none exists, create one that blocks it for all users with exceptions only for documented, legitimate use cases.
Check for Railway.com IP ranges in sign-in logs. Search Entra ID sign-in logs for authentication events from 162.220.232.0/22 and 162.220.234.0/22. Any hits warrant immediate investigation.
Review Conditional Access for compliant device requirements. Verify that access to Exchange Online, SharePoint, and OneDrive requires a compliant or Entra-joined device. Device code flow cannot satisfy this requirement.
Enable CAE if not already active. Continuous Access Evaluation is available in most M365 license tiers and can be enabled through Conditional Access without disrupting existing sessions.
Check for newly registered devices. In Entra ID, review recently registered devices for any that do not match known endpoints. The EvilTokens campaign registered attacker-controlled devices using stolen refresh tokens.
Audit inbox rules. Check for mail forwarding rules and inbox rules that redirect or hide messages — the standard BEC persistence mechanism.

Genesis delivers CIS M365 Benchmark assessments with 100% control coverage — including every Conditional Access, authentication flow, and token management control discussed in this article.

For MSPs: if the EvilTokens campaign is the first time your clients are hearing about device code phishing, the conversation should not be “here is what happened.” It should be “here is the assessment that would have caught this before it happened — and here is what else we have not checked yet.”