Microsoft EvilTokens Takedown Shifts Identity Triage

Microsoft EvilTokens investigators have disrupted an AI-assisted phishing service that Microsoft linked to more than 12,000 compromised email inboxes across over 10,000 organizations. The September 22 action matters beyond the seized infrastructure: affected companies must treat the event as an identity-compromise investigation, not proof that every stolen session disappeared.

Key takeaways

• Microsoft said a federal court order enabled partners to seize 50 websites and disable more than 150 additional domains tied to EvilTokens.
• The service allegedly abused device-code authentication to obtain valid access tokens, then used AI to analyze inboxes and prepare financial-fraud approaches.
• Microsoft attributed more than 12,000 compromised inboxes at over 10,000 organizations to the platform; those are Microsoft’s investigative figures, not an independently audited census.
• Organizations should revoke sessions, review device registrations and consent grants, inspect mailbox rules, and independently verify payment-change requests.

What did Microsoft disrupt?

Microsoft’s Digital Crimes Unit described EvilTokens as a subscription cybercrime service that combined phishing infrastructure, stolen-session access and an AI-style assistant. According to Microsoft, the assistant did more than draft persuasive messages: it could inspect a compromised inbox, map relationships and payment authority, and recommend impersonation paths that might produce a larger payout.

Microsoft said it obtained authorization from the US District Court for the Eastern District of Virginia. The company and its partners then seized 50 websites and disabled more than 150 other domains supporting the operation. Ars Technica, Axios and Dark Reading independently reported the disruption and its mechanics, while CyberScoop reported additional figures attributed to Microsoft and partners.

The allegations against operators remain allegations. CyberScoop reported that two men arrested in Britain were released on bail while the investigation continues, and that Microsoft’s court filings had not yet been unsealed. That distinction is important: a technical disruption can be verified without treating every attribution or loss estimate as finally adjudicated.

Why device-code phishing survives ordinary password resets

Device-code authentication is legitimate. It lets a device with a limited input interface display a short code that a user completes in a separate browser. The abuse occurs when an attacker persuades a target to enter a code generated for the attacker’s session. The victim signs in on a real Microsoft page, but the resulting token can authorize the attacker-controlled device.

This changes the response sequence. Resetting a password may remove one credential, yet an already issued token, newly registered device, malicious consent grant or hidden mailbox rule can preserve access or operational advantage. Microsoft said EvilTokens used Microsoft Graph after access to identify internal relationships and permissions. That means responders need to investigate the identity and mailbox control plane, not only the endpoint that received the lure.

The Microsoft EvilTokens number needs careful attribution

Microsoft’s headline count—more than 12,000 inboxes across over 10,000 organizations—describes accounts the company linked to the platform. SpyCloud separately said data on more than 8,700 compromised accounts supported the operation. Those figures should not be added together because they can overlap and measure different investigative sets.

Microsoft also said activity was concentrated in the United States, Canada, the United Kingdom, Australia, India and France. For Indian organizations, the practical consequence is direct: global identity campaigns can reach finance, construction, education, healthcare and other sectors without deploying custom malware on every device. A convincing device-code prompt can turn a trusted cloud login flow into the initial-access channel.

CyberScoop reported at least 13 FBI complaints tied by Microsoft to approximately $1.7 million in reported losses, while Coinbase reportedly traced about $1.1 million in platform revenue. These are different measurements—reported victim losses versus alleged service revenue—and should never be presented as the same pool of money.

What security teams should do now

First, search identity logs for unusual device-code sign-ins, unfamiliar device registrations, abnormal token use and access from new geographies. A clean endpoint scan does not close the incident if the attacker authenticated through a valid cloud flow.

Second, revoke active sessions and refresh tokens for suspected accounts. Review OAuth application consent, delegated permissions, multifactor-method changes and registered devices. Then inspect inbox forwarding, transport rules, deleted messages and finance-related searches or exports. These checks look for persistence and for evidence that an attacker studied the organization before attempting fraud.

Third, protect the business process. Payment-detail changes, new beneficiaries and urgent transfer requests should require out-of-band confirmation using a known contact route. The Microsoft EvilTokens case shows why an attacker who can read a genuine conversation may produce a request that passes ordinary language and context checks.

Finally, notify affected people and preserve evidence before bulk cleanup where possible. Microsoft said partners shared indicators and helped identify potential victims. Organizations should retain sign-in logs, mailbox audit records and device-registration history long enough to reconstruct the sequence, while coordinating with legal, privacy and law-enforcement teams where required.

The best reading of the takedown is therefore narrow but consequential: infrastructure was disrupted, arrests were reported and victim notifications began, but the operating model is reusable. Defenders should assume that comparable services will copy the same combination of legitimate authentication flows, session theft, mailbox intelligence and AI-assisted social engineering.

The operational metric to watch is not how many domains went offline on announcement day. It is how quickly each potentially affected organization can prove that suspicious sessions ended, unauthorized devices and grants were removed, mailbox manipulation was reversed, and finance workflows were independently checked. Those outcomes require cooperation across identity administrators, messaging teams, security operations, fraud investigators and accounts payable. A single “password reset completed” ticket cannot demonstrate containment. Leaders should ask for evidence at each layer: the sign-in event that began the incident, the token and device state after revocation, the mailbox changes discovered, the people or payments exposed, and the monitoring rule that would catch a repeat. That turns a public takedown into a measurable local response instead of a comforting headline.

For additional context, see Lapaas Voice’s coverage of Microsoft Patch Tuesday, Microsoft cloud CVEs, NIST cloud-token guidance and CISA cyber decoys.

FAQs

What was EvilTokens?

Microsoft described EvilTokens as a subscription phishing-as-a-service platform that combined device-code phishing, stolen-session access and AI-assisted analysis intended to support business email compromise and financial fraud.

Does the takedown mean compromised accounts are safe?

No. Seizing infrastructure can interrupt the service, but organizations still need to revoke sessions, audit registered devices and consent, inspect mailbox rules, and verify whether attackers used information or access before the disruption.

Why can device-code phishing bypass MFA?

The victim completes a real authentication flow for a code controlled by the attacker. The attacker receives a valid session token, so the event may look like successful authentication rather than a stolen password attempt.

What is the main lesson for finance teams?

Treat email context as potentially compromised. Independently confirm new beneficiaries, payment-detail changes and urgent transfer requests using a known second channel, even when a message appears inside a genuine thread.