A Phishing Campaign Just Hit 340 Microsoft 365 Organizations in Five Countries — And Your Cloud Admin Panel Probably Cannot Detect It
I got the Huntress report on my desk last Wednesday morning. Read it twice. Then spent the rest of the day auditing every Microsoft 365 tenant I manage. This attack follows a growing trend of identity-layer exploits — similar to what we covered in the HackerOne vendor breach analysis.
Here's the short version: since February 19th, a phishing campaign has been hitting Microsoft 365 organizations across the United States, Canada, Australia, New Zealand, and Germany. Over 340 organizations confirmed compromised. Construction companies, hospitals, law firms, government agencies, nonprofits. The attack uses a technique called device code phishing, and it's insidious because it abuses OAuth — the same authentication framework that powers every "Sign in with Microsoft" button you've ever clicked.
The worst part? The tokens the attackers steal survive password resets. Let me say that again: changing your password does not revoke the attacker's access.
I'm going to walk you through exactly what this attack does, how to check if your organization has been hit, and — most importantly — how to shut the door before someone walks through it. This is the guide I wish I'd had last Wednesday.
What Is Device Code Phishing (And Why Should You Care)
Device code authentication is a legitimate OAuth flow designed for devices that don't have a browser — think smart TVs, IoT devices, or CLI tools. The flow works like this:
- A device requests a code from Microsoft Entra ID
- Microsoft generates a short alphanumeric code
- The user goes to microsoft.com/devicelogin on their phone or laptop
- The user enters the code and authenticates with their credentials + MFA
- The device receives access and refresh tokens
Simple and useful. The problem is that nothing stops an attacker from initiating step 1, then tricking a user into completing steps 3 and 4. And once the user authenticates, the attacker has valid tokens that work until they're explicitly revoked.
I asked my colleague, a penetration tester, whether he'd seen this in the wild before. His answer: "We've been demonstrating this in red team exercises since 2024. What's new is that it's now a productized phishing-as-a-service kit." He was right — Huntress tracked this campaign back to a platform called EvilTokens, which launched on Telegram last month. It has a dashboard, 24/7 support, and customer feedback channels. Let that sink in: the attackers have better customer support than some of the SaaS products I've reviewed on this site.
How This Specific Campaign Works
The phishing chain is disturbingly sophisticated
This isn't your uncle's "click here to verify your account" phishing email. The campaign uses multiple layers to evade detection:
Step 1 — Legitimate redirect services as cover. The phishing URLs are wrapped inside redirect services from Cisco, Trend Micro, and Mimecast. Yes, security vendor redirects. The irony is painful. These trusted domains bypass spam filters because they're supposed to be the good guys.
Step 2 — Multi-hop redirect chain. After the security vendor redirect, the victim bounces through compromised websites, Cloudflare Workers instances, and Vercel deployments. Each hop makes the final destination harder to trace. The attackers are using Cloudflare's workers.dev domain, which many enterprise web filters whitelist because legitimate business tools use it.
Step 3 — Realistic landing page. The victim lands on a page that displays a device code and a "Continue to Microsoft" button. The code is generated in real-time — the attacker's backend fires off the device code request to Microsoft the moment the victim loads the page. No delay, no manual code sharing.
Step 4 — Token capture. The victim enters the code at the legitimate Microsoft device login page, authenticates with their real credentials and MFA, and the attacker captures the resulting tokens from the other end of the OAuth flow.
The lure themes vary: construction bid notifications, DocuSign impersonation, voicemail alerts, Microsoft Forms pages. All hitting the same victim pool through the same Railway.com infrastructure.
Why MFA doesn't save you here
This is the part that makes security professionals lose sleep. The victim completes MFA themselves. Willingly. On the real Microsoft login page. The attacker never touches the credentials directly — they just receive the tokens that result from the authentication. It's like giving someone your house key instead of them picking the lock. The alarm system (MFA) never triggers because the front door was opened with a valid key.
How to Check If Your Organization Has Been Hit
Before you do anything else, run these checks. I spent three hours on this for my own clients, and I found one suspicious sign-in that turned out to be a false alarm. Better safe than sorry.
Step 1: Check sign-in logs for Railway IPs
The campaign originates from a small cluster of Railway.com IP addresses. Look for these in your Microsoft Entra sign-in logs:
162.220.234.41162.220.234.66162.220.232.57162.220.232.99162.220.232.235
In Microsoft Entra (Azure AD), go to Sign-in logs → Filter by IP address and search for the 162.220.232.0/23 range. Any hits deserve immediate investigation.
Step 2: Look for device code authentication events
In your Entra sign-in logs, filter for Authentication Method = Device code. If your organization doesn't use device code authentication for any legitimate purpose (and most don't — when was the last time someone in accounting logged in from a smart TV?), any event here is suspicious.
Step 3: Check token activity patterns
Look for user accounts where sign-in location suddenly changes. Example: a user authenticates from their normal office IP, then within minutes, the same account accesses resources from a Railway IP in a completely different region. That's token replay, not travel.
Immediate Response: If You Find Something
If your audit turns up evidence of compromise, here's your playbook. I ran through this with two clients last week, so this is tested, not theoretical:
1. Revoke all refresh tokens for affected users
This is the single most important action. Password resets alone won't help because the attacker has OAuth tokens, not passwords. In Microsoft Entra:
- Go to the user's profile → Revoke sessions
- Or via PowerShell:
Revoke-AzureADUserAllRefreshToken -ObjectId <user-id> - Or via Microsoft Graph API:
POST /users/{id}/revokeSignInSessions
Do this first. Everything else is secondary.
2. Force password reset anyway
Even though the attack bypasses passwords, reset them. The attacker may have also exfiltrated credentials through the phishing page, and you want to close every door.
3. Review what was accessed
Check the Unified Audit Log for any data access, mailbox rules, or forwarding rules the attacker might have created. I've seen cases where attackers create inbox rules to forward all incoming email to an external address — it's the first thing they do, and it persists until you manually find and delete the rule.
4. Block Railway infrastructure
In your Conditional Access policies, block sign-ins from the Railway IP ranges listed above. You can also block the entire 162.220.232.0/22 CIDR block if you want to be aggressive. Legitimate use of Railway for authentication? Essentially zero.
Long-Term Protection: How to Prevent Device Code Phishing
Disable device code flow entirely
This is the nuclear option, and honestly, I recommend it for most organizations. The device code flow is enabled by default in Microsoft Entra, and most organizations have zero legitimate use for it.
Go to Microsoft Entra → App registrations → Default app settings and disable the "Allow public client flows" option. Or, better yet, create a Conditional Access policy that blocks device code authentication for all users except a specific group that actually needs it (and monitor that group closely).
I did this for three clients last week. Not a single helpdesk ticket. Nobody noticed. That tells you how rarely this flow is actually used in practice.
Implement Conditional Access with strict location policies
If you can't disable device code flow entirely, at minimum require that device code authentication only works from named locations (your office networks, VPN ranges). An attacker initiating the flow from a Railway IP in Singapore won't be able to complete it if your policy requires a known location.
Enable continuous access evaluation
Continuous Access Evaluation (CAE) is Microsoft's answer to token theft. Instead of tokens being valid until they expire, CAE allows Azure AD to revoke tokens in near-real-time based on policy changes. Enable it. It won't prevent the initial compromise, but it dramatically reduces the window an attacker has to operate.
Deploy a phishing-resistant MFA method
FIDO2 security keys and Windows Hello for Business are phishing-resistant because they're bound to the device and domain. They won't help against device code phishing specifically (the user is authenticating on the real Microsoft site), but they reduce your overall phishing attack surface. Every eliminated attack vector matters.
Monitor for EvilTokens indicators
Huntress identified that the EvilTokens platform uses specific patterns: Cloudflare Workers redirects, Railway.com hosting, and particular URL structures. Work with your security team or SIEM provider to create detection rules for these patterns. Huntress published indicators of compromise (IOCs) in their blog — add them to your blocklists.
The Uncomfortable Truth About Cloud Security in 2026
I've been reviewing hosting and cloud infrastructure for years. And here's what this incident drives home: OAuth is simultaneously the most useful and most dangerous authentication framework in enterprise IT.
We built an entire ecosystem of interconnected cloud services on top of OAuth. Single sign-on, API integrations, third-party app connections — all OAuth. And every single one of those integration points is a potential attack surface. The device code flow wasn't designed to be exploited, but it was designed to be convenient, and convenience almost always trades off against security.
The attackers understand this better than most defenders do. EvilTokens launched with a polished dashboard and customer support. They're running a business. And they're targeting the authentication layer because that's where the keys to everything live.
Last Tuesday, around 2 AM, I got a Slack message from a client: "Did we get hit?" We hadn't. But the fact that a nonprofit with 30 employees was worried about a nation-state-level phishing technique tells you something about the state of cloud security. The attacks are getting more sophisticated. The tools are getting more accessible. And the line between "advanced persistent threat" and "script kiddie with a subscription" is blurring fast.
If your organization runs self-hosted infrastructure alongside M365, make sure your file transfer servers are patched too — CISA just added Wing FTP to its exploited list. And enterprises using AI workloads should review these AWS Bedrock attack vectors that exploit similar permission-based trust models.
Audit your tenants. Disable device code flow. Revoke tokens for anyone who looks suspicious. And do it today — because the campaign is still active, and 340 organizations is just the number we know about.
