EvilTokens disruption gives defenders a short window to clean up device-code phishing risk
EvilTokens disruption gives defenders a short window to clean up device-code phishing risk
Executive Summary
Microsoft says it has disrupted infrastructure tied to EvilTokens, an AI-assisted phishing-as-a-service platform that compromised more than 12,000 inboxes across over 10,000 organizations worldwide. The platform abused Microsoft device-code authentication flows to steal tokens, access mailboxes, and support business email compromise operations.
This is a cybercrime story, but the defensive lesson is bigger than one service. EvilTokens shows how attackers can turn a legitimate authentication flow into an account compromise pipeline that does not require victims to hand over their passwords directly. Once a token is approved, attackers can read mail, create inbox rules, search for payment conversations, identify high-value contacts, and prepare fraud attempts with much less friction.
The disruption may reduce campaign volume in the short term, but Microsoft and public reporting both warn that related tooling and clones remain a risk. Defenders should use the lull to disable unnecessary device-code authentication, tighten Conditional Access, revoke suspicious sessions, hunt malicious mailbox rules, and treat token theft as a durable account takeover problem.
What Happened?
On September 22, 2026, Microsoft Threat Intelligence, Microsoft Defender Experts, Microsoft Security Research, and the Digital Crimes Unit published research on EvilTokens and announced a coordinated disruption of infrastructure used to operate the service. Microsoft says the platform emerged in February 2026 and became one of the most widely used phishing-as-a-service operations specializing in device-code phishing.
Device-code authentication is a legitimate OAuth flow designed for devices that cannot easily accept a normal browser login, such as TVs, printers, command-line tools, and constrained devices. In an EvilTokens-style attack, the criminal infrastructure initiates a device-code sign-in process and tricks the victim into entering a code on a legitimate Microsoft sign-in page. Because the victim is interacting with real Microsoft infrastructure, the flow can feel more trustworthy than a traditional credential-harvesting page.
The end goal is not the password. The goal is token access. Microsoft says EvilTokens enabled actors to abuse the device-code flow, steal tokens, compromise organizational accounts at scale, and use AI-assisted tooling to tailor lures and analyze compromised inboxes for high-value fraud opportunities.
According to Microsoft, EvilTokens facilitated business email compromise campaigns that compromised more than 12,000 inboxes across more than 10,000 organizations worldwide. BleepingComputer reported that the coordinated action disrupted infrastructure associated with the phishing service, but also noted that this was not a complete takedown of the threat and that clones such as APToken have already appeared.
Why This Matters
Device-code phishing is uncomfortable because it abuses a flow defenders often allow by default. Users do not necessarily see a fake login page. They may see a real Microsoft prompt, complete MFA, and believe they have satisfied a legitimate request from IT, a collaboration app, or a workflow tool.
For defenders, that changes the cleanup model. A password reset alone may not end the attack if an attacker still has a valid session or refresh token. An inbox can remain useful to criminals even after the original lure is discovered, especially if they have already created forwarding rules, hidden messages, deleted warnings, or mapped financial workflows.
EvilTokens also points to the industrialization of phishing. Microsoft describes a platform with prebuilt templates, landing pages, AI-assisted lure generation, token validation, and post-compromise analysis. That turns device-code abuse into a repeatable service for affiliates, not just a one-off campaign by a skilled operator.
The business impact is direct. Compromised inboxes are valuable because they contain context: invoices, banking instructions, executive conversations, vendor threads, legal documents, customer data, and internal org charts. Attackers can use that context to make fraud requests more credible and to identify the people most likely to approve payments or sensitive changes.
The Attack Chain
The exact lure varies, but the pattern is consistent.
- The victim receives a message that creates urgency or legitimacy, often impersonating a collaboration, document, meeting, HR, finance, or IT workflow.
- The lure directs the victim into a device-code flow and asks them to enter a code.
- The victim completes authentication on a legitimate Microsoft page.
- The attacker-controlled infrastructure receives the token or session access associated with that approval.
- The attacker uses the mailbox for reconnaissance, persistence, internal phishing, invoice fraud, or further identity abuse.
Microsoft reported that stolen tokens were used for email exfiltration and persistence, including malicious inbox rules designed to hide communications. Public reporting also described attackers using Microsoft Graph to accelerate reconnaissance once access was obtained.
This is why device-code phishing should sit at the intersection of identity security, mail security, and fraud prevention. It is not only a user-awareness issue. It is an identity and access management control issue with downstream financial and operational consequences.
What Defenders Should Do Now
1. Disable Device-Code Authentication Where It Is Not Needed
Many organizations do not need broad device-code authentication across the tenant. Review whether the flow is required for legitimate business use, then restrict or disable it where possible through Conditional Access and authentication policy controls.
The practical question is simple: which users and applications truly need device-code login? If the answer is "almost nobody," then leaving it broadly available creates avoidable exposure.
2. Revoke Suspicious Sessions, Not Just Passwords
When a user may have approved a malicious device-code sign-in, password rotation is only part of recovery. Revoke sessions and refresh tokens, require re-authentication, and verify that the attacker no longer has valid access.
Identity teams should review sign-in logs for device-code authentication events, unfamiliar application IDs, unusual geographies, anomalous user agents, impossible travel, and sign-ins followed by Graph API activity or mailbox access patterns outside the user's normal behavior.
3. Hunt Mailbox Persistence
Compromised inboxes often contain the attacker’s persistence layer. Look for:
- newly created forwarding rules;
- inbox rules that move, delete, hide, or mark messages as read;
- suspicious OAuth grants or app consent events;
- mailbox delegation changes;
- unusual searches across invoice, payment, wire, payroll, executive, HR, or legal terms;
- new external forwarding destinations;
- spikes in sent mail, drafts, or deleted items.
These checks belong in the same playbook as business email compromise triage. A clean password reset does not matter much if fraud-enabling rules stay behind.
4. Prioritize Finance and Executive Workflows
EvilTokens is financially motivated cybercrime. Security teams should alert finance, procurement, payroll, legal, and executive assistants when a relevant account is compromised. Fraud attempts often follow the existing rhythm of a real conversation, so the right control may be a phone call, payment hold, or out-of-band verification rather than a purely technical block.
Update payment-change procedures, vendor bank-detail verification, and executive approval workflows to assume that an email thread may already be compromised.
5. Watch For Clones And Copycats
Infrastructure disruption matters, but it rarely kills a profitable criminal pattern. Microsoft and news coverage noted that EvilTokens-like services and clones remain a concern. Defenders should write controls against the technique, not only the brand name.
That means monitoring device-code sign-ins, token grants, mailbox rule changes, and internal phishing behavior even after known EvilTokens infrastructure goes quiet.
Example Hunt Ideas
These sample queries are starting points. Adapt field names to Microsoft Entra ID, Defender XDR, Sentinel, or your SIEM.
Device-code sign-ins
SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol =~ "deviceCode"
or ClientAppUsed has "Device"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, ResultType, UserAgent
| order by TimeGenerated desc
Device-code sign-ins followed by mailbox access
let DeviceCodeUsers =
SigninLogs
| where TimeGenerated > ago(14d)
| where AuthenticationProtocol =~ "deviceCode" or ClientAppUsed has "Device"
| distinct UserPrincipalName;
OfficeActivity
| where TimeGenerated > ago(14d)
| where UserId in (DeviceCodeUsers)
| where Workload =~ "Exchange"
| summarize count(), Operations=make_set(Operation, 20) by UserId, bin(TimeGenerated, 1d)
Suspicious mailbox rules
OfficeActivity
| where TimeGenerated > ago(30d)
| where Workload =~ "Exchange"
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| where Parameters has_any ("ForwardTo", "RedirectTo", "DeleteMessage", "MarkAsRead", "MoveToFolder")
| project TimeGenerated, UserId, Operation, ClientIP, Parameters
| order by TimeGenerated desc
OAuth consent or token grant anomalies
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has_any ("Consent", "Add delegated permission grant", "Add app role assignment")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result
| order by TimeGenerated desc
Strategic Takeaway
EvilTokens is a reminder that modern cybercrime does not need to defeat MFA head-on when it can convince users to approve a legitimate authentication flow for the wrong device. The weak point is not just the person. It is the combination of permissive authentication policy, durable tokens, limited session revocation, and mailboxes full of monetizable context.
The disruption creates breathing room. Use it to remove unnecessary device-code access, improve token-revocation muscle memory, harden mailbox rule monitoring, and rehearse incident response for identity-led fraud.
The next platform may not be called EvilTokens. The technique will still be there.
References
FAQ
EvilTokens is a phishing-as-a-service platform Microsoft says abused device-code authentication to compromise Microsoft accounts and support business email compromise campaigns.
It can route victims through legitimate Microsoft sign-in infrastructure, making the process look trustworthy while granting attackers token-based access to the victim's account.
Not necessarily. Device-code phishing can still succeed if the victim completes the legitimate MFA challenge for an attacker-initiated device-code flow.
Restrict or disable device-code authentication where it is not needed, revoke suspicious sessions, review mailbox rules, and hunt for unusual device-code sign-ins followed by mailbox or Graph activity.