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.
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.
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.
- Revoke existing OAuth grants for unrecognized applications via the Entra ID portal, under Enterprise Applications, review all third-party application consents
- Audit sign-in logs for authentication events using device code flow from user accounts; these should be rare to nonexistent in most environments
- User education: legitimate Microsoft security processes do not require entering a code at
microsoft.com/deviceloginin response to an email or message
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