EvilTokens Campaign: Device Code OAuth Phishing Hits 340 Microsoft 365 Organizations, MFA Is Useless

EvilTokens Phishing-as-a-Service CampaignOAuth Device Code Flow
340+
M365 Orgs Targeted
5
Countries Affected
OAuth
Device Code Exploited
Persistent
Token Access

EvilTokens is a Phishing-as-a-Service operation documented by Huntress in late April 2026. The campaign targeted 340 or more Microsoft 365 organizations across five countries using the OAuth device code flow, a legitimate Microsoft authentication mechanism, as the attack vector. The result is persistent access via tokens that survive password changes and are not stopped by MFA, because from Microsoft's perspective the authentication was entirely user-initiated and legitimate.

The Device Code Flow, and How It Gets Weaponized

OAuth device code flow exists for devices without a keyboard or browser: smart TVs, printers, IoT devices. The device displays a short code and directs the user to visit microsoft.com/devicelogin on another device, enter the code, and complete authentication. Once the user does, the original device receives an OAuth access token and refresh token.

The attack abuses this by generating a device code through an attacker-controlled application registration, then sending the code to the target as an urgent message. The pretext varies: "verify your device to maintain access," "complete security enrollment," or "approve your account before the deadline." The victim visits the legitimate Microsoft URL (this is not a phishing domain), enters the legitimate code Microsoft displayed, and completes normal Microsoft authentication including MFA.

At the moment they submit, the attacker's application receives an access token and a refresh token. The access token expires in one hour. The refresh token does not expire unless explicitly revoked. The attacker can silently refresh access indefinitely, reading email, accessing SharePoint, exfiltrating OneDrive files, and pivoting to other connected applications without ever prompting the victim again.

EvilTokens Device Code Attack Flow
1
App Registration
Attacker registers a malicious OAuth application in Azure AD; requests device code via Microsoft API
2
Victim Delivery
Email, Teams message, or SMS with device code and link to microsoft.com/devicelogin; urgent pretext: "your access expires in 24 hours"
3
Victim Authenticates Legitimately
Target visits real microsoft.com URL, enters the device code, completes standard Microsoft authentication including MFA
4
Token Issued to Attacker App
Attacker's registered application receives access token (1hr) and refresh token (persistent); MFA was completed by the victim, so Microsoft considers this legitimate
5
Silent Persistent Access
Refresh token used to silently obtain new access tokens indefinitely; victim's password change does not invalidate the grant

Railway.com PaaS Hosting: Why Infrastructure Is Irrelevant

EvilTokens operated its campaign infrastructure on Railway.com, a developer PaaS platform. This is significant for defenders because it means the attack required no server provisioning, no VPS, no domain registration with a suspicious registrar. The attacker spun up containers in a managed cloud environment with a legitimate certificate and a railway.app domain.

IP reputation and domain blacklisting are ineffective against this pattern. railway.app is a legitimate domain used by thousands of developers. Blocking it creates operational disruption. Allowing it means attacker infrastructure rides on trusted hosting. This is the same reason attackers use Google Sites, Cloudflare Pages, and GitHub Pages to host phishing content: defense-in-depth that relies on domain or IP reputation breaks against shared hosting.

PaaS-Hosted Attacks

Infrastructure-based detection fails when attackers operate from legitimate PaaS platforms. Railway.com, Render, Fly.io, and similar platforms issue certificates automatically and share reputation with thousands of legitimate developers. Defender strategy must shift to behavioral detection: what does the OAuth grant do, not where did it come from.

Stopping Device Code Phishing

Microsoft provides two primary controls that directly address this attack vector:

Conditional Access policy blocking device code flow: In Entra ID Conditional Access, organizations can block the device code authentication flow entirely for user accounts. Unless your organization actually deploys devices that require this flow (most enterprise environments do not), blocking it removes the attack vector completely. The policy is: Authentication Flows condition, block device code flow, scope to all users or all non-privileged users at minimum.

OAuth application allowlisting: Tenant-level settings control which applications can be consented to by users. Restricting OAuth application grants to admin-approved applications only prevents users from inadvertently granting access to attacker-registered apps. This requires an approval workflow but eliminates the app registration vector entirely.

The five-country targeting (US, Canada, Australia, New Zealand, Germany) suggests EvilTokens is not limiting itself to a single region or industry. If your organization uses Microsoft 365 and has not blocked device code flow, the exposure is live right now.

Is Device Code Flow Blocked in Your Microsoft 365 Tenant?

RedEye Security reviews your Microsoft 365 Conditional Access policies, OAuth application grants, and authentication flow restrictions to close device code and AiTM attack vectors.

Request an Assessment