Most of the security advice you’ve heard about protecting your Microsoft 365 accounts includes using a strong password and turning on MFA. That combination stops the vast majority of credential-based attacks, and it’s still good advice.
EvilTokens is a good reason to understand where that advice isn’t quite enough.
On September 22, 2026, Microsoft’s Digital Crimes Unit disrupted EvilTokens, “a powerful cybercrime platform that used AI at every step of the attack chain.” It had been running since February and was linked to more than 12,000 compromised inboxes at over 10,000 organizations across 79 countries.
Authorities arrested two suspects in the UK on September 11, 2026. Microsoft seized 50 websites and disabled more than 150 supporting domains.
It’s important to note that EvilTokens didn’t steal passwords or intercept MFA codes. Victims entered their credentials on a legitimate Microsoft page, completed their MFA prompt normally, and still gave the attacker full access to their inbox. This worked because the AI-style chatbot could analyze a victim’s inbox and help criminals identify trusted relationships and circumstances where fraud was most likely to succeed.
Let’s look at how this all worked.
How Device Code Phishing Actually Works
To understand why this attack bypasses MFA, you need to understand what device code authentication is and why it exists.
Device code sign-in was built for hardware without a keyboard, such as smart TVs, conference room equipment, printers, and devices that need to authenticate to a Microsoft account but can’t display a standard login form. The device displays a short code and a URL. The user goes to microsoft.com/devicelogin on any browser, types in the code, completes their normal sign-in including MFA, and the device gets authenticated. This bypasses normal MFA protections by “decoupling authentication from the originating session.”
In an EvilTokens attack, a victim received a phishing lure, such as an invoice, an RFP, a shared file, or a voicemail notice, that led to a page showing a live device code and a “Continue with Microsoft” button. The victim pasted the code into the real microsoft.com/devicelogin page, completed their own sign-in and MFA, and unknowingly authorized the attacker’s session.
What they didn’t know was that the code they entered wasn’t for their own device; it was for the attacker’s session. By completing that sign-in, they handed the attacker an authenticated session token tied to their account.
What Happened After Getting In
Getting into the inbox was only the beginning. EvilTokens used AI-powered tools to analyze compromised inboxes and identify possible targets, specifically finance and executive staff, wire transfer details, and pending invoices.
This is why the attack is particularly dangerous for small businesses. A compromised inbox is a starting point for impersonating an executive, intercepting a payment, redirecting a wire transfer, or reaching out to customers or vendors as if the attacker were you. The session token gives the attacker ongoing access to the inbox as long as the token remains valid, which, without intervention, can be a long time.
EvilTokens was sold on Telegram for a $500 monthly license fee, giving affiliates access to phishing page code and an active API key for backend integration. Anyone willing to pay could run this campaign against organizations of any size. The targets across those 10,000 organizations weren’t selected for their sophistication or their data. They were selected because the attack worked at scale and small businesses were as easy to hit as large ones.
If your organization runs Microsoft 365, specific settings can significantly reduce your exposure to device code phishing. MainNerve can help you identify what needs to change in your environment. Let’s talk about what that looks like.
Why This Is Harder to Spot Than Regular Phishing
Most phishing attacks have tells. The sender address is slightly off, or the login page doesn’t quite match. The link goes somewhere unexpected. Employees who’ve had any security training know to look for these things.
Device code phishing removes most of those tells. The URL the victim visits IS microsoft.com, and the login page IS Microsoft’s login page. The only thing that’s fake is the reason they were sent there in the first place.
Because the lures, the invoices, shared files, RFP notifications, and voicemail alerts are exactly the kind of emails employees interact with dozens of times a day, employees don’t find the requests suspicious. This makes it a little harder to train employees to watch for.
The Fix Is Simpler Than the Attack
Microsoft’s primary recommendation is to block the device-code flow anywhere it isn’t needed.
For most small businesses running Microsoft 365, the device code authentication flow serves no legitimate purpose for standard users. It exists for hardware devices that can’t do a normal browser-based sign-in. If your employees are signing into email, Teams, SharePoint, or any other Microsoft 365 application from a laptop, desktop, or phone, they don’t need the device code flow. Blocking it removes the mechanism the attack relies on entirely.
This is done through Conditional Access policies in Microsoft Entra ID, formerly Azure Active Directory. Under Authentication flows in a Conditional Access policy, you can block the device code flow for your users. If you’re running Microsoft 365 Business Premium or any plan that includes Conditional Access, this setting is available to you now.
Beyond blocking the device code flow, a few other controls reduce your exposure. You can move toward phishing-resistant MFA. FIDO2 hardware keys and Microsoft Authenticator passkeys bind the credential to the origin, so they aren’t susceptible to device code phishing. Normal push MFA notifications are not phishing-resistant. If your organization uses the Microsoft Authenticator app with push notifications, that’s significantly better than SMS codes but still falls short of phishing resistance. Hardware keys or passkeys are the most effective option.
You can also revoke session tokens, not just passwords, after a suspected compromise. Changing a compromised employee’s password after an EvilTokens attack doesn’t revoke the session token the attacker already has. The attacker stays logged in until the token expires or is explicitly revoked. If you suspect an account has been compromised through this method, resetting the password is not sufficient; the session needs to be terminated separately.
Finally, watch for post-authentication anomalies. Microsoft Defender XDR detects “Anomalous OAuth device code authentication activity” and “Anomalous Microsoft Graph API requests following device code flow authentication.” If you see these alerts, assume a breach has happened and revoke tokens immediately. For organizations without active monitoring, this is another argument for having someone watching your Microsoft 365 environment rather than assuming the defaults are sufficient.
Not sure whether your Microsoft 365 environment is configured to block device code phishing? That’s the kind of gap that shows up in a security assessment, and it’s fixable once you know it’s there. Reach out to MainNerve and let’s take a look.
Â
What the Takedown Does and Doesn’t Mean
Microsoft’s disruption of EvilTokens is good news. Seizing 50 websites, disabling 150+ domains, and arresting two suspects puts a big dent in this specific operation.
Microsoft’s technical analysis identified 14 or more distinct device code phishing kits now in circulation. EvilTokens was the most prevalent, and the takedown removed the most active provider. Â However, it didn’t remove the attack method, the availability of similar tools, or the criminal market EvilTokens served. Someone else will build something similar, probably already has, and the device code flow vulnerability in Microsoft 365 remains exploitable until organizations configure their environments to block it.
EvilTokens ran for seven months before Microsoft took it down. During that time, it compromised 12,000 inboxes across 10,000 organizations. Most of those organizations were running MFA. Most had no idea the device code flow could be exploited.
The lesson isn’t that MFA is useless. MFA stops an enormous volume of credential-based attacks and is still one of the most important controls any organization can deploy. The lesson is that MFA has specific limitations that attackers are now exploiting at scale, and understanding those limitations is the difference between a security posture that accounts for the current threat landscape and one that’s still catching up.
Blocking the device code flow in your Microsoft 365 tenant is a single policy change that removes that limitation. Most small businesses running Microsoft 365 can do that this week. If you want help making sure it’s configured correctly, or if you want to understand what else in your Microsoft 365 environment might be configured in ways that create unnecessary exposure, we’re glad to help. MainNerve has been helping organizations understand and close these gaps for over 20 years. Contact us today for your free consult.
