Someone built a phishing service that bypasses MFA completely, uses three different LLMs to analyze stolen inboxes and generate targeted business email compromise attacks in 20+ languages, and charged $1,500 plus $500 a month for access. It ran for seven months. Microsoft's Digital Crimes Unit and UK Metropolitan Police finally shut it down on September 22, with two arrests and 200 domains seized. The service was called EvilTokens, and the attack vector it commercialized is one most security teams still haven't blocked.
The OAuth Device Code Problem
OAuth 2.0 Device Authorization Grant (RFC 8628) exists for a reasonable purpose: letting input-constrained devices like smart TVs and IoT terminals authenticate against identity providers. You open a browser on your phone, navigate to microsoft.com/devicelogin, punch in a short code, authenticate with your credentials and MFA, and the device polls until it gets a token.
The security model relies on a critical assumption: the user knows which device they're authorizing. In practice, they don't. The authorization step and the authentication decision are deliberately decoupled across two different devices. The flow never requires the user to identify the application being authorized. You type a code, you authenticate, you click "Continue." The token goes wherever the code came from.
EvilTokens turned this into a pipeline. The phishing email impersonates Adobe Acrobat, DocuSign, or a voicemail notification. It tells the target to enter a code at the real Microsoft login page. The target does what they've been trained to do: they authenticate at a legitimate domain with their real credentials and their real MFA token. They complete every step correctly. The access token still goes to the attacker's OAuth client.
Here's what makes this worse than traditional credential phishing: the resulting refresh tokens maintain 90-day rolling validity windows that reset with each use. They survive password changes. The only way to kill them is an explicit call to revokeSignInSessions in the Microsoft Graph API. Most incident response playbooks don't include that step.
Three LLMs, One Kill Chain
The phishing itself is just the front door. What EvilTokens did after compromise is where the AI component earned its subscription fee.
Once the operators had valid tokens for a target inbox, three separate language models processed the stolen emails:
Meta Llama 3.1 (8B) ran first, ingesting up to 5,000 harvested emails per compromised inbox. Its job was triage: identify which contacts have financial authority, which threads involve active transactions, which relationships have enough trust to exploit. The 8B parameter model is fast enough to process thousands of messages without burning through compute budgets.
OpenAI GPT-4o mini handled translation. Stolen emails in French, German, Arabic, Hindi, or any of 20+ languages got translated into English so the downstream models could analyze them. This is the step that turns a regional phishing operation into a global one. A traditional threat actor needs human operators who speak the target's language. EvilTokens needed a $0.15/million-token API call.
Meta Llama 3.3 (70B) generated the Business Email Compromise messages. It took the triage results from the 8B model and drafted contextually appropriate emails matched to the victim's role, writing style, and active business relationships. A CFO gets a different email than an accounts payable clerk. The model had enough context from the stolen inbox to mimic internal communication patterns.
The entire pipeline ran on Railway.com, a platform-as-a-service provider. The operators managed concurrent authorization polling across parallel campaigns from a single dashboard. If you're building legitimate AI agent workflows, you'd recognize the architecture. Research-analyze-act, with specialized models at each step. The EvilTokens developers apparently read the same agent orchestration literature the rest of us did and applied it to inbox exploitation.
This is worth sitting with for a second. The tools are the same ones any practitioner uses to build automation. Llama 3.1, GPT-4o mini, Railway for hosting. The difference is the target of the automation, not the automation itself. Anyone building agent pipelines with the AI Automation Playbook workflow recognizes the architecture: task decomposition, model-size-appropriate routing, parallel execution. EvilTokens just pointed it at crime.
The Infrastructure
EvilTokens launched commercially in mid-February 2026. The operators sold access through a private Telegram channel that reached approximately 280 subscribers by March 19.
The pricing structure tells you something about the target market:
- $1,500 one-time fee plus $500/month for the Office 365 device-code phishing kit
- $600 for the B2B sender module
- $1,000 for the SMTP sender
- $500 lifetime license for the multi-account management portal
This isn't a sophisticated state actor pricing model. It's SaaS for mid-tier cybercriminals. The operators were selling capability to people who couldn't build it themselves. By the time Microsoft identified over 1,000 phishing domains on March 23, the platform had compromised 12,000+ inboxes across 340+ Microsoft 365 organizations spanning financial services, healthcare, government, construction, manufacturing, legal, and nonprofit sectors in the US, Canada, France, Australia, India, Switzerland, and the UAE.
Forty-four pre-built phishing themes. Templates for every major document-sharing service. Automated account compromise and token management. The EvilTokens operators understood product-market fit.
What the Takedown Actually Disrupted
Microsoft's Digital Crimes Unit filed a court-authorized lawsuit, their 40th disruption action and the first targeting an end-to-end AI-enabled cybercrime service. They partnered with Health-ISAC to obtain authorization, then worked with Cloudflare, Coinbase, The Shadowserver Foundation, and TRM Labs to execute.
The results: 50 websites dismantled, 150 additional domains disabled, two men aged 32 and 38 arrested by the Metropolitan Police Service's cybercrime team in the UK. Both were released on bail.
Microsoft called out the connection to Storm-2372, a threat actor they assess with moderate confidence as aligned with Russian state interests. Storm-2372 pioneered device-code phishing campaigns from at least August 2024 through February 2025, targeting government, defense, telecom, healthcare, and energy sectors. They combined social engineering through Teams, WhatsApp, and Signal with device-code lures. EvilTokens commercialized what a state-sponsored actor developed.
The takedown matters, but the technique is out. Push Security documented a 37.5-fold increase in device-code phishing detections by September 2026, primarily driven by EvilTokens activity. Taking down one platform doesn't un-teach the method.
Blocking Device Code Flow
If you run a Microsoft 365 environment and haven't explicitly disabled the Device Authorization Grant for users and applications that don't need it, you're exposed to exactly this attack.
The fix is a Conditional Access policy:
- Open the Microsoft Entra admin center
- Navigate to Protection > Conditional Access > Policies
- Create a new policy targeting All Users (or start with a scoped group)
- Under Conditions > Authentication flows, select Device code flow
- Under Grant, select Block access
# Verify no legitimate device-code apps exist first
az ad app list --filter "requiredResourceAccess/any(r:r/resourceAppId eq '00000003-0000-0000-c000-000000000000')" --query "[].{name:displayName, id:appId}" -o table
For already-compromised accounts, a password reset alone is insufficient. Refresh tokens survive password changes. You need:
# Revoke all sessions for a specific user
Revoke-MgUserSignInSession -UserId "user@domain.com"
# Or via Graph API
POST https://graph.microsoft.com/v1.0/users/{id}/revokeSignInSessions
Restrict device-code polling to documented corporate IP ranges via Conditional Access network policies. Audit your tenant for any OAuth applications using the device code grant type that you didn't explicitly provision. And if you have the budget, move executives, administrators, and anyone with financial authority to phishing-resistant authentication: FIDO2 hardware keys or passkeys. Device-code phishing doesn't work against hardware-bound credentials.
The Uncomfortable Part
The strategic problem isn't EvilTokens. The strategic problem is that OAuth device authorization was designed to be convenient, and convenience features in authentication protocols become attack surface the moment someone figures out the trust gap. EvilTokens figured it out. So did Storm-2372 before them. The next group already has.
Device-code phishing is up 1,500% in 2026. The AI layer makes it scalable across languages and contexts in ways that manual operations never could. And the tools to build it are the same tools sitting on your workstation right now.
If you want a structured threat intelligence workflow for tracking these campaigns as they evolve, I put together a research pipeline system over at numbpilled.gumroad.com that covers automated intel collection, analysis templates, and session logging without the subscription overhead.
Written with AI assistance. Technical content, methodology, and voice are mine.
Top comments (0)