Commissioned, Curated and Published by Russ. Researched and written with AI.
What’s New This Week
Huntress published detailed findings on March 25, 2026 identifying a campaign active since February 19, 2026 that has compromised 340+ Microsoft 365 organisations across the US, Canada, Australia, New Zealand, and Germany via device code phishing. Sectors hit include financial services, healthcare, government, legal, and construction. Palo Alto Networks Unit 42 independently confirmed a parallel campaign with an earliest observation of February 18, 2026. Huntress has attributed the infrastructure to a phishing-as-a-service platform called EvilTokens, which launched on Telegram last month and is already running 24/7 customer support.
Changelog
| Date | Summary |
|---|---|
| 25 Mar 2026 | Initial publication. |
The Specific Problem
Resetting a compromised user’s password will not invalidate the access tokens this campaign already stole. That is the mechanism this attack is built around.
The OAuth device code flow was designed for input-constrained devices – smart TVs, CLI tools, anything without a convenient browser. The flow works by issuing a short device code to the device, then asking the user to visit microsoft.com/devicelogin on a separate device and enter that code to authorise it. The device polls the token endpoint until the user completes authentication, at which point it receives an access token and a refresh token.
What makes this useful for attackers is that the device code is generated by the attacker, not the victim. Once the victim authenticates against Microsoft’s legitimate endpoint, the resulting tokens are retrievable by anyone who knows the original device code. And because those tokens are tied to the OAuth grant – not to the account password – resetting the password leaves the tokens alive.
Huntress first spotted this specific campaign on February 19, 2026. It has since accelerated.
How the Campaign Runs
The attack chain has several distinct layers, each designed to clear a different detection hurdle.
The phishing email wraps malicious URLs inside redirect services from legitimate security vendors – Cisco, Trend Micro, and Mimecast among them. This gets the message past spam filters and injects perceived legitimacy. From there, a multi-hop redirect chain runs through compromised sites, Cloudflare Workers, and Vercel before landing the victim on the final page.
The landing page itself is hosted on Railway, a PaaS platform. Three Railway IP addresses account for roughly 84% of observed events, according to Huntress. The use of Railway is operationally convenient for the attackers: it provides scalable infrastructure behind a trusted platform domain, reducing the likelihood of outright IP blocking in enterprise environments.
The landing page prompts the victim to visit microsoft.com/devicelogin and enter a device code – but with a variation on the usual approach. Normally the attacker has to convey the device code to the victim via the phishing email itself. In this campaign, the code is rendered directly on the phishing landing page, generated dynamically. The victim sees the code, sees a “Continue to Microsoft” button, clicks it, gets a pop-up to the legitimate Microsoft authentication endpoint, and completes MFA. The attacker retrieves the resulting tokens from the OAuth token API.
Lure techniques in use include construction bid notifications, DocuSign impersonation, voicemail alerts, and Microsoft Forms pages. The variety suggests either a toolkit designed to rotate lures, or multiple threat actors operating via the same EvilTokens infrastructure.
The Anti-Analysis Layer
Palo Alto Networks Unit 42, tracking a parallel campaign from February 18, 2026, noted the phishing pages include active anti-analysis measures. Right-click is disabled. Text selection and drag operations are blocked. Keyboard shortcuts for developer tools (F12, Ctrl+Shift+I/C/J) and source viewing (Ctrl+U) are suppressed. The page detects developer tools via a window-size heuristic and triggers an infinite debugger loop if tools are detected.
This is not standard phishing kit behaviour. These are measures you implement when you expect your targets to have security-aware users, or when you are actively trying to frustrate automated analysis infrastructure.
Who Is Behind This
Huntress attributes the Railway-hosted infrastructure to EvilTokens, a phishing-as-a-service platform that appeared on Telegram last month. The platform provides tools to send phishing emails, bypass spam filters, and generate open redirect links to vulnerable domains. It has a customer dashboard, a feedback channel, and a full 24/7 support operation.
Device code phishing is not new. Microsoft and Volexity identified it in February 2025. Amazon Threat Intelligence and Proofpoint documented subsequent waves. Russia-aligned groups – Storm-2372, APT29, UTA0304, UTA0307, UNK_AcademicFlare – have all used the technique. What EvilTokens represents is the commoditisation of that tradecraft: it has moved from nation-state tooling to a for-hire service with a support desk and customer reviews.
What to Do
The recommended response from Huntress is three steps: scan sign-in logs for Railway IP addresses (the five documented IPs are 162.220.234.41, 162.220.234.66, 162.220.232.57, 162.220.232.99, 162.220.232.235), revoke all refresh tokens for affected users, and block authentication attempts from Railway infrastructure where possible.
The broader control is Conditional Access policy. Microsoft provides a mechanism to restrict device code flow per application via Entra ID. If your organisation has no legitimate use for device code authentication in M365, disabling it removes the attack surface entirely. Most enterprise M365 deployments do not need it.
The harder problem is the token persistence property. If an organisation discovers a device code phishing compromise after the fact, they need to treat it as a full token revocation exercise – not a password reset. Detection based on password change alone will miss active sessions.
The attack is using Microsoft’s own authentication infrastructure. The auth page is real. The device login portal is real. The only thing that is not real is the reason the user was told to visit it.