EvilTokens compromised more than 12,000 inboxes without stealing a single password. The device code flow did exactly what it was built to do, and that is the whole problem.
The Oldest Trick I Know
Back when I was on the wrong side of the keyboard, the best social engineering never asked anyone for a password. Passwords make people nervous. What worked was asking someone to do something they already did ten times a week, in a place they already trusted, for a reason that sounded boring. Click approve. Read me the number. Hold the door. The victim never felt robbed, because from where they sat, nothing had been taken. They had done their job.
That is exactly the move EvilTokens industrialized. Microsoft’s threat intelligence team says the phishing-as-a-service platform showed up in February 2026 and was used to compromise more than 12,000 inboxes in over 10,000 organizations [1]. On September 22, Microsoft’s Digital Crimes Unit and partners announced they had seized 50 websites and disabled more than 150 domains tied to the service, and London’s Metropolitan Police arrested two men, aged 32 and 38, suspected of running it [2]. Good. I mean that. But nobody should mistake a takedown for a fix, because the thing EvilTokens abused is still sitting in your tenant right now, working as designed.
How the Con Actually Works
The device authorization grant exists for hardware that cannot handle a normal sign-in: smart TVs, printers, conference room gear. The device asks the identity provider for a short user code, shows it to you, and tells you to go type it into a browser on your laptop or phone. You sign in there, the provider links your approval to that code, and the device, which has been polling in the background, collects a token [4]. Two devices, one approval. Elegant.
Now put an attacker where the TV should be. According to Microsoft’s write-up, an EvilTokens lure lands you on a page whose background script requests a live device code from Microsoft in real time, shows it with a “Copy Code” button, and sends you to the genuine microsoft.com/devicelogin page [1]. While you are typing, the attacker’s script checks every three to five seconds whether you have finished, inside a 15-minute window [1]. If you are already signed in, pasting the code and confirming is enough to authenticate the attacker’s session [1]. No fake login page. No credential harvest. No certificate warning. The domain in your address bar is real, because it is Microsoft’s.
Sit with that for a second. The victim authenticated to the correct site, with their real credentials, satisfied their real MFA, and approved the request. Every control that checks who you are passed. None of them asked the only question that mattered, which is where the token was going.
Why Your MFA Rollout Didn’t Save You
I have spent years telling people to get off SMS codes and move to phishing-resistant authentication, and I stand by it. But understand what phishing-resistant means. It stops a fake site from relaying your login, because the credential is bound to the real origin. Here there is no fake origin to catch. The ceremony happens on the legitimate page, so the cryptography is satisfied. Microsoft describes the core weakness plainly: because authentication completes on a separate device, the session that started the request is not strongly bound to the user’s original context [1].
And this is not some zero-day nobody saw coming. The IETF standard that defines the flow, RFC 8628, published in 2019, has a section literally titled Remote Phishing. It describes an attacker starting the flow on a device they control and emailing the target instructions to go enter the code [4]. The standard recommends telling the user they are authorizing a device and confirming that device is in their possession, and it concedes that short code lifetimes do not stop a phisher who is interacting with the victim in real time [4]. It also notes that signals from the approving user’s session are not always relevant to whether the requesting device can be trusted [4]. The designers wrote down this exact attack seven years ago. Then the industry turned the flow on by default and moved on.
That is the part that gets under my skin. We keep calling these things vulnerabilities, like a patch is coming. It is not a bug. It is a delegation feature being used as a delegation feature, by someone you did not mean to delegate to.
What Happens in the First Ten Minutes
The token is the entry fee. What the kit sold was speed afterward. Microsoft says that in some cases operators registered new devices within 10 minutes to generate a Primary Refresh Token for long-term persistence, while in others they waited hours before creating inbox rules or pulling mail, to avoid tripping anything [1]. The platform offered token auto-refresh, admin detection and keyword alerts pushed to Telegram, all for $1,500 up front and $500 a month [1].
Then there is the AI layer, which is getting the headlines. The Register reports the service included a chatbot that could read a compromised inbox and tell the operator whom to target, which contacts to impersonate and which fraud play would pay best [2]. Microsoft says operators used Microsoft Graph to map organizational structure and permissions and went looking for wire details, pending invoices and executive correspondence [1]. The DCU called this its first action against an end-to-end AI-enabled cybercrime service [2].
I want to be careful here, because the AI angle is real but it is not the root cause. The model did not open the door. The human did, through a flow that was allowed to exist. What the model did was compress the part of the job that used to eat an attacker’s afternoon, reading someone else’s email and figuring out who owes whom money, into minutes. Microsoft’s own advice to organizations is to assume that once an inbox is compromised, criminals may understand its contents in minutes rather than days [2]. Your detection window just lost a zero.
The Revocation Problem Nobody Wants to Say Out Loud
Here is the operational detail in Microsoft’s write-up that I would tattoo on every incident responder’s forearm. Standard session revocation often invalidates only refresh tokens, and existing access tokens can stay live for up to an hour, which hands-on operators exploit [1]. Microsoft’s recommendation is to temporarily disable the compromised account for immediate containment, accepting the business disruption [1].
Read that again. The vendor that runs the identity platform is telling you that the button labeled revoke sessions does not fully end the session. If your playbook for a phished user is reset the password and revoke sessions, you have left the attacker an hour of runway, and they only needed ten minutes to register a device. Resetting a password the attacker never had accomplishes exactly nothing. Your response plan has to be written around tokens and devices, not around credentials, because that is where this attacker actually lives.
The Honest Counterargument
I can already hear the objection, and it is fair. Plenty of organizations use this flow legitimately. Conference rooms, shared devices, command-line tools that sign in from a headless box. Blocking it everywhere breaks things, and the people it breaks will be loud about it. Microsoft’s own guidance acknowledges this and tells you to scope exceptions narrowly, for example to specific Teams device resource accounts, rather than leave the flow open to everyone [1].
There is also a reasonable case that the disruption matters more than I am giving it credit for. Knocking out infrastructure and arresting alleged administrators raises the cost of doing business. But BleepingComputer notes this was not a full takedown, that the threat remains active, that at least 10 platforms supported device code phishing by April, and that affiliates have already built clones [3]. The DCU’s own lead said the model will not disappear with the infrastructure [2]. When the people who did the seizure tell you the problem outlives the seizure, believe them.
What I Would Do on Monday
Start by finding out who actually uses the flow. Microsoft’s documentation calls device code flow a high-risk authentication method, recommends blocking it wherever possible, and points you at sign-in logs filtered by authentication protocol, or a policy in report-only mode, to see real usage before you enforce [5]. Most organizations will discover the legitimate population is a handful of room devices and a few engineers. Block everyone else. Carve exceptions by device and account, not by department.
Then treat any cross-device grant as what it is: a transfer of your identity to hardware you have never seen. That event deserves the same alerting you would give a new admin role assignment. A device code sign-in followed by a new device registration, a burst of Graph queries or a fresh inbox rule is not a user doing something quirky. It is a sequence, and it has a known ending.
Finally, rewrite the phished-account runbook so containment means disabling the account and the newly registered devices first and asking questions second. An hour of disruption to one user is cheap. An hour of a live token inside finance is not.
The Real Lesson
Every time the industry hardens the front door, attackers stop picking the lock and start asking the homeowner to open it. We spent a decade making credentials hard to steal, and the market responded by selling tools that never need to steal them. Identity is not just proving who you are anymore. It is controlling what you are allowed to hand to something else, and whether anyone notices when you do. EvilTokens did not beat MFA. It walked around it, through a door the standards body labeled and the rest of us left propped open. Close the door, or at least put a camera on it.
About the Author
Len Noe is a Solutions Architect at BeyondTrust, Transhuman, Podcaster, International Cyber Security Speaker, Author, Technical Evangelist, and Biohacker with 11 implanted microchips. A former blackhat and ex-1% motorcycle club member with more than 30 years in technology, he has presented in over 70 countries and is featured in the documentary I Am Machine, which premiered at DEF CON 2025.
References
- Microsoft Threat Intelligence, Microsoft Defender Experts and Microsoft Security Research. “Unmasking EvilTokens: Getting to the root of device code phishing.” Microsoft Security Blog, September 22, 2026. microsoft.com
- Jessica Lyons. “UK cops arrest 2 EvilTokens suspects, Microsoft seizes 50 phishing kit websites.” The Register, September 22, 2026. theregister.com
- Bill Toulas. “EvilTokens PhaaS disrupted after compromising 12,000 Microsoft accounts.” BleepingComputer, September 22, 2026. bleepingcomputer.com
- W. Denniss, J. Bradley, M. Jones and H. Tschofenig. “RFC 8628: OAuth 2.0 Device Authorization Grant.” Internet Engineering Task Force, August 2019. rfc-editor.org
- Microsoft Learn. “Conditional Access: Authentication flows.” Microsoft Entra documentation, last updated March 24, 2026. learn.microsoft.com