EvilTokens takedown: 226 domains in the court order, two arrests, and a phish MFA cannot stop

Two hundred and twenty six domains, and not one revoked token

Appendix A of the temporary restraining order signed in Alexandria, Virginia on 15 September 2026 lists 50 domains. Appendix B lists 176. Add them and the order reaches 226 internet names: the public surface of a phishing service that Microsoft says was linked to more than 12,000 compromised inboxes across more than 10,000 organisations in the seven months after it appeared. Microsoft's own announcement rounds the second number down, to 50 websites seized and more than 150 further domains disabled.

The seizure is real and it is unusually thorough. The Appendix A names, the control panels, are to be moved into Microsoft's registrar account within three business days. The Appendix B names, the phishing sites, go on serverHold or an equivalent registry lock, which pulls their delegation out of the top level domain zone file so that ordinary recursive DNS resolution fails. Registry maintained DS and glue records are removed. The registrations stay locked so that logs and registration data survive as evidence.

Now read what the same bundle of paperwork says about the technique itself. In the sworn declaration filed in support of the emergency application, Microsoft states that device code misappropriation "cannot be stopped through multifactor authentication" flows, and that simple password resets will not remove an attacker's access to a compromised mailbox. That is the plaintiff's own evidence, not a critic's gloss.

That gap between a takedown and a tenant is the whole story for a UK security lead. The enforcement action removes an operator's infrastructure. Everything that protects your own mailboxes has to be configured by you, and the control that matters most is one sentence long: block device code flow.

What EvilTokens sold, and what it was not

Microsoft Threat Intelligence tracks the actor behind the kit as Storm-2992 and dates its emergence to February 2026. It was sold on Telegram: 1,500 US dollars to buy in, then 500 dollars a month for continued access to the kit and the control panel, with add on products charged separately. The panel offered 44 template themes, deployment through Cloudflare Workers, Bunny or ordinary PHP hosting, fake CAPTCHA gates, and redirect chains through high reputation serverless hosts so that phishing traffic blends into normal enterprise cloud traffic.

The part Microsoft is marketing as new is the post compromise half. Once tokens were captured, the panel offered auto refresh of those tokens, admin detection, keyword alerting into Telegram, and an assistant that read the mailbox for the buyer. Preset prompts offered to find wire transfer discussions, map the organisation chart, locate vendor invoices, identify the "money movers" and pick the best person to impersonate. The complaint quotes a system prompt that opens: "You are a seasoned BEC (Business Email Compromise) operator and wire transfer fraud specialist." Microsoft says parts of the platform itself were built with AI assistance, and that its operators drew on more than one commercial model, naming Groq in early versions and OpenAI in later ones.

Advertised service tiers and prices, from the civil complaint filed in EDVA case 1:26-cv-3047

Product as advertised	Price	What it did
EvilTokens Office 365 Capture Link	1,500 US dollars, then 500 a month	Token capture, panel access, mailbox dashboard using Microsoft Graph
EvilTokens B2B Sender	600 US dollars a month	Rate controlled bulk sending with role based permissions
SMTP Sender	1,000 US dollars a month	Delivery platform with per sender credential storage and templates
Antibot redirector, Capture Link add ons	Not stated in the filings we read	Evasion of scanners and sandboxes, listed under Essential Tools

One label needs correcting before any of this turns into a purchase order. Microsoft tags its research post with "adversary in the middle", and the complaint calls the operator's position a browser in the middle attack. In the usual sense of the term, an adversary in the middle kit proxies the victim's traffic through a fake sign in page and steals the resulting session cookie. EvilTokens does something different. The victim's credentials go to Microsoft's genuine sign in page, over a genuine TLS connection, and the attacker never sees the password. What the attacker holds is a device code that the victim was persuaded to approve.

The distinction is not pedantry. Controls sold against proxy phishing, including phishing resistant authentication methods, are aimed at a fake page. There is no fake page in this flow.

The arrests: what the police have said, and what they have not

Specialist officers from the Metropolitan Police Service's cybercrime team arrested two men, aged 32 and 38, and seized digital devices and other items for examination. Both were released on police bail subject to conditions while the investigation continues. That is the whole of what Microsoft, which worked with the officers, states in its announcement.

The men have not been named by police, have not been charged, and are entitled to the presumption of innocence. We will not repeat descriptions that could identify them. Press accounts add that the Met received information about the suspects in August 2026, that warrants were executed at addresses in Canary Wharf and Nine Elms, and that the arrests were on suspicion of making articles for use in fraud and of money laundering offences. Making or supplying articles for use in frauds is section 7 of the Fraud Act 2006, which turns on making, adapting, supplying or offering to supply an article knowing it is designed or adapted for use in fraud, or intending it to be so used. An arrest on suspicion is not a charge, and a charging decision has not been announced.

We could not find a statement on the Metropolitan Police news site about this operation. The quotation circulating in coverage, from Detective Inspector Serena D'Adamo, appears to have been given directly to reporters: "Phishing services bring misery to thousands, taking money from everyday people across the world."

The arrests as the record has them. Left column from Microsoft's announcement, right column from what no source we fetched establishes

Stated on the record	Not stated
Two men, aged 32 and 38, arrested by the Met's cybercrime team	Their names, nationalities or residence
Digital devices and other items seized for examination	What, if anything, has been recovered from them
Both released on police bail subject to conditions	The bail conditions, or a return date
Microsoft dates the arrests to 11 September 2026	A Metropolitan Police press release; some coverage says Friday 18 September
Reported suspicion of making articles for use in fraud and money laundering	Any charge, court date or criminal allegation tested in public

The date conflict is worth flagging rather than smoothing over. Microsoft's blog gives 11 September 2026, which was a Friday. Two news outlets describe warrants executed "on Friday" or "last Friday", and The Register states 18 September, also a Friday. We use Microsoft's date, because it is the only one in a first party account, and note that the court's restraining order was signed on 15 September, between the two candidate dates.

The civil mechanism: how a judge in Virginia took the domains

The seizure is not a criminal forfeiture. It is a civil suit, Microsoft Corporation and Health-ISAC, Inc. v. two named individuals and Does 1 to 5, case number 1:26-cv-3047-LMB-WEF in the United States District Court for the Eastern District of Virginia, Alexandria Division. Judge Leonie M. Brinkema granted the temporary restraining order on 15 September 2026 on an ex parte application filed under seal, and ordered the defendants to show cause within 14 days why a preliminary injunction should not follow. Microsoft posted a 25,000 dollar cash bond into the court registry.

The claims are the usual Digital Crimes Unit stack: trademark infringement under the Lanham Act, the Computer Fraud and Abuse Act, the Stored Communications Act and the Electronic Communications Privacy Act, the RICO Act, and tortious interference under Virginia common law. The trademark count does real work. Phishing templates that reproduced the Microsoft, Microsoft 365, Office 365, SharePoint and Outlook marks, including a counterfeit copyright line, are what let a software company sue in its own name over harm suffered mainly by its customers.

Jurisdiction was anchored in Virginia three ways: 106 victim organisations located in the state, Azure virtual machines in Microsoft's Dulles data centre, and the presence of Verisign, Public Interest Registry and Cloudflare. Health-ISAC, a non profit with roughly 1,100 health sector members, joined as co plaintiff because healthcare organisations were among those hit. The order then leans on the All Writs Act to direct US registries, registrars, data centres and hosting providers to assist, and asks registrars outside the court's reach to comply voluntarily.

On the defendants: the complaint names two individuals it says reside in the United Kingdom, alongside three unnamed support staff and two unnamed customers of the service. We are not naming them here. They are civil defendants who have not answered the complaint, the allegations against them have not been tested, and no public source we read connects them to the two men arrested by the Met. Readers should not assume a link.

The restraining order, ECF 16, signed 15 September 2026. Counts of Appendix A and Appendix B are ours, from the published PDF

Ordered	Effect	Limit
50 control panel domains transferred to Microsoft's registrar	Panels made inaccessible to the operators	Only domains the plaintiffs identified before filing
176 phishing domains placed on serverHold, DS and glue records removed	Resolution fails, registrations preserved as evidence	Registrations remain with their holders, not transferred
Hosting providers to isolate content, preserve evidence, stay silent	Infrastructure frozen rather than wiped	Applies to providers with a US presence
Defendants to appear within 14 days on the preliminary injunction	Case moves from ex parte to contested, in principle	Service is by email and by notice published on the domains

Why this phish walks past multifactor authentication

The device authorisation grant exists for devices that cannot show a browser or take typed input: smart televisions, printers, conference room and Teams devices, digital signage. The device shows a short code, the user types that code into a browser on a phone or laptop, and the device receives tokens. Microsoft documents the trade off plainly. Because authentication completes on a separate device, the session that asked for the token is not strongly bound to the user's context.

The kit inserts itself at exactly that seam. On Microsoft's account of the attack chain, a lure lands with an invoice, request for proposal, shared file or password expiry theme. The link opens a page that asks Microsoft's identity platform, in real time, for a live device code for the attacker's own session. The page shows the code, often copies it to the clipboard automatically, and sends the victim to the genuine microsoft.com/devicelogin page. A background script polls the operator's endpoint every three to five seconds across the 15 minute code window. The victim signs in with password and whatever second factor the tenant requires. If the victim already has an active session, they simply paste the code and confirm, and no authentication prompt appears at all. Microsoft's identity platform then issues tokens to the polling session, which belongs to the criminal.

Follow what that means for the controls most UK organisations have bought. The victim was not sent to a lookalike domain, so domain checks do not fire. The victim did not hand a password to an attacker, so password hygiene does not help. The victim did complete multifactor authentication, correctly, on the real page. A passkey or FIDO2 security key binds a credential to the origin it was registered for, and the origin here is Microsoft's own. Our reading of the mechanism is that the passkey works exactly as designed and the attacker still ends up with the tokens. Microsoft does not say this in as many words, but its sworn declaration says the technique cannot be stopped through multifactor authentication flows, and its own mitigation list puts blocking device code flow first and phishing resistant methods lower down under general best practice.

What actually breaks the chain

Microsoft's guidance is unambiguous on the primary control: "Microsoft recommends blocking device code flow wherever possible", and, in the Conditional Access documentation, organisations should get as close as possible to a unilateral block. The condition sits under Conditional Access, Conditions, Authentication Flows, with Block access as the grant control. If Teams room devices need the flow, Microsoft's advice is to scope the exception to those specific device resource accounts and to exclude the Device Registration Service resource rather than to leave the flow open for everyone.

There is a trap in the good news. Microsoft now ships a Microsoft-managed policy called Block device code flow. It is created in tenants automatically in report only state, and Microsoft says it enables such policies no less than 30 days after introduction if they are left that way, with two weeks of notice first. A policy named for a threat, sitting in report only, or switched off by an administrator during a compatibility scare, blocks nothing at all. Check the state, not the name.

Controls against this specific path, from Microsoft Learn. The right column is where the documentation stops short

Control	What it does here	Limit or not established
Conditional Access, block device code flow	Refuses the flow, so the captured code yields nothing	Needs Entra ID P1 or Business Premium; protocol tracking can block later sessions unexpectedly
Microsoft-managed Block device code flow policy	Arrives preconfigured in eligible tenants	Ships in report only, and an administrator can set it to Off
Require a compliant device	An unmanaged machine running the polling client should fail the grant	Our inference from the mechanism; Microsoft documents device code as a route to corporate resources from unmanaged devices
Token protection	Rejects bearer refresh tokens that are not bound to a device	Documented for Exchange Online, SharePoint Online and Teams; Microsoft Graph is not on the supported resource list
Continuous access evaluation	Password reset, account disable or high user risk revoke access in near real time	Up to 15 minutes propagation; SharePoint Online does not support user risk events
Revoke sessions after compromise	Invalidates refresh tokens	Microsoft says access tokens can stay live for up to an hour, so it advises temporarily disabling the account

Two of those rows deserve emphasis because they are where a confident tenant gets caught. Token protection is the control that makes stolen tokens useless, and Microsoft describes it precisely: only sign in session tokens cryptographically bound to a registered device are accepted, and bearer refresh tokens usable from any device are automatically rejected. But the published resource list is Exchange Online, SharePoint Online and Microsoft Teams, with Azure Virtual Desktop and Windows 365 on Windows. EvilTokens read mailboxes through Microsoft Graph, which is not on that list. We could not find documentation stating that token protection is enforced for Graph requests, so we do not claim it is.

The second is the clean up. Microsoft's guidance for a suspected device code compromise is to revoke sign in sessions, then note that revocation often leaves existing access tokens valid for up to an hour, and to disable the account temporarily despite the disruption. Hunt for the persistence that follows: in some incidents attackers registered a new device within 10 minutes to obtain a Primary Refresh Token, and in others they waited hours before creating inbox rules or exfiltrating mail.

// Entra sign-in logs in Log Analytics: who is using device code flow at all?
SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode"
| summarize attempts = count(), apps = make_set(AppDisplayName, 10)
    by UserPrincipalName, ResultType, tostring(LocationDetails.countryOrRegion)
| order by attempts desc

// Same question without KQL: Entra admin centre, Sign-in logs,
// filter Authentication Protocol = Device code, then check the
// Original transfer method property on any blocked sign-in.

Whose numbers these are

Every scale figure in this story comes from one company, which is the plaintiff, the investigator, the identity provider that was abused, and the vendor of most of the fixes. That is not a reason to dismiss the figures. It is a reason to attribute them. The 12,000 inboxes and 10,000 organisations are Microsoft telemetry, unaudited by anyone outside Microsoft. The claim that this is the Digital Crimes Unit's 40th court authorised disruption and its first against an end to end AI enabled criminal service is Microsoft's own framing of its own record. The only third party count in the filings is from the security firm Huntress, cited in Microsoft's declaration as more than 340 organisations compromised across five countries between February and March 2026, and Huntress sells services too.

The mitigations follow the same pattern. Conditional Access, the control that actually closes this path, requires Microsoft Entra ID P1 or Microsoft 365 Business Premium. Risk based policies need P2. Token protection, attack disruption and the detections listed in the research post are Defender and Entra features. A small UK charity or a 40 person manufacturer on a basic Microsoft 365 plan reads that guidance and finds the primary control behind a licence upgrade. Worth saying plainly, without implying that the advice is wrong: it is the correct advice, and it is also a price list.

The coalition partners each published their own account on the same day, which is how these operations are run now: Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, The Shadowserver Foundation, TRM Labs and Health-ISAC. Their participation is useful and their incentives are visible.

What to do, in the order worth doing it

The question that exposes the gap

Microsoft's closing advice to organisations is that once an inbox is compromised, criminals may understand its contents in minutes rather than days, and that requests to change payment details should be verified through a trusted second channel. That is sound, and it is an admission: the assumption behind it is that compromise happens.

So the question for your next identity review is not whether you have multifactor authentication, or even whether it is phishing resistant. It is this. If one of your finance team approved a device code on Microsoft's genuine sign in page tomorrow morning, which control in your tenant would refuse the resulting token, and can you name the policy, its state, and the last date anyone tested it?