What the EvilTokens Takedown Cannot Revoke

Fifty Websites Seized Under a Virginia Court Order

On Tuesday, September 22, Microsoft’s Digital Crimes Unit announced that it had disrupted EvilTokens, a subscription phishing service that investigators linked to more than 12,000 compromised inboxes across more than 10,000 organizations.¹ A federal court in the Eastern District of Virginia authorized the action on September 15. Acting on that order, Microsoft and its co-plaintiff Health-ISAC worked with Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, the Shadowserver Foundation, and TRM Labs to seize 50 websites and disable more than 150 additional domains.^2,3 CyberScoop put the domain count above 175, and that discrepancy has not been resolved publicly. In London, the Metropolitan Police arrested two men, aged 32 and 38, on suspicion of making articles for use in fraud and money laundering, and both were released on bail while the investigation continues.⁴ Microsoft and most outlets date the arrests to September 11, although The Register reported September 18.⁵

Nevertheless, the core facts survive independent scrutiny, which matters because the announcement came from a company that is simultaneously the lead plaintiff and the operator of the identity platform being abused. Coinbase traced roughly $1.1 million in subscription revenue flowing to the operators, and SpyCloud identified 8,708 compromised accounts across 6,585 corporate email domains in 79 countries.^2,6 SpyCloud’s count falls short of Microsoft’s 12,000; however, it comes from a separate dataset and points in the same direction. Furthermore, the threat was well documented long before the seizure. Sekoia first described the kit in March, and by April Microsoft was reporting that the campaign compromised hundreds of organizations every day, with ten to fifteen distinct campaigns launching in each twenty-four-hour period.⁷

The word disrupt deserves more care than most headlines gave it. In the Digital Crimes Unit’s usage, a disruption is a court-authorized civil action against infrastructure, and this one was the unit’s fortieth in nearly two decades and its first against an end-to-end AI-enabled cybercrime service.¹ It took the operators’ websites offline, supported victim notification, and delivered attribution evidence to police, all of which deserve credit. However, a seizure cannot reach backward into a victim tenant, where tokens already issued remain valid until someone revokes them. It also has no effect on the roughly 1,000 criminals who subscribed to the service over its lifetime.²

A Microsoft spokesperson told Axios that the company began warning customers publicly about EvilTokens’ tactics in April and described the eventual operation as relatively accelerated from initiation to execution.⁸ Both statements can be true at once, and neither should be read as evasive. After all, civil litigation, cryptocurrency tracing, and a cross-border police referral take months regardless of urgency. Nevertheless, the service operated for roughly five months after the first public warning, and it compromised thousands of organizations whose authentication controls performed exactly as designed.

The signal The takedown closed a storefront after seven months of trading, while the capability it sold, and the tokens it harvested, sit inside the customer’s own tenant, where only the customer can remove them.

A Real Page, a Real Passkey, and Someone Else’s Session

The OAuth 2.0 Device Authorization Grant exists for hardware that cannot display a normal sign-in prompt, such as conference-room systems, smart displays, and command-line tools. The device shows a short code, the user enters it on a separate device, and the identity provider issues tokens back to whatever client requested the code. The standard that defines the flow, RFC 8628, published in 2019, discusses remote phishing explicitly in its security considerations, so none of this represents an undisclosed defect in Microsoft’s implementation or anyone else’s.⁹

EvilTokens turned that design into a production line. According to Microsoft’s technical analysis, a victim who clicked a lure reached a page that requested a live device code from Microsoft in real time, copied it to the clipboard, and opened the genuine microsoft.com/devicelogin portal in a new window. If the victim already had an active session, pasting the code and confirming the request authenticated the attacker’s session instantly.¹⁰ The victim never typed a password into a counterfeit page, and the browser’s address bar showed a legitimate Microsoft domain throughout.

Therefore, the attack defeats the control that most security programs regard as the finish line. Push Security’s research team states plainly that device code phishing cannot be prevented with authentication controls, including passkeys and other phishing-resistant methods, because the authorization happens after authentication has already succeeded.¹¹ A FIDO2 key verifies that the right person is signing in to the right domain, and both conditions hold in this attack even though the user never started the client waiting for the token. Microsoft’s own mitigation guidance for EvilTokens still recommends phishing-resistant authentication among its general best practices, which remains sound advice against adversary-in-the-middle kits. A board report that lists passkey deployment as the answer to this incident, however, would be describing the wrong layer.

However, the technique itself is several years old. Push traces its first public documentation to 2020, its first confirmed in-the-wild use to August 2024, and its state-sponsored use by Russia-aligned clusters through 2025.¹¹ What changed in 2026 was productization, which turned a specialist technique into a monthly subscription. By Push’s count, detections of device code phishing pages rose 37.5-fold during the year, spread across more than fourteen distinct kits, with EvilTokens the most prevalent.¹¹ Additionally, Microsoft reported that the operators developed portions of the platform with AI assistance and that the finished product drew on capabilities from multiple AI models.²

Ten Minutes From Code to Persistence

Once a code was redeemed, the operator’s options widened quickly. Microsoft observed some operators registering new devices within ten minutes of the compromise to obtain a Primary Refresh Token for long-term persistence.¹⁰ Others waited hours before creating inbox rules or exfiltrating mail in order to avoid immediate detection. Cisco Talos analyzed ARToken, an affiliate panel that shares infrastructure and API contracts with EvilTokens. Its researchers found more than 80 API endpoints covering device code phishing, refresh token persistence, mailbox access, business email compromise operations, and SharePoint exfiltration.¹² Furthermore, many Microsoft first-party applications belong to a family of client IDs whose refresh tokens can be exchanged across the family. A single phished session can therefore extend to Outlook, Teams, OneDrive, and SharePoint without further user interaction.¹¹

Consequently, the instinctive first response to an account compromise, a password reset, accomplishes very little here. Microsoft warned that EvilTokens access could persist after a reset if the associated sessions and tokens were not also revoked.¹³ However, even revocation leaves a gap, since standard session revocation often invalidates refresh tokens while leaving existing access tokens active for up to an hour.¹⁰ Microsoft therefore recommends temporarily disabling the compromised account for immediate containment, despite the business disruption that follows.

The AI layer is what converted access into money at scale. EvilTokens placed a chatbot inside each compromised mailbox that identified trusted relationships, payment authorizations, and the people who controlled funds, then recommended fraud strategies and drafted impersonation messages.¹ Axios reported that this condensed reconnaissance that could otherwise take several days into a matter of hours.⁸ Steven Masada, who leads the Digital Crimes Unit, drew the operational conclusion directly.

“The infrastructure supporting EvilTokens has been disrupted, but the model it demonstrated will not disappear with it.”

— Steven Masada, Associate General Counsel and General Manager, Microsoft Digital Crimes Unit, September 22, 2026

The measured harm is almost certainly a small fraction of the real harm. Microsoft could correlate only thirteen complaints filed with the FBI’s Internet Crime Complaint Center to EvilTokens-linked activity, totaling approximately $1.7 million in reported losses.² The company described that figure as conservative, since many incidents go unreported or cannot be tied to a specific campaign. For scale, the FBI’s 2025 annual report recorded roughly $3.05 billion in business email compromise losses across all reported incidents.¹⁴ The gap between those two numbers is largely an attribution problem, and enterprises should therefore read it as a measure of how little any single victim can know about its own exposure.

Takedowns on Trial: The Tycoon Precedent

The strongest argument for this operation rests on what infrastructure seizures cost criminal operators, including lost domains, disrupted customer relationships, and damaged reputation within the underground market. Victim notification alone has value, since many of the 10,000 affected organizations would otherwise never learn that their tokens had been taken. Critically, this case produced arrests, which distinguishes it from many prior actions. Allure Security, reviewing an earlier takedown, argued that seizures unaccompanied by arrests or physical asset recovery impose costs on attackers without stopping them.¹⁵ Removing the two alleged operators, in addition to their domains, attacks the part of the business that is hardest to rebuild.

Still, the precedent set six months ago counsels caution. On March 4, Europol and Microsoft coordinated the seizure of 330 domains belonging to Tycoon 2FA, the dominant adversary-in-the-middle phishing kit. CrowdStrike reported that Tycoon activity fell to roughly 25 percent of normal on March 4 and 5 and then returned to early 2026 levels within days.¹⁶ Abnormal AI identified a rebuilt deployment on freshly registered infrastructure twenty days after the seizure, with its kill-switch hosting migrated away from the provider the takedown had targeted.¹⁷ Barracuda’s assessment offers the more durable lesson, which holds that attack patterns migrate after a takedown and that detection tied to an individual kit becomes obsolete quickly.¹⁸

Device code phishing already has that kind of redundant supply. The FBI warned in May about Kali365, a separate Telegram-distributed service that captures Microsoft 365 tokens through the same flow.¹⁹ Push has observed Tycoon 2FA itself adding device code phishing alongside its established capabilities.¹¹ Furthermore, the two arrested men have been bailed and not charged, and Microsoft has said that others may have supported the operation.⁴ A security leader should therefore treat the seizure as a temporary reduction in one supplier’s capacity and plan as though the capability remains fully available to anyone willing to pay for it.

Five Identity Providers, Five Different Defaults

Because the flow is standardized, every major identity provider faces the same underlying risk. Their implementations differ considerably, and those differences determine how much an attacker gains from a single redeemed code:

Sources for the table are Push Security, Microsoft, AWS, and Dark Atlas.^11,20,21,22 Google offers the clearest example of containment by design, since restricting the scopes available to the flow removes most of what an attacker would want. AWS moved its command-line default to an authorization code flow with PKCE in version 2.22.0, which binds the sign-in to the local machine, while retaining device code behind an explicit option for headless environments.²¹ GitHub, by contrast, still uses device code as the default sign-in path for its own command-line tool, which normalizes code entry among exactly the developers whose tokens carry repository access.¹¹ Additionally, the technique is well established outside Microsoft, most prominently in a 2025 campaign that combined voice phishing with device code payloads against Salesforce and claimed more than 1,000 compromised organizations.¹¹

Microsoft occupies the most complicated position among the five providers. Its tenants present the broadest post-compromise surface, and Microsoft 365 is where EvilTokens and nearly every comparable kit concentrated. However, Microsoft also offers the most granular administrative control and has moved toward safer defaults. Beginning in February 2025, it rolled out a managed Conditional Access policy that blocks device code flow for tenants that had not used it in the previous 25 days.²³ Each tenant’s policy appears first in report-only mode and switches on automatically after at least 45 days.²³ Microsoft’s documentation describes the flow as rarely used by customers and frequently used by attackers.²⁰

That description invites a fair question about why the flow remains available by default in every tenant that has touched it recently. The answer involves operational constraints, including Teams Rooms hardware, shared devices, and command-line tools such as the Azure CLI. Blocking the flow outright would break legitimate workloads in many developer-heavy organizations. Even so, the tenants most exposed are the ones the managed policy skips, and Conditional Access requires an Entra ID P1 license, which leaves smaller organizations without the primary control.²⁴ Huntress has reported that roughly a quarter of the customers it observes have paid for Conditional Access without configuring it.²⁵ Consequently, responsibility for the remaining exposure is shared, and a customer relying on the vendor’s default has accepted a residual risk it may not have examined.

The AI providers form a quieter part of the story. OpenAI participated in the disruption, and Microsoft said EvilTokens drew on capabilities from multiple AI models while declining to name the others.⁴ Which model provider observes misuse, and whether that provider shares what it sees, remains uneven across the industry, a problem examined in an earlier analysis of how AI misuse monitoring is splitting across providers.

An Authorization Program for the Next Kit

The response that follows from all of this spans identity engineering, incident response, and finance. There are five actions a CISO can take this quarter:

Inventory and restrict the flow. Every identity platform in the enterprise should be reviewed for device code support, starting with sign-in logs that show where the flow is used legitimately today. In Microsoft tenants, the recommended pattern is a Conditional Access policy that blocks device code flow in report-only mode first, followed by enforcement with narrowly scoped exceptions for Teams device resource accounts and an exclusion for the Device Registration Service.^24,26 Blocking device code does not close every door, however, since related techniques such as ConsentFix abuse the authorization code flow and produce equivalent tokens that a device-code-specific policy will not catch.¹¹

Move developers to bound flows. Command-line tools are the largest legitimate source of device code usage and the reason many tenants fall outside Microsoft’s managed policy. Where a tool supports an authorization code flow with PKCE, as the AWS CLI now does by default, that flow should be the standard, with device code reserved for genuinely headless environments and logged as an exception.

Rewrite the token-theft playbook. A compromise response that ends with a password reset is incomplete for this class of attack. The playbook should revoke refresh tokens, disable the account temporarily to cover the access-token window, disable and remove any device registered after an anomalous device code sign-in, and hunt for inbox rules created in the same period.¹⁰

Detect at the authorization layer. The high-signal events are device code sign-ins by users with no history of using the flow, new device registrations that follow them, and unusual Microsoft Graph volume afterward. These events belong in the security operations center’s detection backlog regardless of which vendor supplies the tooling.

Close the payment loop with the CFO. AI-assisted mailbox analysis means that an attacker can understand a finance team’s relationships and pending payments within minutes. Masada’s own advice was to verify requests to change payment details, redirect funds, or approve unusual transactions through a trusted second channel.⁵ That control belongs to accounts payable, and it is the only one on this list that still works after every technical control has failed.

The principle Authentication strength and authorization governance are separate programs, and an enterprise that has funded the first to completion has not yet started the second.

Revocation Belongs to the Customer

The EvilTokens action removed an efficient supplier from a market that already had competitors and will produce more, and it did so after the supplier’s customers had spent seven months collecting tokens from organizations whose MFA deployments worked perfectly. The seizure deserves credit, and the arrests may prove more consequential than the domains. Nevertheless, everything that determines whether the next kit succeeds sits inside the enterprise: whether a flow few employees need remains available to all of them, whether incident response revokes tokens or merely resets passwords, and whether a payment instruction arriving from a trusted inbox is verified through a channel that inbox cannot reach. None of those can be seized by a court order, and each of them can be fixed this quarter by the organization that owns it.

References

1. Steven Masada, “Disrupting EvilTokens: The AI Chatbot Built for Cybercrime,” Microsoft On the Issues, September 22, 2026, https://blogs.microsoft.com/on-the-issues/2026/09/22/disrupting-eviltokens-the-ai-chatbot-built-for-cybercrime/.
2. Matt Kapko, “Microsoft and Partners Disrupt EvilTokens, a Comprehensive Cybercrime Service for Financial Fraud,” CyberScoop, September 22, 2026, https://cyberscoop.com/microsoft-eviltokens-cybercrime-service-takedown/.
3. “Microsoft Disrupts EvilTokens Phishing Service That Gave Criminals Access to 12,000 Inboxes,” Help Net Security, September 23, 2026, https://www.helpnetsecurity.com/2026/09/23/microsoft-eviltokens-phishing-service-disrupted/.
4. “Two Arrested in UK after Microsoft Takedown of ‘EvilTokens’ AI-Chatbot for Cybercriminals,” The Record from Recorded Future News, September 22, 2026, https://therecord.media/two-arrested-in-uk-after-microsoft-takedown-eviltokens.
5. “UK Cops Arrest 2 EvilTokens Suspects, Microsoft Seizes 50 Phishing Kit Websites,” The Register, September 22, 2026, https://www.theregister.com/security/2026/09/22/uk-cops-arrest-2-eviltokens-suspects-microsoft-seizes-50-phishing-kit-websites/5298317.
6. “Microsoft Disrupts EvilTokens Device Code Phishing Service,” Dark Reading, September 22, 2026, https://www.darkreading.com/identity-access-management-security/microsoft-disrupts-eviltokens-device-code-phishing-service.
7. “EvilTokens Device-Code Phishing Kit Totally More Evil Than We All Thought,” The Register, July 1, 2026, https://www.theregister.com/cyber-crime/2026/07/01/eviltokens-device-code-phishing-kit-totally-more-evil-than-we-all-thought/5265409.
8. “Microsoft, Partners Disrupt EvilTokens, AI-Powered Phishing Service,” Axios, September 22, 2026, https://www.axios.com/2026/09/22/microsoft-eviltokens-court-takedown.
9. William Denniss, John Bradley, Michael B. Jones, and Hannes Tschofenig, “OAuth 2.0 Device Authorization Grant,” RFC 8628, Internet Engineering Task Force, August 2019, sec. 5.4, https://www.rfc-editor.org/rfc/rfc8628.
10. 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, https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/.
11. Luke Jennings, “Device Code Phishing Attacks Have Skyrocketed: Here’s What You Need to Know,” Push Security, April 4, 2026, updated August 12, 2026, https://pushsecurity.com/blog/device-code-phishing.
12. “ARToken: Inside an EvilTokens Affiliate Panel Targeting Microsoft 365,” Cisco Talos Intelligence Blog, July 2026, https://blog.talosintelligence.com/artoken-inside-an-eviltokens-affiliate-panel-targeting-microsoft-365/.
13. “Microsoft Takes Down EvilTokens Device-Code Phishing Service Tied to 12,000 Inbox Compromises,” The Hacker News, September 23, 2026, https://thehackernews.com/2026/09/microsoft-takes-down-eviltokens-device.html.
14. Federal Bureau of Investigation, Internet Crime Complaint Center, 2025 Internet Crime Report, as summarized in “The Sobering Truth of the FBI’s 2025 Internet Crime Complaint Center Report,” McDonald Hopkins, 2026, https://www.mcdonaldhopkins.com/insights/news/the-sobering-truth-of-the-fbis-2025-internet-crime-complaint-center-report.
15. “The Tycoon 2FA Takedown and the Limits of Infrastructure Disruption,” Allure Security, April 6, 2026, https://alluresecurity.com/blog/tycoon-2fa-takedown-infrastructure-limits/.
16. “Tycoon 2FA Fully Operational Despite Law Enforcement Takedown,” SecurityWeek, March 23, 2026, https://www.securityweek.com/tycoon-2fa-fully-operational-despite-law-enforcement-takedown/; see also CrowdStrike, “Tycoon2FA Phishing-as-a-Service Platform Persists Following Takedown,” March 20, 2026.
17. “Tycoon2FA Rebounds Post-Takedown with 6 Layers of Obfuscation,” Abnormal AI, May 6, 2026, https://abnormal.ai/blog/tycoon2fa-post-takedown-rebuild.
18. “Threat Spotlight: Tycoon 2FA Didn’t Die—It’s Scattered Everywhere,” Barracuda Networks Blog, April 16, 2026, https://blog.barracuda.com/2026/04/16/threat-spotlight-tycoon-2fa-scattered-everywhere.
19. Federal Bureau of Investigation, Internet Crime Complaint Center, “Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens,” Public Service Announcement I-052126-PSA, May 21, 2026, https://www.ic3.gov/PSA/2026/PSA260521.
20. Microsoft, “Microsoft-Managed Conditional Access Policies for Enhanced Security,” Microsoft Learn, updated August 2026, https://learn.microsoft.com/en-us/entra/identity/conditional-access/managed-policies.
21. Amazon Web Services, “Configuring IAM Identity Center Authentication with the AWS CLI,” AWS Command Line Interface User Guide, accessed September 23, 2026, https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso-tutorial.html; see also aws/aws-cli pull request #8947, “Add the OAuth Authorization Code Flow with PKCE,” merged November 18, 2024.
22. “The Code Is Real, the Device Is Not: The Definitive Guide to Device Code Phishing,” Dark Atlas, July 29, 2026, https://darkatlas.io/blog/the-code-is-real-the-device-is-not-the-definitive-guide-to-device-code-phishing.
23. Microsoft Entra, “New Microsoft-Managed Policies to Raise Your Identity Security Posture,” Microsoft Community Hub, updated March 2025, https://techcommunity.microsoft.com/blog/microsoft-entra-blog/new-microsoft-managed-policies-to-raise-your-identity-security-posture/4286758.
24. Microsoft, “Restrict Device Code Flow for Microsoft Teams Devices with Conditional Access,” Microsoft Learn, May 28, 2026, https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-teams-devices-device-code-flow.
25. “We Need to Talk About Device Code Phishing,” Huntress, June 22, 2026, https://www.huntress.com/blog/tradecraft-tuesday-device-code-phishing-explained.
26. Microsoft, “Block Authentication Flows with Conditional Access Policy,” Microsoft Learn, April 7, 2026, https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows.