Microsoft Dismantles AI-Powered EvilTokens Network Behind 12,000 Email Account Takeovers

Microsoft has disrupted EvilTokens, a phishing-as-a-service platform that turned a legitimate Microsoft authentication mechanism into an industrialized system for email account compromise and business email fraud.

The operation seized 50 websites and disabled more than 150 supporting domains. Microsoft linked the service’s development, operation, and customer support to the threat actor it tracks as Storm-2992.

EvilTokens was associated with more than 12,000 compromised inboxes at over 10,000 organizations worldwide. Rather than stealing passwords directly, the service manipulated victims into authorizing attacker-controlled sessions through Microsoft’s OAuth 2.0 device authorization flow.

Microsoft’s Digital Crimes Unit obtained authorization for the disruption from the U.S. District Court for the Eastern District of Virginia. Health-ISAC, Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, The Shadowserver Foundation, and TRM Labs supported the operation.

A Commercial Platform for Token Theft and Business Email Compromise

Storm-2992 marketed EvilTokens through Telegram as a packaged service for cybercriminals. The operator used messaging channels and bots to advertise products, distribute the phishing kit, announce updates, assist subscribers, and offer cryptocurrency rewards for customer referrals.

The platform emerged in February 2026. Huntress documented it in March 2026, while Sekoia described a turnkey offering sold through Telegram since mid-February. Microsoft subsequently tracked an EvilTokens-aligned campaign in April 2026.

Reported Telegram accounts included the administrator handles @eviltokensadmin, @eviltokensadmins, and @EvilTokenscontact, as well as the store bots @EvilTokens_bot and @EvilTokensStorebot. The operation also maintained the public channel @EvilTokensChannel and a separate Telegram group.

The core kit cost $1,500, followed by a $500 monthly subscription for access to its phishing components and control panel, according to Microsoft’s technical analysis. Other reported products included an Antibot Redirector, B2B Sender, SMTP Sender, and Office 365 Capture Link.

Separate reporting attributed to Sekoia placed the B2B Sender at $600 and the SMTP Sender at $1,000. Those additional prices and reported licensing arrangements were not independently detailed in the available Microsoft advisory.

The customer panel handled far more than phishing-page creation. Subscribers could configure domains and hosting, select page languages and layouts, alter CAPTCHA and redirect behavior, monitor victims, manage stolen tokens, scan mailboxes for selected keywords, and receive alerts through Telegram.

Deployment options included Cloudflare Workers or Bunny infrastructure and conventional PHP hosting. These choices helped customers customize campaigns without building their own delivery or account-takeover systems.

How a Genuine Microsoft Login Became the Phishing Mechanism

The device authorization flow exists for hardware with limited input capabilities, such as smart TVs, printers, Teams devices, and conferencing equipment. A device normally displays a short code, which the user enters in a browser on another system to approve the login.

EvilTokens exploited the separation between the browser performing that approval and the session that originally requested authorization.

The attacker first initiated a device-code request. EvilTokens then delivered the resulting code to a target through a phishing page, persuading the victim to approve a session controlled by the attacker.

Campaigns used 44 lure themes, including invoices, requests for proposals, shared documents, password-expiration warnings, voicemail, eFax messages, payment notices, and document-signing services. Malicious links could be delivered directly or embedded in PDF and HTML attachments.

After following the lure, a victim reached a page containing background automation that communicated with Microsoft’s identity provider and generated a live device code. The page presented a “Copy Code” control and a button labeled “Continue” or “Continue with Microsoft.”

That button sent the victim to the legitimate microsoft.com/devicelogin page. The authentic domain provided credibility that a cloned credential-harvesting page could not.

The victim entered the attacker-generated code and, if necessary, completed the normal password and multi-factor authentication prompts. Microsoft’s authorization service then issued access and refresh tokens to the attacker’s client.

No password had to be disclosed to the EvilTokens operator. MFA also did not stop the compromise because the victim was approving a real authentication request—just not one initiated by the device or service they believed they were accessing.

Stolen Tokens Fed an AI-Assisted Fraud Pipeline

Once EvilTokens obtained valid tokens, its customers could enter the victim’s mailbox, exfiltrate messages, create inbox rules to hide malicious correspondence, and register additional devices. Refresh tokens and active sessions could preserve access beyond the initial intrusion.

The platform also used Microsoft Graph to examine users, roles, permissions, reporting structures, and other organizational relationships. That reconnaissance helped identify employees with financial authority and contacts whose identities would be useful for impersonation.

AI functions were integrated into this post-compromise process. The assistant could inspect mailbox content for vendor invoices, payment approvals, financial discussions, sensitive responsibilities, and people authorized to transfer money.

It could then summarize or translate messages in more than 20 languages, identify trusted relationships, propose fraud strategies, and draft messages that imitated known contacts. Phishing content could be adjusted to the target’s role and the context found inside the mailbox.

This made EvilTokens more than a token-harvesting kit. It combined initial access, mailbox intelligence, target selection, organizational mapping, impersonation, and business email compromise preparation in one interface.

The result lowered the expertise required for targeted fraud. An affiliate did not need to develop an OAuth phishing system, manually review thousands of messages, or understand the victim organization before attempting payment diversion.

Short-Lived Infrastructure Complicated Detection

EvilTokens used layered redirects, fake CAPTCHA checks, and serverless hosting to avoid straightforward domain blocking. Observed infrastructure included Vercel, Cloudflare Workers, and AWS Lambda.

In the campaign Microsoft tracked in April 2026, automation platforms generated thousands of unique, short-lived polling nodes. Complex Node.js backend logic supported the process from live device-code generation through later account activity.

Rapidly changing infrastructure reduced the value of static indicators and simple signatures. A domain identified in one message could disappear or become irrelevant while the same backend workflow resurfaced through another serverless endpoint.

SpyCloud contributed recovered phishing data covering 8,708 unique victim accounts tied to 6,585 corporate email domains in 79 countries. Its earliest recovered captures dated to February 18, 2026.

The largest observed victim concentrations were in the United States, Canada, the United Kingdom, Australia, India, and France. Affected sectors included wholesale distribution, construction, financial services, real estate, higher education, and healthcare.

Partner reporting also attributed approximately $1.1 million in platform revenue to four Tron addresses between October 2025 and June 2026. Coinbase reportedly identified more than 1,000 deposits from over 700 cryptocurrency addresses. Microsoft did not separately quantify those financial findings in its advisory.

Court-Backed Takedown Accompanied by Two Arrests

Microsoft’s Digital Crimes Unit used the Virginia federal court order to seize 50 websites involved in operating EvilTokens and disable more than 150 related domains.

The Metropolitan Police Service arrested two men, aged 32 and 38, on September 11, 2026, in connection with the commercial operation, according to reporting on the coordinated action. Their names were not provided in the available material.

Microsoft published its analysis on September 22, 2026. The takedown removes substantial infrastructure, but no complete list of affected accounts, customer identities, or remaining affiliate-controlled systems has been disclosed.

Organizations should therefore investigate potential exposure rather than treating the infrastructure disruption as remediation for already compromised tenants.

Defenders Must Revoke Tokens, Not Only Reset Passwords

Microsoft recommends blocking device-code authentication wherever it is not operationally required. Organizations can use Conditional Access to disable or tightly restrict the flow.

Where Teams hardware depends on device-code authentication, exceptions should be limited to designated Teams device resource accounts. Microsoft also recommends excluding the Device Registration Service resource from the relevant Conditional Access policy.

Following suspected compromise, defenders should revoke active sessions and refresh tokens, remove unauthorized device registrations, and reset credentials. A password change by itself may leave an attacker’s existing token-backed access intact.

Security teams should also examine:

• Newly registered devices and suspicious OAuth authorizations.
• Malicious inbox rules, hidden messages, and unusual forwarding.
• Abnormal Microsoft Graph queries involving users, roles, permissions, or organizational structure.
• Unsolicited links using serverless platforms such as Vercel, Cloudflare Workers, or AWS Lambda.
• Invoice, RFP, shared-file, password-expiration, payment, voicemail, eFax, and document-signing lures.
• Third-party connectors that could allow spoofed messages to bypass normal mail protections.

Users should treat unexpected instructions to enter a code at microsoft.com/devicelogin as suspicious, even though the site itself is legitimate. The decisive question is whether the user personally initiated an approved device-authentication process.

That distinction was central to EvilTokens: the Microsoft login was real, the code was valid, and MFA worked as designed. The deception concerned whose session the victim was authorizing.