Microsoft 365 Users Targeted by AI-Augmented EvilTokens Phishing Service
EvilTokens abuses the Microsoft 365 device code flow: the victim enters a legitimate code on Microsoft's own genuine sign-in page, which is why URL-checking advice fails. Huntress has documented more than 340 organizations affected across five countries since mid-February 2026.
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.
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.
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.
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 is being 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
- 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.
- 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.
- 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.
