Date: September 24, 2026
Author: Threat Research & Intelligence Team, Digital Spying
Category: Identity & Cloud Security / Phishing-as-a-Service / Threat Intelligence
Tags: EvilTokens, Device Code Phishing, OAuth 2.0, Microsoft Entra ID, MFA Bypass, Artificial Intelligence, BEC
Executive Summary
On September 22–24, 2026, the Microsoft Digital Crimes Unit (DCU), in coordination with global law enforcement and threat intelligence researchers, announced the legal and technical disruption of EvilTokens—one of the most sophisticated and prolific Phishing-as-a-Service (PhaaS) platforms in cybercrime history. As documented in technical briefings by Microsoft Security, Microsoft On the Issues, and The Hacker News, EvilTokens compromised more than 12,000 enterprise inboxes across over 10,000 organizations worldwide within seven months of operation.
Unlike legacy phishing kits that steal static usernames and passwords, or standard Adversary-in-the-Middle (AiTM) frameworks that intercept session cookies, EvilTokens weaponized the OAuth 2.0 Device Authorization Grant (RFC 8628). By abusing the legitimate device code authentication protocol, attackers completely bypassed enterprise multi-factor authentication (MFA)—including push notifications, one-time passwords (OTPs), and even FIDO2 hardware security keys.
Most alarmingly, EvilTokens was engineered with an autonomous AI agent engine directly embedded into its post-exploitation pipeline. Upon receiving stolen primary refresh tokens (PRTs), the platform’s AI agents automatically interrogated Microsoft Graph API endpoints, synthesized mailbox histories to mimic executive writing styles, altered banking instructions on pending invoices, and initiated fraudulent wire transfers with zero human operator intervention.
Technical Deep-Dive: Weaponizing the OAuth Device Code Flow
To understand why EvilTokens was able to blindside enterprise security perimeters, we must examine the architectural anatomy of the attack chain.+-----------------------------------------------------------------------------------+
| EVILTOKENS DEVICE CODE ATTACK ARCHITECTURE |
|---|
Victim / Enterprise User Microsoft Identity Platform (Entra ID) EvilTokens PhaaS & AI Engine
| | |
| | 1. Requests Device Code for |
| | legitimate client (e.g. Office CLI) |
| |<------------------------------------------|
| | 2. Returns user_code (e.g., "ABCD-WXYZ") |
| | and device_code token |
| |------------------------------------------>|
| | |
| 3. Receives phishing lure (HR/DocuSign) | |
| Directs user to real microsoft.com link | |
|<----------------------------------------------------------------------------------------|
| | |
| 4. Navigates to legitimate URL: | |
| `https://microsoft.com/devicelogin` | |
| Enters code "ABCD-WXYZ" | |
|-------------------------------------------->| |
| 5. Completes Full Enterprise MFA: | |
| Password + Authenticator Push / FIDO2 | |
|-------------------------------------------->| |
| 6. Consents to application access | |
|-------------------------------------------->| |
| | 7. Polls `/token` endpoint |
| |<------------------------------------------|
| | 8. Issues valid Access Token & |
| | Primary Refresh Token (PRT)! |
| |------------------------------------------>|
| | |
| | 9. Autonomous AI Agent Takes Over: |
| | - Connects via Microsoft Graph API |
| | - Semantic search: "wire", "invoice" |
| | - Replaces banking wire details |
| | - Hides alerts with inbox rules |
v v v v
1. The Legitimate Purpose of Device Code Flow
The OAuth 2.0 Device Authorization Grant (RFC 8628) was originally developed for devices lacking a full browser or keyboard—such as smart TVs, IoT hardware, and command-line interfaces (CLIs).
1. The client sends a POST request to https://login.microsoftonline.com/common/oauth2/v2.0/devicecode.
2. Microsoft responds with a user_code (e.g., ABCD-WXYZ) and a device_code.
3. The device prompts the user to visit https://microsoft.com/devicelogin on another browser, enter the user_code, and authenticate.
4. Meanwhile, the client polls the /token endpoint until Microsoft returns the authorization token.
2. The EvilTokens Exploit Vector
EvilTokens turned this legitimate convenience feature into a devastating credential-less compromise pipeline:
* Legitimate Domain Authentication: The victim is sent directly to https://microsoft.com/devicelogin. Because the URL is an authentic Microsoft properties domain with a valid certificate, Secure Email Gateways (SEGs), web proxies, and browser security extensions verify the site as 100% trustworthy.
* Full MFA Satisfaction: The user logs in using their real corporate password and approves their genuine MFA prompt. Crucially, the user believes they are authenticating their own workstation or cloud session. In reality, they are authorizing an OAuth token request initiated remotely by the EvilTokens C2 server.
* Token Issuance: Once authentication is approved, Microsoft’s token endpoint delivers a high-privilege Bearer Access Token and Refresh Token directly to the attacker’s infrastructure.
3. The Autonomous AI Post-Compromise Engine
What set EvilTokens apart from all previous PhaaS platforms was its deep integration with a purpose-built large language model (LLM) backend:
* Automated Mailbox Reconnaissance: Upon token arrival, the EvilTokens backend used Microsoft Graph API (/v1.0/me/messages) to index the victim's email history, identifying ongoing invoice negotiations, executive discussions, and financial workflows.
* Style-Matching BEC Synthesis: The AI agent analyzed the victim's historical correspondence to replicate their vocabulary, punctuation, and greeting conventions. It generated reply emails into active threads, informing vendors or clients that "due to an ongoing audit, banking details have been updated," attaching fraudulent payment routing numbers.
* Stealth Persistence: The agent created stealthy inbox rules (/v1.0/me/mailFolders/inbox/messageRules) to automatically redirect and mark as read any incoming messages containing keywords like "phishing," "fraud," "unauthorized," or "bank."
Strategic Impact on Enterprise Identity Architecture
The EvilTokens operation fundamentally challenges traditional enterprise assumptions regarding identity security:
1. MFA Is Not a Silver Bullet: Strong MFA (even FIDO2 WebAuthn keys) does not prevent compromise if the authentication grant itself is redirected at the protocol level.
2. AiTM Evasion: Because no proxy or spoofed domain sits between the victim and Microsoft, network-level AiTM detection tools are completely blind to device code phishing.
3. Automated Cybercrime Scaling: By coupling PhaaS with autonomous AI agents, cybercriminal groups eliminated the latency between initial credential theft and financial monetization, executing fraudulent wire transfers within minutes of token acquisition.
Defensive Hardening & Detection Blueprint
CISOs, Entra ID administrators, and security operations centers must immediately harden their cloud identity configurations:
1. Restrict or Block Device Code Flow in Microsoft Entra ID
Organizations that do not strictly require device code authentication on user endpoints should block it using Conditional Access:
* In Microsoft Entra Admin Center, navigate to Protection > Conditional Access > Policies.
* Target: All Users (excluding break-glass emergency accounts).
* Target Resources: Cloud Apps > All Cloud Apps.
* Conditions: Client Apps > Configure > Select Browser and Mobile apps and desktop clients.
* Grant: Block Access for authentication requests utilizing the Device Code grant, or restrict execution exclusively to Intune-compliant, hybrid Azure AD-joined devices.
2. Hunt for Suspicious Device Code Authentication Events
Audit your Microsoft Entra Sign-in logs using Kusto Query Language (KQL) in Microsoft Sentinel or Defender for Cloud Apps:// Detect successful Device Code authentications
SigninLogs
| where TimeGenerated >= ago(14d)
| where AuthenticationProtocol =~ "deviceCode"
| where ResultType == 0 // Successful logon
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, ResourceDisplayName, DeviceDetail
| order by TimeGenerated desc
3. Audit Risky OAuth Application Grants & Permissions
Regularly review OAuth application consents and tokens granted to non-standard CLI or native applications:# Review OAuth permissions in Microsoft Graph PowerShell
Get-MgServicePrincipal -All | Where-Object {$_.OAuth2PermissionGrants -ne $null}
4. Monitor Mailbox Rule Creation for Financial Keywords
Configure alerting for Exchange Online inbox rules designed to hide financial correspondence:# Search for suspicious inbox rules redirecting mail externally
Get-InboxRule -Mailbox * | Where-Object {
$_.ForwardTo -ne $null -or $_.RedirectTo -ne $null -or $_.DeleteMessage -eq $true
} | Select-Object MailboxOwnerId, Name, Description
For technical threat intelligence advisories, identity security breakdowns, and enterprise cloud defense research, subscribe to Digital Spying.