EvilTokens: phishing-as-a-service that abuses Microsoft's OAuth device code flow

EvilTokens is a phishing-as-a-service kit, documented by Sekoia at the end of March 2026, that turns the OAuth 2.0 device authorization flow into a way to take over Microsoft 365 accounts. Victims type a code on Microsoft's real login page and complete their real MFA prompt, and the attacker receives the tokens. If your organisation uses Entra ID, or you build CLIs and devices that use device code login, this is the attack to understand.

What happened

Sekoia, working with Mnemonic, described EvilTokens as the only widely sold phishing kit with built-in device code phishing, account takeover tooling and post-compromise features. It is sold on Telegram and under active development, and its author said Gmail and Okta phishing pages were planned. Microsoft later said the service emerged in February 2026 and cost $1,500 upfront plus $500 a month in cryptocurrency.

Lures arrive as PDF, HTML, DOCX, XLSX or SVG attachments containing a QR code or link. They pose as payment confirmations, payroll notices, meeting invites, purchase orders, or DocuSign, SharePoint and Adobe shares, and they mostly target finance, HR, logistics and sales staff. Sekoia saw campaigns in the US, Canada, France, Australia, India, Switzerland and the UAE.

Abnormal Security's analysis described the back end: each customer gets an isolated tenant, a fake Outlook-style webmail client called "MailVault", keyword alerts sent over Telegram, AI summarisation of stolen mailboxes, and token refreshes that can keep access to a mailbox for up to 90 days.

On 22 September 2026 Microsoft announced it had disrupted the service. It seized 50 websites through a US court order and disabled more than 150 related domains. Microsoft tracks the operators as Storm-2992 and says EvilTokens-enabled business email compromise hit more than 12,000 inboxes across over 10,000 organisations. The UK's Metropolitan Police arrested two men in connection with the campaign.

Who is affected

• Microsoft 365 / Entra ID tenants that still allow the device code flow for all users, which is the default unless Conditional Access blocks it.
• Finance, HR, logistics and sales staff, the main targets, because their mailboxes are useful for invoice and payment fraud.
• Organisations relying on MFA alone. The victim completes MFA on Microsoft's site, so push, SMS and app-based MFA don't stop it.

What it means for developers and engineering teams

The device authorization grant (RFC 8628) exists for TVs, CLIs and other devices that can't show a browser. The device asks the identity provider for a device_code and a short user_code. The user opens a verification page on another device and types the code. Meanwhile the device polls the token endpoint until the user approves.

EvilTokens simply plays the role of "the device". Its back end calls Microsoft's /devicecode endpoint, shows the resulting code on a fake Adobe or DocuSign page, and sends the victim to microsoft.com/devicelogin. Once the victim signs in, the back end's polling of /token returns an access token and a refresh token. No password crosses an attacker-controlled page, so URL reputation, password managers and most MFA prompts don't help. Microsoft's codes expire after a short window (about 15 minutes), which is why the kit generates a fresh code when the victim opens the page.

Sekoia notes that in advanced cases the refresh token can be used to register a device in Entra ID and obtain a Primary Refresh Token, which gives quieter, longer-lived access. For anyone building auth: RFC 8628's security section warns about exactly this remote phishing scenario. If you ship device code login in your own product, show the requesting client and location on the approval screen, keep code lifetimes short, and don't use the flow where a normal browser redirect would work.

What to do now

1. Block device code flow with Conditional Access. In Entra ID, create a policy using the Authentication flows condition that blocks "Device code flow" for all users, then exclude only the accounts, devices or locations that really need it.
2. Hunt for use of the flow in sign-in logs, for example in Sentinel or Log Analytics: SigninLogs | where AuthenticationProtocol == "deviceCode". Investigate users who don't normally use CLIs or shared devices.
3. Revoke tokens on suspicion. Use Revoke-MgUserSignInSession -UserId <id> (Microsoft Graph PowerShell), reset credentials and check for newly registered devices and inbox rules.
4. Use phishing-resistant MFA (FIDO2 or Windows Hello for Business) and require compliant devices for sensitive apps, so a stolen token alone gets less.
5. Tell staff the simple rule: never type a code into microsoft.com/devicelogin unless you started the sign-in yourself on a device in front of you.

Related on TechLogHub

• OAuth 2.0: grants, tokens and flows explained
• Authentication
• Clerk vs Auth0: hosted identity providers compared

Sources

• Sekoia: New widespread EvilTokens kit, device code phishing as-a-service (Part 1)
• Sekoia: EvilTokens, AI PhaaS for automating BEC fraud (Part 2)
• BleepingComputer: New EvilTokens service fuels Microsoft device code phishing attacks (1 April 2026)
• Help Net Security: EvilTokens ramps up device code phishing (31 March 2026)
• Abnormal: EvilTokens, turning OAuth device codes into BEC operations
• Dark Reading: Microsoft disrupts EvilTokens device code phishing service