EvilTokens did not defeat multi-factor authentication. It made victims complete it

What was disrupted

On 22 September 2026 Microsoft's Digital Crimes Unit and eight partners announced the disruption of EvilTokens, a phishing-as-a-service platform operating since February 2026. Fifty websites were seized under an order from the United States District Court for the Eastern District of Virginia, issued on 15 September 2026 ^[8]. Accounts of the supporting infrastructure differ: Microsoft, as reported by Axios and Help Net Security, describes more than 150 domains disabled ^{[9] [10]}; CyberScoop reports over 175 ^[8]. Two men, aged 32 and 38, were arrested in London and released on police bail pending investigation. Help Net Security and The Hacker News date the arrests to 11 September 2026 ^{[10] [5]}; CyberScoop reports warrants served on 18 September ^[8]. They are not named here.

The partner list is the notable part: Health-ISAC, Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, the Shadowserver Foundation and TRM Labs ^[10]. Steven Masada of Microsoft's Digital Crimes Unit is quoted stating that no single organisation could have disrupted EvilTokens alone, because the service relied on hosting providers ^[10]. Coinbase traced roughly $1.1 million in revenue through more than 1,000 deposits from over 700 addresses; thirteen FBI complaints correlated to the service account for at least $1.7 million in reported losses ^[8].

The technique is the authentication flow working correctly

EvilTokens abused the OAuth 2.0 device authorization grant. The operator initiates a device code request, the victim receives a message containing that code, and the victim enters it on Microsoft's genuine device-login page and completes multi-factor authentication ^{[5] [6]}. The operator then collects the resulting access and refresh tokens. No password is captured. No MFA prompt is bypassed. The victim performs a legitimate authorisation, on legitimate infrastructure, for a device they do not control ^[5].

The grant is specified in RFC 8628, published in August 2019 by Denniss, Bradley, Jones and Tschofenig, and exists to let input-constrained devices — televisions, media consoles, printers — obtain authorisation using a second device with a browser. Its security considerations section names this abuse directly: an attacker could initiate the flow and email instructions to a target user. The specification's stated mitigations are that the authorisation server inform the user they are authorising a device, confirm the device is in the user's possession, display device information so impersonation can be detected, and ask the user to verify the same code is currently displayed on the device ^[4]. Seven years on, the failure mode the authors anticipated is the basis of a commercial criminal service.

Why the usual remediation does not work

The reason this technique outperforms credential phishing is what the operator ends up holding. SpyCloud records that refresh tokens obtained this way remained valid for 90 days of inactivity ^[11]. The Cloud Security Alliance research note is blunter about the consequence: the resulting refresh tokens persist even after a password reset, which complicates remediation ^[12].

That invalidates the standard response. An organisation that detects a compromised mailbox, resets the password and re-enrols MFA has changed nothing the operator depends on. Microsoft's own account of Storm-2372, the state-aligned actor that brought device code phishing into wide use, makes the same point: access persists so long as the tokens remain valid ^[1].

Post-compromise behaviour is consistent across both the criminal and espionage cases. Storm-2372 used Microsoft Graph to search compromised mailboxes for terms including 'password', 'admin' and 'credentials', exfiltrated matching messages, and sent further device code lures internally from the victim's own account ^[1]. The Cloud Security Alliance note records Graph enumeration and device registration as the post-compromise pattern in the EvilTokens campaign ^[12]. The device code itself is short-lived — Microsoft records a 15-minute validity, which produces repeated waves of lures rather than a single attempt ^[2].

The numbers, and where they disagree

Microsoft reports over 12,000 compromised inboxes across more than 10,000 organisations ^{[5] [7]}. SpyCloud, working the same case as a partner, documents over 8,700 unique victims across 6,585 corporate email domains in 79 countries ^[11]. These are different visibility windows rather than competing claims, and both belong in any internal briefing that cites a figure at all.

Two distribution facts are more useful than the totals. SpyCloud found 97.5 per cent of compromised accounts belonged to enterprise domains rather than consumer webmail, and that compromises clustered inside business hours — 09:00 to 17:00 US Eastern on weekdays, weekends accounting for only 5.4 per cent ^[11]. This was not opportunistic spray. Second, the top ten customers accounted for 60 per cent of all unique victims ^{[6] [11]}, against roughly 1,000 customers in total ^[8]. A handful of competent operators produced most of the damage; the platform supplied the rest with 44 customisable phishing kits impersonating document-signing platforms, Microsoft services and cloud providers ^[7].

Named victim geographies include the United States, Canada, the United Kingdom, Australia, India and France ^[9], with BleepingComputer also listing Saudi Arabia and naming wholesale, construction, financial services, healthcare and education as the concentrated sectors ^[7]. The Asia-Pacific presence is real but secondary here. That reflects where the operators sold, not where the technique works: device code flow is enabled by default in Entra ID tenants regardless of jurisdiction.

The trajectory is the warning

A Cloud Security Alliance research note published on 25 March 2026 documented the same campaign at an earlier stage: over 340 Microsoft 365 organisations compromised across five countries, with the activity dated to mid-February 2026 ^[12]. Six months later the count reported at takedown was over 10,000 organisations ^[5]. One technique, one service, and roughly a thirtyfold increase in affected organisations over two quarters.

The delivery side industrialised in parallel. Multi-stage pipelines ran on serverless platforms including Vercel, Cloudflare Workers and AWS Lambda to evade mail gateways ^[5], while authentication polling concentrated on a few Railway.com addresses ^[12]. Microsoft also describes an AI chatbot that analysed compromised inboxes in more than twenty languages to find payment authorisations and trusted relationships, then drafted impersonation messages ^[5]. That reduced operator labour after access was obtained. It is not what obtained the access. The access came from an authentication flow that was switched on.

Actions

• Block device code flow with Conditional Access. Microsoft's own guidance is to get as close to a complete block as possible, audit existing usage, and allow it only for documented and secured cases such as legacy tooling that cannot be updated ^[3].
• Build the policy as Microsoft documents it: all users with emergency access accounts excluded, all resources, Authentication Flows condition set to device code flow, Block access, in report-only mode first. Exclude service accounts and service principals, using Conditional Access for workload identities instead ^[3].
• Query sign-in logs for device code authentication over the previous 90 days. The distinguishing field is authenticationProtocol set to deviceCode ^[12].
• Where compromise is found, revoke sessions rather than resetting passwords. The revokeSignInSessions call is the step that invalidates the refresh tokens; a password reset does not ^[12].
• Monitor device registration and Graph enumeration as post-compromise indicators, not only sign-in anomalies ^{[1] [12]}.
• Move privileged and high-exposure accounts to phishing-resistant authentication. Both Microsoft and SpyCloud name FIDO2 and passkeys as the durable control, alongside risk-based Conditional Access and restricted app consent policies ^{[2] [11]}.
• Also consider blocking authentication transfer, configured through the same Authentication Flows condition, where transferring a session from PC to mobile is not a requirement ^[3].

Domain note

A takedown removes infrastructure. It does not remove a design. Fifty seized sites, 150-odd disabled domains and two arrests have ended one service; the device authorization grant remains enabled in most tenants, the refresh tokens it issues remain long-lived, and the people who bought access to EvilTokens retain the tradecraft. The lesson for cyber operations is narrower than the headline. Identity compromise has moved from stealing what a user knows to collecting what a user has already been issued, and the authorisation the user performed was entirely valid. Defences framed around credentials and MFA prompts do not see that event. Defences framed around tokens, sessions and registered devices do.