Microsoft 365 Users Targeted by AI-Augmented EvilTokens Phishing Service

Correction (August 26, 2026): This article originally described the victim entering the device code on an attacker-controlled page, and overstated the campaign's scale. The code is entered on Microsoft's genuine sign-in page; the campaign affected more than 340 organizations since mid-February 2026; and the primary research is credited to Huntress.

Updated September 23, 2026: EvilTokens has been disrupted. Microsoft's Digital Crimes Unit seized the service's infrastructure on September 22, 2026, four days after London's Metropolitan Police arrested two men alleged to have run its website. Microsoft also now puts the scale at more than 12,000 compromised inboxes across more than 10,000 organizations, far above the April figure this article first reported. The new section below covers what the takedown does and doesn't fix.

A novel Phishing-as-a-Service platform is leveraging Microsoft's device code flow to bypass multi-factor authentication and automate business email compromise at scale.

REDMOND — Security researchers have identified a surge in high-velocity phishing campaigns powered by a new service called "EvilTokens." The platform specifically targets Microsoft 365 environments by abusing the OAuth 2.0 device code flow—a feature originally designed to allow users to sign into accounts on devices with limited input capabilities, such as smart TVs or IoT hardware.

Unlike traditional credential harvesting, EvilTokens does not steal passwords. Instead, the attacker initiates a device code sign-in and social-engineers the victim into entering the legitimate Microsoft-generated code on Microsoft's own genuine device-login page at microsoft.com/devicelogin. That is the defining property of the attack — and precisely why "check the URL" advice fails here: the page the victim lands on is authentic and the certificate is valid. Once the victim approves the request, the service captures the resulting access and refresh tokens, granting attackers persistent access to the mailbox even if multi-factor authentication (MFA) is enabled.

The September 2026 Takedown: What It Fixes and What It Doesn't

Microsoft took court-authorized legal and technical action against EvilTokens on September 22, 2026. Its Digital Crimes Unit seized 50 websites used to run the service and disabled more than 150 additional domains tied to supporting infrastructure, according to Microsoft's announcement. Microsoft calls it the unit's 40th court-authorized disruption and its first against an end-to-end AI-enabled cybercrime service. Partners named in the action include Health-ISAC, Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, the Shadowserver Foundation and TRM Labs.

Four days earlier, on September 18, London's Metropolitan Police Service arrested two men, aged 32 and 38, alleged to have administered the EvilTokens website, The Record reported. Both were released on police bail with conditions while the investigation continues. No charges have been reported.

The numbers moved too. When this article was first published in April, the best public figure was Huntress's count of more than 340 organizations. Microsoft now links EvilTokens to more than 12,000 compromised inboxes across more than 10,000 organizations since the service launched in February 2026, BleepingComputer reported. That figure traces to Microsoft alone. Tanmay Ganacharya, Microsoft's VP of security research, told The Register: "Since March 15, 2026, we have observed 10 to 15 distinct campaigns launching every 24 hours." Microsoft also says the platform offered an AI chatbot that analyzed victims' inboxes to help operators pick targets, choose which trusted contacts to impersonate and select fraud strategies, and that AI was used "at every step of the attack chain."

A Takedown Removes a Vendor, Not a Technique

Our assessment: this won't end device code phishing, and this site's own archive is the evidence. After Microsoft and Europol disrupted Tycoon2FA, the kit came back within about six weeks by pivoting into OAuth device code phishing, the same technique EvilTokens then industrialized. The play has also run under other names: Kali365, which spread it to AWS and Okta, and Forg365. In our coverage over the past year, every disruption of a device code phishing service has been followed by the technique resurfacing under a new brand, usually within weeks. Nothing published so far shows EvilTokens is gone for good, and the method certainly isn't. The control that matters is the one that survives the rebrand.

What to Check Now If You Were in the Blast Radius

A seizure doesn't invalidate a stolen token. Every token EvilTokens operators collected before September 22 was issued by Microsoft's real identity platform to a user who really did pass MFA. Taking down 50 websites removes delivery and control infrastructure; it does nothing to refresh tokens already in an attacker's hands, or to the persistence those tokens were used to set up. If your organization was exposed between February and September 22, 2026, treat the takedown as the trigger for a look-back, not an all-clear.

• Revoke, don't just reset. Confirm refresh tokens and sign-in sessions were revoked for phished users. A password reset alone doesn't invalidate a refresh token that has already been issued.
• Hunt the device code grant. Search sign-in logs for device code authentication on accounts and from locations with no reason to use it. The flow is legitimate but low-volume in most tenants, which makes it a high-signal thing to look for.
• Scope the flow with Conditional Access. Limit device code sign-in to the users and devices that need it. That's the durable fix, and it's covered in more depth in our guide to account takeover prevention and detection.
• Review mailbox persistence. Check inbox rules, forwarding rules and OAuth application consents created since February 2026. Token-theft operations cash out through that persistence, and it outlives the takedown.

Automation and AI-enabled social engineering

The EvilTokens service represents a shift toward the industrialization of MFA bypass. Huntress, which first spotted the campaign on February 19, 2026 and tracked it through disclosure on March 25, 2026, documented more than 340 organizations affected across five countries — the United States, Canada, Australia, New Zealand, and Germany — over roughly five weeks. Microsoft's Defender Security Research Team separately reported observing 10 to 15 distinct campaigns launching every 24 hours since mid-March 2026; that figure is a campaign-launch rate, not a count of affected organizations. The service utilizes AI-augmented templates to craft highly convincing lures that mimic internal IT support notifications or urgent security alerts. These lures walk the user to Microsoft's genuine device-login page with a live device code in hand, tricking the user into authorizing the attacker’s application. (Update, September 23, 2026: the 340-organization count was the picture in April. Microsoft now attributes more than 12,000 compromised inboxes across more than 10,000 organizations to EvilTokens.)

Once the token is secured, the EvilTokens backend automatically scans the compromised inbox for financial keywords, active invoice threads, and executive contact lists. This automated reconnaissance allows attackers to initiate BEC fraud within minutes of a successful login. Researchers have noted that the service also includes features to automatically hide the attacker's activity by creating hidden inbox rules that move suspicious replies to the "Archive" or "RSS Feeds" folders.

The move toward Phishing-as-a-Service (PhaaS)

EvilTokens was marketed on dark web forums as a subscription-based model, lowering the barrier to entry for lower-skilled threat actors. The "kit" handles the hosting of the phishing infrastructure, the rotation of domains to avoid blocklists, and the bypass of standard email security filters. Huntress traced the operators' token-replay infrastructure to the Railway.com PaaS platform, with Cloudflare Workers redirects and abuse of link-rewriting services from Cisco, Trend Micro, and Mimecast to launder the initial lure URLs. Microsoft has issued an advisory noting that while MFA remains a critical defense, "possession-based" protocols like device code flow are increasingly targeted because they reside outside the scope of traditional password-matching defenses.

Security practitioners are seeing a rise in "AitM" (Adversary-in-the-Middle) techniques that render SMS and TOTP-based MFA less effective. Because the EvilTokens attack occurs during a live session, the "MFA fatigue" or traditional prompt-bombing is replaced by a single, seemingly legitimate interaction. Microsoft has reportedly begun rolling out updates to the device code interface to include geographic and application-specific warnings, but the responsibility for restricting this flow currently rests with tenant administrators.

The CyberSignal analysis

Signal 01 — The weaponization of "Convenience" features

Device code flow is a legacy convenience feature that has become a significant enterprise blind spot. Security practitioners should recognize that any authentication flow intended for "low-input" devices is inherently less secure than standard OIDC/SAML flows. In an enterprise environment, the number of users who actually need to sign into M365 on a smart TV is statistically zero, making this an easy surface area to eliminate.

Signal 02 — BEC automation is moving "Upstream"

By integrating automated reconnaissance into the phishing kit itself, EvilTokens shortens the time-to-exploit from days to minutes. This "upstream" automation means that by the time a SecOps team detects an unusual login, the attacker may have already modified payroll details or sent out fraudulent invoices. Detection must move from "post-compromise" to "flow-specific" blocking.

Signal 03 — The end of the "Check the URL" era

Social engineering is evolving past the need for a "fake" login page. Because the user is entering the code into a legitimate Microsoft URL (microsoft.com/devicelogin), traditional user training that focuses on checking the browser's address bar will fail. Security teams must pivot their training to focus on why a user is being asked to perform a specific authentication action, rather than just where they are performing it.

What to do this week

1. Disable Device Code Flow via Conditional Access. Unless your organization has a documented business need for users to sign in on headless devices, create a Conditional Access policy to block the "Device Code Flow" protocol entirely.
2. Audit for "Risky" Service Principals. Use the Microsoft Entra ID (formerly Azure AD) portal to search for service principals or applications that have been granted "Office 365 Exchange Online" permissions through a device code login in the last 30 days.
3. Hunt for specific "EvilTokens" inbox rules. Run a tenant-wide PowerShell script to identify inbox rules that move incoming mail to obscure folders like "Deleted Items," "RSS Subscriptions," or "Conversation History," as these are classic markers of an automated BEC takeover.

Sources