Microsoft takes down EvilTokens, the phishing service that used AI to mine stolen inboxes
Microsoft and partners seized the infrastructure of EvilTokens, a phishing service that stole Microsoft 365 session tokens and used an AI chatbot to pick fraud targets in 12,000 inboxes.
On September 22, 2026, Microsoft's Digital Crimes Unit and a coalition of partners seized the infrastructure behind EvilTokens, a subscription phishing service that stole Microsoft 365 sign-in tokens from more than 12,000 mailboxes at over 10,000 organizations, then used a built-in AI chatbot to read those mailboxes and decide who to defraud. UK police arrested two suspected operators earlier in September 2026. If your organization runs Microsoft 365 and has not switched off the OAuth device code sign-in flow, that is the one change worth making this week.
What happened, in plain English
EvilTokens abused a legitimate feature of OAuth 2.0 — the open standard that lets apps sign you in — called the device code flow. It exists for devices that are awkward to type on: a smart TV, a conference-room display, a printer. The device shows you a short code, you go to a normal browser on your phone or laptop, enter the code on the vendor's real sign-in page, and the device is then signed in.
EvilTokens simply reversed who benefits. A phishing email pointed the victim at an attacker-controlled page, which in the background asked Microsoft for a live device code and displayed it with a helpful "Copy Code" button. The victim was then sent to the genuine microsoft.com/devicelogin page to enter it. Microsoft's own blog explains why this works: "the session initiating the request is not strongly bound to the user's original context," so the attacker's waiting script — not the victim's browser — collects the resulting access and refresh tokens.
That distinction matters. A token is a signed pass that says "this session is already authenticated." Calling it an "MFA bypass" is not quite right: multi-factor authentication ran correctly. The victim completed it, and handed the result to someone else. And because a password reset does not invalidate tokens, resetting the password alone leaves the intruder signed in.
The AI part is what makes this story different. The service, sold on Telegram for a $1,500 joining fee plus $500 a month, shipped with a chatbot that summarized and translated stolen mail, mapped who reported to whom, flagged trusted relationships, surfaced invoices and wire-transfer threads, and drafted messages impersonating colleagues. Microsoft associate general counsel Steven Masada put it this way: AI "was not simply helping attackers write more convincing messages. It helped them decide who to target, who to impersonate, and how to most effectively exploit" those relationships.
Are you affected? What to do now
You should care if your organization uses Microsoft Entra ID or Microsoft 365. Microsoft reports victims concentrated in the United States, Canada, the United Kingdom, Australia, India and France, across wholesale distribution, construction, financial services, real estate, higher education and healthcare. The lures used 44 interchangeable themes — invoices, requests for proposal, document-signing requests, voicemail and eFax notifications — so "we train staff to spot the invoice scam" is not coverage.
In rough order of value:
- Block the device code flow in Conditional Access. Microsoft's own recommendation is to block it wherever possible. If a genuine need exists, scope the exception narrowly to specific Teams device accounts and exclude the Device Registration Service resource.
- Require phishing-resistant MFA — FIDO2 security keys, or passkeys in Microsoft Authenticator — and block legacy authentication with Conditional Access.
- Turn on sign-in risk policies so risky sign-ins get an automated response rather than a ticket.
- If you suspect a compromise, revoke tokens, don't just reset the password. Call
revokeSignInSessionsfor the user, then add a Conditional Access policy forcing re-authentication. Microsoft notes that standard revocation often invalidates only refresh tokens, leaving existing access tokens usable for up to an hour — which is why it also suggests briefly disabling the account despite the disruption. - Hunt for the persistence steps. Microsoft observed attackers registering a new device to obtain a Primary Refresh Token within about ten minutes of the theft, and creating concealing inbox rules several hours later. Check Entra ID device registrations and joins, and mailbox rule changes, around any suspicious sign-in.
- Watch Microsoft Graph activity. The operators used Graph to map org structure and permissions programmatically. Defender XDR ships named detections for anomalous device code authentication, anomalous token exchange, suspicious device registration after device code phishing, anomalous Graph API activity and suspicious inbox rules created after such a sign-in; Microsoft's blog includes advanced hunting queries and a Sentinel query for phishing link clicks.
- Fix the finance control, not just the mailbox. Microsoft's guidance is blunt: assume that once an inbox is compromised, criminals may understand its contents within minutes. Payment and bank-detail changes must be confirmed on a second, independently obtained channel.
- One awareness point worth adding: a sign-in code you did not personally initiate is never legitimate, even when the page asking for it really is Microsoft's. Staff are trained to check the domain, and here the domain was genuine.
Two caveats. Microsoft published no file hashes, IPs or domains as indicators — the redirect infrastructure ran on Vercel, Cloudflare Workers and AWS Lambda, deliberately blending into normal enterprise cloud traffic, so a blocklist would not have helped much anyway. And if you are not a Microsoft shop, this is still worth a question to your identity provider: the device code flow is an OAuth pattern, not a Microsoft one.
The expert view
The conceptual core is consent-flow abuse, not credential theft. The device code grant intentionally decouples authorization from the session that initiated it, because the whole point is that the authorizing device has no usable browser. Once you accept that decoupling, nothing in the protocol distinguishes "my smart TV asked for this code" from "a stranger's Node.js script asked for this code, and I typed it in." The defensive answer is therefore not better user vigilance — it is turning off a grant type most organizations never needed.
Little of the delivery tradecraft is new. Device code phishing has been documented in both state-aligned espionage and criminal campaigns before this service existed, and phishing-as-a-service with fake CAPTCHAs and multi-stage redirects is a mature market. What is genuinely new is the productization of post-compromise triage. The historic bottleneck in business email compromise was human labour: someone had to read a stolen mailbox in a language they may not speak, work out the org chart, and find the one thread where a payment was plausibly in flight. That is the step the chatbot automates, and Microsoft frames the action accordingly — its 40th court-authorized disruption, and its first against what it calls an end-to-end AI-enabled cybercrime service.
The practical consequence is timing. Defender playbooks often assume days between mailbox compromise and a fraud attempt. Against an operator whose assistant produces a target list and a drafted impersonation in minutes, detection budgets measured in days are simply the wrong unit.
The economics are modest and that is the point: roughly a thousand subscribers, about $1.1 million in service revenue traced by Coinbase, and around $1.7 million in victim losses reported to the FBI, according to CyberScoop's account of Microsoft's announcement. This is not a nation-state budget. It is a small business.
Several things remain unknown. Microsoft has not said which AI models powered the chatbot; OpenAI took part in the disruption, but that does not establish that its models were the ones abused, and no public source says they were. No indicators were released. The arrest date is reported inconsistently: The Hacker News and TechNadu both state that the Metropolitan Police Service arrested two men, aged 32 and 38, on September 11, 2026, and Help Net Security gives the same date, while CyberScoop and The Register place the arrests on September 18, 2026. We follow the September 11 reporting, which carries the most specific detail. The men were released on bail with the investigation continuing, so nothing is proven against them. And takedowns of this kind are usually interruptions rather than endings — the relevant question in three months is whether the same code reappears under a different name.
Official sources
- Microsoft Security Blog — "Unmasking EvilTokens: Getting to the root of device code phishing" (September 22, 2026) — technical analysis, detections, hunting queries and Entra ID guidance
- Microsoft On the Issues — "Disrupting EvilTokens: The AI Chatbot Built for Cybercrime" (September 22, 2026) — the Digital Crimes Unit's account of the legal action
- Coverage: The Hacker News · CyberScoop · The Register · Axios · Help Net Security